>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
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
