Make sure the LDAP server is using local authentication (
ldapi://) or TLS (
ldaps). See https://www.openldap.org/doc/admin24/tls.html for instructions on configuring TLS support in OpenLDAP.
Add the Kerberos schema file to the LDAP Server using the OpenLDAP LDIF file from the krb5 source directory (
src/plugins/kdb/ldap/libkdb_ldap/kerberos.openldap.ldif). The following example uses local authentication:
ldapadd -Y EXTERNAL -H ldapi:/// -f /path/to/kerberos.openldap.ldif
Choose DNs for the
kadmind(8)servers to bind to the LDAP server, and create them if necessary. Specify these DNs with the ldap_kdc_dn and ldap_kadmind_dn directives in
kdc.conf(5). The kadmind DN will also be used for administrative commands such as
Alternatively, you may configure krb5kdc and kadmind to use SASL authentication to access the LDAP server; see the
dbmodulesrelations ldap_kdc_sasl_mech and similar.
Specify a location for the LDAP service password file by setting ldap_service_password_file. Use
kdb5_ldap_util stashsrvpwto stash passwords for the KDC and kadmind DNs chosen above. For example:
kdb5_ldap_util stashsrvpw -f /path/to/service.keyfile cn=krbadmin,dc=example,dc=com
Skip this step if you are using SASL authentication and the mechanism does not require a password.
Choose a DN for the global Kerberos container entry (but do not create the entry at this time). Specify this DN with the ldap_kerberos_container_dn directive in
kdc.conf(5). Realm container entries will be created underneath this DN. Principal entries may exist either underneath the realm container (the default) or in separate trees referenced from the realm container.
Configure the LDAP server ACLs to enable the KDC and kadmin server DNs to read and write the Kerberos data. If disable_last_success and disable_lockout are both set to true in the
dbmodulessubsection for the realm, then the KDC DN only requires read access to the Kerberos data.
Sample access control information:
access to dn.base="" by * read access to dn.base="cn=Subschema" by * read # Provide access to the realm container. access to dn.subtree= "cn=EXAMPLE.COM,cn=krbcontainer,dc=example,dc=com" by dn.exact="cn=kdc-service,dc=example,dc=com" write by dn.exact="cn=adm-service,dc=example,dc=com" write by * none # Provide access to principals, if not underneath the realm container. access to dn.subtree= "ou=users,dc=example,dc=com" by dn.exact="cn=kdc-service,dc=example,dc=com" write by dn.exact="cn=adm-service,dc=example,dc=com" write by * none access to * by * read
If the locations of the container and principals or the DNs of the service objects for a realm are changed then this information should be updated.
kdc.conf(5), make sure the following relations are set in the
dbmodulessubsection for the realm:
db_library (set to ``kldap``) ldap_kerberos_container_dn ldap_kdc_dn ldap_kadmind_dn ldap_service_password_file ldap_servers
Create the realm using
kdb5_ldap_util create -subtrees ou=users,dc=example,dc=com -s
Use the -subtrees option if the principals are to exist in a separate subtree from the realm container. Before executing the command, make sure that the subtree mentioned above
(ou=users,dc=example,dc=com)exists. If the principals will exist underneath the realm container, omit the -subtrees option and do not worry about creating the principal subtree.
For more information, refer to the section
The realm object is created under the ldap_kerberos_container_dn specified in the configuration file. This operation will also create the Kerberos container, if not present already. This container can be used to store information related to multiple realms.
krbPrincipalNameto speed up principal lookup operations. See https://www.openldap.org/doc/admin24/tuning.html#Indexes for details.
With the LDAP back end it is possible to provide aliases for principal entries. Currently we provide no administrative utilities for creating aliases, so it must be done by direct manipulation of the LDAP entries.
An entry with aliases contains multiple values of the krbPrincipalName attribute. Since LDAP attribute values are not ordered, it is necessary to specify which principal name is canonical, by using the krbCanonicalName attribute. Therefore, to create aliases for an entry, first set the krbCanonicalName attribute of the entry to the canonical principal name (which should be identical to the pre-existing krbPrincipalName value), and then add additional krbPrincipalName attributes for the aliases.
Principal aliases are only returned by the KDC when the client requests canonicalization. Canonicalization is normally requested for service principals; for client principals, an explicit flag is often required (e.g.,
kinit -C) and canonicalization is only performed for initial ticket requests.