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.
- 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=comsubtree. - Service principals are stored under the
cn=services,cn=accounts,dc=example,dc=comsubtree. - Filter by the last change date (
krblastpwdchange). - Limit the search result information to only the entry name and principal by specifying the
dn krbprincipalnameattributes.
Dates are expressed in YYYYMMDD format, and times in HHMMSS format (GMT). - Retrieve a new keytab for the principal using the
ipa-getkeytabcommand. 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
- Regenerate the keytab using
ipa-getkeytabfor 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.
