Elementary PKINIT questions (MIT Kerberos/Linux configuration)
Jason White via Kerberos <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.general |
|---|---|
| Message-ID | <[email protected]> |
Dear kerberos community, I've set up a very small MIT Kerberos installation for my own use, with MIT Kerberos under Linux. In experimenting with the PKINIT configuration, I have essentially followed the MIT Kerberos documentation (using openssl to generate keys and certificates), and reached the point at which I can authenticate as principal "jason" without a password. (I also have ssd configured on my Linux client with sssd-kcm for caching and the PAM module for login.) 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. Do I need to specify a PKINIT certificate matching rule, or is there some other configuration that is required? 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 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. As mentioned, this is simply for my own use/experimentation, so there's no urgency at all. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos