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 ldapsearch utility 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): The searchbase ( -b ) defines the subtree where ldapsearch looks 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 krblastpwdchange parameter 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 dn and krbprincipalname attributes limits the search results to the entry name and principal. For every service and host that requires rekeying the principal, use the ipa-getkeytab utility 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 : To rekey the keytab for the Apache service in the default location of /etc/httpd/conf/ipa.keytab : Important Some 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 klist utility to list all Kerberos tickets. For example, to list all keytab entries in /etc/krb5.keytab : The output shows that the keytab entry for client.example.com was rekeyed with a higher KVNO. The original keytab still exists in the database with the 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.

Commands:
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
ipa-getkeytab -p host/ client.example.com@EXAMPLE.COM -s server.example.com -k /etc/krb5.keytab
ipa-getkeytab -p HTTP/ client.example.com@EXAMPLE.COM -s server.example.com -k /etc/httpd/conf/ipa.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)