Next: Providing Kerberos credentials to servers and programs, Previous: Setting up DNS, Up: Setting up a realm
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.
Requirements:
--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 list.
Its also possible to configure the ldap backend as a shared module, see option –hdb-openldap-module to configure.
include /usr/local/etc/openldap/schema/hdb.schema
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'' "uid=heimdal,dc=services,dc=example,dc=com"
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 group.
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
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.
[kdc] 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.
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 \ 'objectclass=krb5KDCEntry'
index objectClass eq index cn eq,sub,pres index uid eq,sub,pres index displayName eq,sub,pres index krb5PrincipalName eq
The smbk5pwd overlay, updates the krb5Key and krb5KeyVersionNumber appropriately when it receives an LDAP Password change Extended Operation:
https://sec.miljovern.no/bin/view/Info/TroubleshootingGuide
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 See 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.