>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
