Learn Kerberos - LDAP and Kerberos Integration

#Introduction

In episode 16 you used Kerberos tickets to get into PostgreSQL and MySQL. Now we move up to the layer that manages identity itself: the directory. So far Kerberos principals have lived in the KDC's binary database, which only Kerberos understands — hard to read, audit, or synchronize with other systems. This episode fixes that with LDAP: first as a storage place for KDC principals, then as a service that can be authenticated with Kerberos via SASL/GSSAPI, and finally with a discussion of Active Directory.

The end result is a unified identity foundation: one directory as the source of truth for users, and one KDC issuing tickets for them.

#LDAP as a Principal Backend

The MIT Kerberos principal database defaults to a local file (/var/lib/krb5kdc/principal) that only special tools can read. With an LDAP backend, principals are stored as objects in the directory — user alice becomes an entry that can be read, searched, and managed together with other identity attributes.

Unified user management is the main reason to switch: instead of three separate systems (a Kerberos database, an LDAP directory, and an application user list), just one. When an employee leaves, one operation deletes the entry — the Kerberos principal, mailbox, and group memberships disappear all at once.

Benefits of an LDAP backend for the KDC include: separating principal data from the KDC process (a KDC can be rebuilt without losing data), easy integration with identity management tools that already understand LDAP, mature replication, and the ability to carry principal attributes along with user data.

#Configuring the KDC with an LDAP Backend (kldap)

MIT Kerberos supports an LDAP backend through the kldap module. First, the KDC must use an LDAP database instead of a file — this is declared in [dbmodules] in /etc/krb5.conf:

/etc/krb5.conf - KDC with an LDAP backend

[dbmodules]
  EXAMPLE.COM = {
    db_library = kldap
    ldap_kerberos_container_dn = cn=krbContainer,dc=example,dc=com
    ldap_kdc_dn = cn=kdc-svc,ou=services,dc=example,dc=com
    ldap_kadmind_dn = cn=admin-svc,ou=services,dc=example,dc=com
    ldap_service_password_file = /etc/krb5kdc/service.keyfile
    ldap_servers = ldap://ldap1.example.com
  }

LDAP schema installation. The KDC needs to understand the Kerberos attributes in the directory. That schema is provided by MIT as kerberos.schema — import it into OpenLDAP so entries can carry attributes like krbPrincipalName and krbPrincipalKey.

Container setup. All principals are stored under the cn=krbContainer container. The container is initialized with kdb5_ldap_util, and the service accounts (kdc-svc, admin-svc) are granted read/write rights on that container.

ACL configuration. Security is managed via ACLs on the LDAP side: the KDC service account may only read/write Kerberos objects, not the whole directory. Restrict kadmind's rights to modifying principal attributes only, and never give these accounts full directory admin access.

kdb5_ldap_util -D cn=admin,dc=example,dc=com create -r EXAMPLE.COM
kdb5_ldap_util -D cn=admin,dc=example,dc=com stash

#SASL/GSSAPI for LDAP

Once the KDC lives on top of LDAP, it's time to use Kerberos to authenticate the LDAP connection itself — no more plain password binds. SASL supports the GSSAPI mechanism: the client offers a Kerberos ticket, the server validates it with its own keytab.

LDAP server SASL configuration. The LDAP server must have the ldap/ldap1.example.com principal in its keytab:

kadmin.local -q "addprinc -randkey ldap/ldap1.example.com"
kadmin.local -q "ktadd -k /etc/krb5.keytab ldap/ldap1.example.com"

This keytab for the ldap service is used by OpenLDAP to decrypt GSSAPI tokens from clients. Once the keytab is available and the daemon reads KRB5_KTNAME, the server is ready to accept SASL binds.

LDAP client SASL binds. From the client side, just have a ticket and use -Y GSSAPI:

kinit alice
ldapwhoami -Y GSSAPI -H ldap://ldap1.example.com

A response like dn:uid=alice,ou=people,dc=example,dc=com proves two things at once: the ticket was accepted by the server, and the principal identity was successfully mapped to a directory entry.

#OpenLDAP Integration

slapd.conf or cn=config. OpenLDAP configuration can be file-based (slapd.conf) or written dynamically in cn=config. For SASL GSSAPI, both approaches lead to realm and principal mapping:

SASL realm mapping. OpenLDAP must know that the Kerberos realm EXAMPLE.COM equals the directory domain dc=example,dc=com. This is set with sasl-realm:

cn=config - SASL realm and principal mapping

olcSaslRealm: EXAMPLE.COM
olcSaslHost: ldap1.example.com
olcSaslSecProps: minssf=0
olcAuthzRegexp: ^uid=([^,]+).*$ uid=$1,ou=people,dc=example,dc=com

Kerberos principal to DN mapping. The olcAuthzRegexp line above is the heart of the mapping: every alice@EXAMPLE.COM principal (represented by SASL as uid=alice@EXAMPLE.COM,cn=gssapi,cn=auth) is turned into the full DN uid=alice,ou=people,dc=example,dc=com. Without this rule, a GSSAPI bind succeeds but the identity is not tied to any entry.

#Active Directory

AD as KDC. Active Directory is essentially a Kerberos KDC that wraps tickets with Microsoft attributes: the domain becomes the realm, the Domain Controller becomes the KDC, and tickets carry a PAC containing group memberships. What's interesting for us: because AD speaks standard Kerberos, Linux clients and MIT services can join the same realm.

Kerberos tickets from AD. When a Linux machine joins an AD domain, it gets tickets from the DC just like a Windows client. klist on Linux shows tickets with the principal user@AD.EXAMPLE.COM — the Kerberos realm is the domain name.

Cross-realm with AD. Instead of merging the whole organization into one realm, many companies choose cross-realm trust: the MIT realm EXAMPLE.COM and the AD realm AD.EXAMPLE.COM trust each other through inter-realm tickets. Users from one realm can use tickets to access services in the other realm, without duplicate accounts.

Linux clients with AD. Linux clients consume AD through SSSD or pam_krb5 + LDAP: authentication uses Kerberos against the DC, while attributes (UID, group, shell) are fetched from LDAP behind it. From a pure Kerberos perspective, this is just a matter of pointing kdc and admin_server at the DC and adding a realm mapping in /etc/krb5.conf.

#Conclusion

This episode united the two pillars of identity: Kerberos for authentication and LDAP for the directory. You placed KDC principals in an LDAP backend via kldap and [dbmodules], imported kerberos.schema, built the container and ACLs, activated SASL/GSSAPI binds with the ldap/ldap1.example.com principal, mapped principals to DNs via olcAuthzRegexp, and saw how Active Directory occupies the same role as a KDC and a cross-realm partner.

Key takeaways:

• An LDAP backend makes KDC principals managed data — one directory becomes the source of truth, one entry represents one user together with their attributes.
• SASL/GSSAPI binds replace plain passwords: ldapwhoami -Y GSSAPI uses a ticket, and olcAuthzRegexp maps the alice@EXAMPLE.COM principal to its actual DN.
• A KDC with an LDAP backend needs extra preparation: the kerberos.schema schema, the cn=krbContainer container, service accounts, and strict ACLs — never give KDC accounts directory admin rights.
• Active Directory is a standard Kerberos KDC, and integration with an MIT realm is done through cross-realm trust, not by stacking two KDCs in the same realm.

In episode 18 we fully dissect the Windows side: Kerberos in Active Directory — from the Domain Controller's role and the krbtgt account to the golden ticket consequences of its compromise. See you there!