( Using LDAP to store the database

Info Catalog ( Setting up DNS ( Setting up a realm ( Providing Kerberos credentials to servers and programs
 4.16 Using LDAP to store the database
 This document describes how to install the LDAP backend for Heimdal.
 Note that before attempting to configure such an installation, you
 should be aware of the implications of storing private information
 (such as users' keys) in a directory service primarily designed for
 public information. Nonetheless, with a suitable authorisation policy,
 it is possible to set this up in a secure fashion. A knowledge of LDAP,
 Kerberos, and C is necessary to install this backend. The HDB schema
 was devised by Leif Johansson.
 This assumes, OpenLDAP 2.3 or later.
    * A current release of Heimdal, configured with
      `--with-openldap=/usr/local' (adjust according to where you have
      installed OpenLDAP).
      You can verify that you manage to configure LDAP support by running
      `kdc --builtin-hdb', and checking that `ldap:' is one entry in the
      Its also possible to configure the ldap backend as a shared module,
      see option -hdb-openldap-module to configure.
    * Configure OpenLDAP with `--enable-local' to enable the local
    * Add the hdb schema to the LDAP server, it's included in the
      source-tree in `lib/hdb/hdb.schema'. Example from slapd.conf:
           include /usr/local/etc/openldap/schema/hdb.schema
    * Configure the LDAP server ACLs to accept writes from clients over
      the local transport. For example:
           access to *
                   by dn.exact="uid=heimdal,dc=services,dc=example,dc=com" write
           authz-regexp "gidNumber=.*\\\+uidNumber=0,cn=peercred,cn=external,cn=auth''
      The sasl-regexp is for mapping between the SASL/EXTERNAL and a
      user in a tree.  The user that the key is mapped to should be have
      a krb5Principal aux object with krb5PrincipalName set so that the
      "creator" and "modifier" is right in `kadmin'.
      Another option is to create an admins group and add the dn to that
      Since Heimdal talks to the LDAP server over a UNIX domain socket,
      and uses external sasl authentication, it's not possible to require
      security layer quality (ssf in cyrus-sasl lingo). So that
      requirement has to be turned off in OpenLDAP `slapd' configuration
      file `slapd.conf'.
           sasl-secprops minssf=0
    *  Start `slapd' with the local listener (as well as the default
      TCP/IP listener on port 389) as follows:
               slapd -h "ldapi:/// ldap:///"
      Note: These is a bug in `slapd' where it appears to corrupt the
      krb5Key binary attribute on shutdown. This may be related to our
      use of the V3 schema definition syntax instead of the old
      UMich-style, V2 syntax.
    * You should specify the distinguished name under which your
      principals will be stored in `krb5.conf'. Also you need to enter
      the path to the kadmin acl file:
                   database = {
                           dbname = ldap:ou=KerberosPrincipals,dc=example,dc=com
                           hdb-ldap-structural-object = inetOrgPerson
                           acl_file = /path/to/kadmind.acl
                           mkey_file = /path/to/mkey
      `mkey_file' can be excluded if you feel that you trust your ldap
      directory to have the raw keys inside it.  The
      hdb-ldap-structural-object is not necessary if you do not need
      Samba comatibility.
    * Once you have built Heimdal and started the LDAP server, run kadmin
      (as usual) to initialise the database. Note that the instructions
      for stashing a master key are as per any Heimdal installation.
           kdc# kadmin -l
           kadmin> init EXAMPLE.COM
           Realm max ticket life [unlimited]:
           Realm max renewable ticket life [unlimited]:
           kadmin> ank lukeh
           Max ticket life [1 day]:
           Max renewable life [1 week]:
           Principal expiration time [never]:
           Password expiration time [never]:
           Attributes []:
           lukeh@EXAMPLE.COM's Password:
           Verifying password - lukeh@EXAMPLE.COM's Password:
           kadmin> exit
      Verify that the principal database has indeed been stored in the
      directory with the following command:
           kdc# ldapsearch -L -h localhost -D cn=manager \
            -w secret -b ou=KerberosPrincipals,dc=example,dc=com \
    * Now consider adding indexes to the database to speed up the
      access, at least theses should be added to slapd.conf.
           index	objectClass		eq
           index	cn			eq,sub,pres
           index	uid			eq,sub,pres
           index	displayName		eq,sub,pres
           index	krb5PrincipalName	eq
 4.16.1 smbk5pwd overlay
 The smbk5pwd overlay, updates the krb5Key and krb5KeyVersionNumber
 appropriately when it receives an LDAP Password change Extended
 4.16.2 Troubleshooting guide
 4.16.3 Using Samba LDAP password database
 The Samba domain and the Kerberos realm can have different names since
 arcfour's string to key functions principal/realm independent.  So now
 will be your first and only chance name your Kerberos realm without
 needing to deal with old configuration files.
 First, you should set up Samba and get that working with LDAP backend.
 Now you can proceed as in  Using LDAP to store the database.
 Heimdal will pick up the Samba LDAP entries if they are in the same
 search space as the Kerberos entries.
Info Catalog ( Setting up DNS ( Setting up a realm ( Providing Kerberos credentials to servers and programs
automatically generated byinfo2html