Ce contenu n'est pas disponible dans la langue sélectionnée.
29.2. Rekeying Kerberos Principals
Rekeying a Kerberos principal adds a new keytab entry with a higher key version number (KVNO) to the principal's keytab. The original entry remains in the keytab, but is no longer used to issue tickets.
- Find all keytabs issued within the required time period. For example, the following commands use the
ldapsearchutility to display all host and service principals created between midnight on January 1, 2016, and 11:59 PM on December 31, 2016 in Greenwich Mean Time (GMT):# ldapsearch -x -b "cn=computers,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20160101000000)(krblastpwdchange<=20161231235959))" dn krbprincipalname# ldapsearch -x -b "cn=services,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20160101000000)(krblastpwdchange<=20161231235959))" dn krbprincipalname- The searchbase (
-b) defines the subtree whereldapsearchlooks for the principals:- Host principals are stored under the cn=computers,cn=accounts,dc=example,dc=com subtree.
- Service principals are stored under the cn=services,cn=accounts,dc=example,dc=com subtree.
- The
krblastpwdchangeparameter filters the search results by the last change date. The parameter accepts the YYYYMMDD format for the date and the HHMMSS format for the time of day in GMT. - Specifying the
dnandkrbprincipalnameattributes limits the search results to the entry name and principal.
- For every service and host that requires rekeying the principal, use the
ipa-getkeytabutility to retrieve a new keytab entry. Pass the following options:--principal(-p) to specify the principal--keytab(-k) to specify the location of the original keytab--server(-s) to specify the Identity Management server host name
For example:- To rekey a host principal with its keytab in the default location of
/etc/krb5.keytab:# ipa-getkeytab -p host/client.example.com@EXAMPLE.COM -s server.example.com -k /etc/krb5.keytab - To rekey the keytab for the Apache service in the default location of
/etc/httpd/conf/ipa.keytab:# ipa-getkeytab -p HTTP/client.example.com@EXAMPLE.COM -s server.example.com -k /etc/httpd/conf/ipa.keytabImportantSome services, such as NFS version 4, support only a limited set of encryption types. Pass the appropriate arguments to the ipa-getkeytab command to configure the keytab properly.
- Optional. Verify that you rekeyed the principals successfully. Use the
klistutility to list all Kerberos tickets. For example, to list all keytab entries in/etc/krb5.keytab:# klist -kt /etc/krb5.keytab Keytab: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 06/09/16 05:58:47 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 2 06/09/16 11:23:01 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/16 13:57:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/16 13:57:16 HTTP/server.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 1 03/09/16 13:57:16 ldap/server.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
The output shows that the keytab entry forclient.example.comwas rekeyed with a higher KVNO. The original keytab still exists in the database with the previous KVNO.Tickets issued against the earlier keytab continue to work, while new tickets are issued using the key with the highest KVNO. This avoids any disruption to system operations.
