(heimdal.info.gz) Using LDAP to store the database
Info Catalog
(heimdal.info.gz) Setting up DNS
(heimdal.info.gz) Setting up a realm
(heimdal.info.gz) 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.
Requirements:
* 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
list.
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
transport.
* 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''
"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
* 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:
[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.
* 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 \
'objectclass=krb5KDCEntry'
* 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
Operation:
`http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/smbk5pwd/README?hideattic=1&sortbydate=0'
4.16.2 Troubleshooting guide
----------------------------
`https://sec.miljovern.no/bin/view/Info/TroubleshootingGuide'
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
(heimdal.info.gz) Setting up DNS
(heimdal.info.gz) Setting up a realm
(heimdal.info.gz) Providing Kerberos credentials to servers and programs
automatically generated byinfo2html