Este conteúdo não está disponível no idioma selecionado.
Chapter 16. Maintaining IdM Kerberos keytab files
Maintain Identity Management (IdM) Kerberos keytab files to ensure services can 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.
16.1. How Identity Management uses Kerberos keytab files Copiar o linkLink copiado para a área de transferência!
Learn how Identity Management (IdM) uses Kerberos keytab files to enable users, hosts, and services to authenticate to the KDC without human interaction, so you can maintain and troubleshoot service authentication in your IdM deployment.
A Kerberos keytab is a file containing Kerberos principals and their corresponding encryption keys.
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)
16.2. Verifying that Kerberos keytab files are in sync with the IdM database Copiar o linkLink copiado para a área de transferência!
Verify that Kerberos keytab files on an Identity Management (IdM) server are in sync with the IdM database to fix service authentication failures caused by outdated Key Version Numbers (KVNOs).
When you change a Kerberos password, IdM automatically generates a new key and increments its KVNO. If a keytab is not updated accordingly, services that rely on it cannot authenticate to the Kerberos Key Distribution Center (KDC). If an IdM service cannot communicate with another service, a stale keytab is a likely cause.
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
16.3. List of IdM Kerberos keytab files and their contents Copiar o linkLink copiado para a área de transferência!
Reference keytab file locations and their associated principals to understand which services use which authentication credentials in Identity Management (IdM). This information helps troubleshoot authentication issues and verify service configurations.
| 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 |
16.4. Viewing the encryption type of your IdM master key Copiar o linkLink copiado para a área de transferência!
View the encryption type of the Identity Management (IdM) master key to determine whether your deployment is compatible with FIPS standards.
The master key is the key the IdM KDC uses to encrypt all other Kerberos principals when storing them at rest. 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 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
rootaccess to any of the RHEL 8 replicas in the IdM deployment.
Procedure
On the replica, view the encryption type on the command line:
# 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.