Next: Providing Kerberos credentials to servers and programs, Previous: Setting up DNS, Up: Setting up a realm [Contents]
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.
If a non-local LDAP connection is used, the authz-regexp is not needed as Heimdal will bind to LDAP over the network using provided credentials.
Since Heimdal talks to the LDAP server over a UNIX domain socket when
configured for ldapi:///, 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
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.
[kdc] # Optional configuration hdb-ldap-structural-object = inetOrgPerson hdb-ldap-url = ldapi:/// (default), ldap://hostname or ldaps://hostname hdb-ldap-secret-file = /path/to/file/containing/ldap/credentials hdb-ldap-start-tls = false database = { dbname = ldap:ou=KerberosPrincipals,dc=example,dc=com 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.
If connecting to a server over a non-local transport, the ‘hdb-ldap-url’ and ‘hdb-ldap-secret-file’ options must be provided. The ‘hdb-ldap-secret-file’ must contain the bind credentials:
[kdc] hdb-ldap-bind-dn = uid=heimdal,dc=services,dc=example,dc=com hdb-ldap-bind-password = secretBindPassword
The ‘hdb-ldap-secret-file’ and should be protected with appropriate file permissions
kdc# kadmin -l kadmin> init EXAMPLE.COM Realm max ticket life [unlimited]: Realm max renewable ticket life [unlimited]: kadmin> add 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.
Next: Providing Kerberos credentials to servers and programs, Previous: Setting up DNS, Up: Setting up a realm [Contents]