20.3. Refreshing Kerberos Tickets

Kerberos keys are analogous to passwords. As with password policies, Kerberos tickets come under security policies which require them to be manually refreshed after a specified interval.
The version of the key is shown in its key version number (KVNO). Refreshing (also called rotating) the principal's key increments the KVNO in the keytab entry. When a key is refreshed, a new entry is added to the keytab with a higher KVNO. The original key remains in the keytab but is no longer used to issue tickets.
Each keytab for the IdM realm has an entry in the IdM LDAP server, which includes its last change time. The principals which need to be refreshed can be regenerated using the ipa-getkeytab command.

Note

The ipa-getkeytab command does not delete the old keytab in case it already exists in the file.
  1. Find all keytabs issued before the requisite date. For example, this looks for any principals created between midnight on January 1, 2010, and 11:59 PM on December 31, 2010: 
    # ldapsearch -x -b "cn=computers,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20100101000000)(krblastpwdchange<=20101231235959))" dn krbprincipalname
					 
# ldapsearch -x -b "cn=services,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20100101000000)(krblastpwdchange<=20101231235959))" dn krbprincipalname
    • Host (machine) 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.
    • Filter by the last change date (krblastpwdchange).
    • Limit the search result information to only the entry name and principal by specifying the dn krbprincipalname attributes.
    Dates are expressed in YYYYMMDD format, and times in HHMMSS format (GMT).
  2. Retrieve a new keytab for the principal using the ipa-getkeytab command. This requires the location of the original keytab for the service or host (-k), the principal (-p), and the IdM server hostname (-s).
    For example, this refreshes the host principal with a keytab in the default location of /etc/krb5.keytab: 
    # ipa-getkeytab -p host/client.example.com@EXAMPLE.COM -s ipa.example.com -k /etc/krb5.keytab
    This refreshes the keytab for the Apache service, with a keytab in the default location of /etc/httpd/conf/ipa.keytab: 
    # ipa-getkeytab -p HTTP/client.example.com@EXAMPLE.COM -s ipa.example.com -k /etc/httpd/conf/ipa.keytab
  3. Regenerate the keytab using ipa-getkeytab for every service.
The klist command displays the new key version number for the refreshed keytab. The original keytab still exists in the database, and it is listed with the previous KVNO. 
# klist -kt /etc/krb5.keytab
Keytab: WRFILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   1 06/09/10 11:23:01 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 
   2 06/09/11 05:58:47 host/client.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96) 
   1 03/09/11 13:57:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
   1 03/09/11 13:57:16 HTTP/ipa.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
   1 03/09/11 13:57:16 ldap/ipa.example.com@EXAMPLE.COM(aes256-cts-hmac-sha1-96)
Tickets issued against the old keytab continue to work, while new tickets are issued using the key with the highest KVNO. This avoids any disruption to system operations.

Important

Some services, such as NFSv4, only support a limited set of encryption types. Pass the appropriate arguments to the ipa-getkeytab command to configure the keytab properly.