Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 48. Maintaining IdM Kerberos keytab files

The following documentation explain 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.

This section discusses the following topics:

48.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 in order 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)

48.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

  1. 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.

    [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)
  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.

    [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
    DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 3
  3. Authenticate as the IdM admin account.

    [root@server1 ~]# kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  4. 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.

    [root@server1 ~]# ipa-getkeytab -s server1.idm.example.com -p DNS/server1.idm.example.com -k /etc/named.keytab

Verification

  1. 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)
  2. 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

48.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 48.1. Table

Keytab locationContentsPurpose

/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 HOSTNAME$@AD-DOMAIN.COM

Communicating with AD DCs through an IdM-AD Trust