Copy:
[email protected]
First problem: I have a second principal, jason/admin, for use with
kadmin. I've generated a certificate that can authenticate. However, now
that I have two certificates (one for jason and another for
jason/admin), it isn't clear how to configure the client to offer the
correct certificate to the kdc. If I specify both certificates on >pkinit_identities lines in the client's krb5.conf file, "jason" can log
in, but kadmin returns a "Client name mismatch while initializing kadmin >interface" error. My assumptions is that the wrong certificate was
offered to the KDC (i.e., not the jason/admin certificate). Specifying
the directory containing the certificates in pkinit_identities results
in finding two certificates where one is expected, with an error message
to that effect.
The bottom line is you need to make only one certificate available
to the PKINIT client code. This is kind of a corner case; you don't
normally have a single Unix user with two valid certificates. But
there are some options.
You can specify the certificate exactly on the 'kinit' command line
with the "-X X509_user_identity" option (this has the same format
as the pkinit_identities option in krb5.conf). Now this option isn't
supported for kadmin, but you can do:
% kinit -X X509_user_identity=FILE:/tmp/foo.pem -S kadmin/admin jason/admin
or
% kinit -X X509_user_identity=FILE:/tmp/foo.pem -S kadmin/admin.host jason/admin
Depending on the principal you are using for kadmind, and then you can use
the "-c credential_cache" option to kadmin to use an existing credential
cache.
Do I need to specify a PKINIT certificate matching rule, or is there
some other configuration that is required?
I do not think a matching rule would help; it sounds like you have two
distinct certificates but I cannot think of a generic match rule that
would match one certificate but not another based on the requested
principal.
Second problem: securing the client's private key. The Linux client has
a TPM 2.0 module, but I haven't found any documentation on how to
configure it for use with Kerberos, if indeed this is supported.
References would be welcome.
The incredibly short answer here is that the only generic mechanism
supported for hardware storage of private keys is a PKCS#11 module. A
quick Google suggests that there are PKCS#11 modules which can interface
with a TPM module. However, I have to caution you that when using a
PKCS#11 module with Kerberos the hardware backed by the PKCS#11 module
has to contain the certificate _and_ keys. There's not a way to say,
"The cert is on this file and the private key is available in this
module". (I COULD be wrong about this, but a quick glance at the source
code suggests that I am correct). A very quick Google only shows the
PKCS#11 module that interfaces with TPM storing private keys; it MAY
support storing a certificate as well, but it may not. You're going to
be kind of on the fringe here is what I'm trying to say.
The machine has a smartcard reader, so my other options would be to
purchase some compatible smartcards (after finding out what those are),
or a security key. In the latter case, I would probably choose a FIDO 2
key with smartcard support.
I would also caution you that the same issue applies as above; you need
to make sure your smartcard (a) has a PKCS#11 module available (on Linux
this probably means OpenSC) and (b) it supports storing certificates on
the smartcard.
I have had success using a YubiKey 5 in PIV mode which also supports
a bunch of other things like FIDO 2; I have no connection with Yubico
other than as a user. Yubico provides a PKCS#11 module but in PIV mode
you should be able to use any PKCS#11 module that supports PIV (this is
very common). One advantage to a YubiKey is it is just USB and does not require a dedicated smartcard reader. Note that this is a lot of moving
parts and probably will require a fair amount of fiddling.
--Ken
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)