Chapter 54. Maintaining IdM Kerberos keytab files Learn more about what Kerberos keytab files are and how Identity Management (IdM) uses them to allow services to authenticate securely with Kerberos. You can use this information to understand why you should protect these sensitive files, and to troubleshoot communication issues between IdM services. For more information, see the following topics: How Identity Management uses Kerberos keytab files Verifying that Kerberos keytab files are in sync with the IdM database List of IdM Kerberos keytab files and their contents Viewing the encryption type of your IdM master key . 54.1. How Identity Management uses Kerberos keytab files A Kerberos keytab is a file containing Kerberos principals and their corresponding encryption keys. Hosts, services, users, and scripts can use keytabs to authenticate to the Kerberos Key Distribution Center (KDC) securely, without requiring human interaction. Every IdM service on an IdM server has a unique Kerberos principal stored in the Kerberos database. For example, if IdM servers east.idm.example.com and west.idm.example.com provide DNS services, IdM creates 2 unique DNS Kerberos principals to identify these services, which follow the naming convention <service>/host.domain.com@REALM.COM : DNS/east.idm.example.com@IDM.EXAMPLE.COM DNS/west.idm.example.com@IDM.EXAMPLE.COM IdM creates a keytab on the server for each of these services to store a local copy of the Kerberos keys, along with their Key Version Numbers (KVNO). For example, the default keytab file /etc/krb5.keytab stores the host principal, which represents that machine in the Kerberos realm and is used for login authentication. The KDC generates encryption keys for the different encryption algorithms it supports, such as aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96 . You can display the contents of a keytab file with the klist command: Additional resources Verifying that Kerberos keytab files are in sync with the IdM database List of IdM Kerberos keytab files and their contents 54.2. Verifying that Kerberos keytab files are in sync with the IdM database When you change a Kerberos password, IdM automatically generates a new corresponding Kerberos key and increments its Key Version Number (KVNO). If a Kerberos keytab is not updated with the new key and KVNO, any services that depend on that keytab to retrieve a valid key might not be able to authenticate to the Kerberos Key Distribution Center (KDC). If one of your IdM services cannot communicate with another service, use the following procedure to verify that your Kerberos keytab files are in sync with the keys stored in the IdM database. If they are out of sync, retrieve a Kerberos keytab with an updated key and KVNO. This example compares and retrieves an updated DNS principal for an IdM server. Prerequisites You must authenticate as the IdM admin account to retrieve keytab files You must authenticate as the root account to modify keytab files owned by other users Procedure Display the KVNO of the principals in the keytab you are verifying. In the following example, the /etc/named.keytab file has the key for the DNS/server1.idm.example.com@EXAMPLE.COM principal with a KVNO of 2. Display the KVNO of the principal stored in the IdM database. In this example, the KVNO of the key in the IdM database does not match the KVNO in the keytab. Authenticate as the IdM admin account. Retrieve an updated Kerberos key for the principal and store it in its keytab. Perform this step as the root user so you can modify the /etc/named.keytab file, which is owned by the named user. Verification Display the updated KVNO of the principal in the keytab. Display the KVNO of the principal stored in the IdM database and ensure it matches the KVNO from the keytab. Additional resources How Identity Management uses Kerberos keytab files List of IdM Kerberos keytab files and their contents 54.3. List of IdM Kerberos keytab files and their contents The following table displays the location, contents, and purpose of the IdM Kerberos keytab files. Table 54.1. Table Keytab location Contents Purpose /etc/krb5.keytab host principal Verifying user credentials when logging in, used by NFS if there is no nfs principal /etc/dirsrv/ds.keytab ldap principal Authenticating users to the IdM database, securely replicating database contents between IdM replicas /var/lib/ipa/gssproxy/http.keytab HTTP principal Authenticating to the Apache server /etc/named.keytab DNS principal Securely updating DNS records /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-dnskeysyncd principal Keeping OpenDNSSEC synchronized with LDAP /etc/pki/pki-tomcat/dogtag.keytab dogtag principal Communicating with the Certificate Authority (CA) /etc/samba/samba.keytab cifs and host principals Communicating with the Samba service /var/lib/sss/keytabs/ ad-domain.com .keytab Active Directory (AD) domain controller (DCs) principals in the form HOSTNAMEUSD@AD-DOMAIN.COM Communicating with AD DCs through an IdM-AD Trust Additional resources How Identity Management uses Kerberos keytab files Verifying that Kerberos keytab files are in sync with the IdM database 54.4. Viewing the encryption type of your IdM master key As an Identity Management (IdM) administrator, you can view the encryption type of your IdM master key, which is the key that the IdM Kerberos Distribution Center (KDC) uses to encrypt all other principals when storing them at rest. Knowing the encryption type helps you determine your deployment's compatibility with FIPS standards. As of RHEL 8.7, the encryption type is aes256-cts-hmac-sha384-192 . This encryption type is compatible with the default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3. The encryption types used on RHEL versions are not compatible with RHEL 9 systems that adhere to FIPS 140-3 standards. To make RHEL 9 systems compatible with a RHEL 8 FIPS 140-2 deployment, see the AD Domain Users unable to login in to the FIPS-compliant environment KCS solution. Prerequisites You have root access to any of the RHEL 8 replicas in the IdM deployment. Procedure On the replica, view the encryption type on the command-line interface: The aes256-cts-hmac-sha1-96 key in the output indicates that the IdM deployment was installed on a server that was running RHEL 8.6 or earlier. The presence of a aes256-cts-hmac-sha384-192 key in the output would indicate that the IdM deployment was installed on a server that was running RHEL 8.7 or later.

Commands:
klist -ekt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes128-cts-hmac-sha1-96) 2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia128-cts-cmac) 2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia256-cts-cmac)
klist -ekt /etc/named.keytab Keytab name: FILE:/etc/named.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac) 2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
kvno DNS/server1.idm.example.com@EXAMPLE.COM DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 3
kinit admin Password for admin@IDM.EXAMPLE.COM:
ipa-getkeytab -s server1.idm.example.com -p DNS/server1.idm.example.com -k /etc/named.keytab
klist -ekt /etc/named.keytab Keytab name: FILE:/etc/named.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac) 4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
kvno DNS/server1.idm.example.com@EXAMPLE.COM DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 4
kadmin.local getprinc K/M | grep -E '^Key:' Key: vno 1, aes256-cts-hmac-sha1-96