Chapter 53. 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:
53.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:
[root@idmserver ~]# 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)
53.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
rootaccount 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.keytabfile has the key for theDNS/server1.idm.example.com@EXAMPLE.COMprincipal with a KVNO of 2.[root@server1 ~]# 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)
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.
[root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 3Authenticate as the IdM admin account.
[root@server1 ~]# kinit admin Password for admin@IDM.EXAMPLE.COM:
Retrieve an updated Kerberos key for the principal and store it in its keytab. Perform this step as the
rootuser so you can modify the/etc/named.keytabfile, which is owned by thenameduser.[root@server1 ~]# ipa-getkeytab -s server1.idm.example.com -p DNS/server1.idm.example.com -k /etc/named.keytab
Verification
Display the updated KVNO of the principal in the keytab.
[root@server1 ~]# 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)
Display the KVNO of the principal stored in the IdM database and ensure it matches the KVNO from the keytab.
[root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 4
53.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.
| Keytab location | Contents | Purpose |
|---|---|---|
|
|
|
Verifying user credentials when logging in, used by NFS if there is no |
|
|
| Authenticating users to the IdM database, securely replicating database contents between IdM replicas |
|
|
| Authenticating to the Apache server |
|
|
| Securely updating DNS records |
|
|
| Keeping OpenDNSSEC synchronized with LDAP |
|
|
| Communicating with the Certificate Authority (CA) |
|
|
| Communicating with the Samba service |
|
|
Active Directory (AD) domain controller (DCs) principals in the form | Communicating with AD DCs through an IdM-AD Trust |
53.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 previous RHEL versions are not compatible with RHEL 9 systems that adhere to FIPS 140-3 standards. To make RHEL 9 systems in FIPS mode compatible with a RHEL 8 FIPS 140-2 deployment, enable the FIPS:AD-SUPPORT cryptographic policy on the RHEL 9 systems.
Microsoft’s Active Directory implementation does not yet support any of the RFC8009 Kerberos encryption types that use SHA-2 HMAC. If you have an IdM-AD trust configured, FIPS:AD-SUPPORT crypto subpolicy use is therefore required even if the encryption type of your IdM master key is aes256-cts-hmac-sha384-192.
Prerequisites
-
You have
rootaccess to any of the RHEL 8 replicas in the IdM deployment.
Procedure
On the replica, view the encryption type on the command-line interface:
# kadmin.local getprinc K/M | grep -E '^Key:' Key: vno 1, aes256-cts-hmac-sha1-96The
aes256-cts-hmac-sha1-96key in the output indicates that the IdM deployment was installed on a server that was running RHEL 8.6 or earlier. The presence of aaes256-cts-hmac-sha384-192key in the output would indicate that the IdM deployment was installed on a server that was running RHEL 8.7 or later.
