15. Appendix D: Using Kerberos authentication with slapd and slurpd.

Slapd and slurpd both support authentication using MIT's Kerberos 4 system, which is supported in the LDAP protocol as a stronger form of authentication than simple (clear-text password) authentication. This appendix describes how to configure slapd and slurpd to support Kerberos 4 authentication, and how to link Kerberos identities to directory entries. Note that some LDAP clients do not support Kerberos authentication.

15.1 Build the U-M LDAP Package with Kerberos Support Enabled

By default, Kerberos support is not included when you build slapd and slurpd as part of the U-M LDAP package. You will need to edit the Make-common file to enable Kerberos before you make the software. See section 4 above for instructions on building the LDAP package.

15.2 Using Kerberos with slapd

Follow these steps to configure slapd for Kerberos authentication.

15.2.1 Obtain a srvtab File for Your slapd Server

You will need to add your slapd server to your realm's Kerberos server and extract an appropriate srvtab (service key) file. This is typically done using MIT's kdb_edit and ext_srvtab utilities, and must be done by someone who has privileged access to the Kerberos database (the Kerberos administrator).

You will actually want to add two Kerberos entries for each slapd server: one with a name portion of ldapserver and one with a name portion of x500dsa. The second one is necessary because most LDAP clients that use Kerberos have no way of knowing that they are connected to a server that is not back-ended by an X.500 DSA, so they will try to authenticate in two steps, first using to the LDAP server and then to the X.500 DSA. slapd will ignore the second authentication step, but the LDAP clients will be unhappy if the x500dsa principal does not exist.

The instance portion of both principals needs to match the first part of the real name of the host on which you run slapd. LDAP clients will determine the real name of the slapd host by performing a reverse (gethostbyaddr-style or "in-addr.arpa") Domain Name Service lookup on the IP address of the slapd host, and then they will use the part to the left of the first dot (.) as the Kerberos instance name for the server.

For example, if an LDAP client is told to connect to the server on the host "d.rs.itd.umich.edu", it will perform a forward (gethostbyname-style) DNS lookup and open a TCP LDAP connection to IP address port 389. When doing Kerberos authentication, it will look up the hostname using the IP address and see that the real host name is terminator.rs.itd.umich.edu. Thus the Kerberos tickets (shown in name.instance@realm format) that the client will obtain and pass to slapd will be:

(assuming that "umich.edu" is your Kerberos realm). Both of these principals need to be added to the "umich.edu" Kerberos database, and a srvtab file would need to be extracted that contains their service keys.

15.2.2 Install the srvtab File and Tell slapd Where It Is

Place the srvtab file on the machine where you are going to run slapd and add a "srvtab" line to the slapd configuration file. The srvtab config. file option simply contains the full path to the "ldapserver/x500dsa" service key file obtained in the previous step (the default is /etc/srvtab if no srvtab option is specified). For example, assuming the srvtab is in a file called /etc/slapd.srvtab, this would be an appropriate slapd config. file line:
srvtab /etc/slapd.srvtab
If slapd is already running, you will need to kill and restart it to have slapd recognize the new option.

15.2.3 Add Kerberos Names to Entries to Enable Authentication

To authenticate as an entry in the directory using Kerbeors, the entry must contain one or more krbName (Kerberos Name) attributes that associate a Kerberos identity with the entry. Each krbName value should be a string of the form:
(the instance part is optional). For example, to allow the principal "bjensen" in the "umich.edu" Kerberos realm to authenticate to slapd as the entry "cn=Babs Jensen, o=University of Michigan, c=US", you could use the ldapmodify(1) tool (or another LDAP client) to add a krbName attribute to her entry that has the string value "bjensen@umich.edu". To do this, first you would first create a file called /tmp/modify with the contents:
cn=Babs Jensen, o=University of Michigan, c=US
and then use a command like this to actually make the change:
ldapmodify -f /tmp/modify -D "cn=Manager, o=University of Michigan, c=US" -w secret
Note that the above command assumes that you have set rootdn to "cn=Manager, o=University of Michigan, c=US" and rootpw to "secret" in your slapd configuration file.

You should now be able to authenticate to slapd as Bab's entry using Kerberos. For example, the following commands will authenticate using Kerberos and perform a search for all entries that have a surname of "Smith" while bound as Babs' entry and retrieve the commonName of each entry (text you would type is whown in bold):

kinit bjensen
University of Michigan (terminator.rs.itd.umich.edu)
Kerberos Initialization for "bjensen"

ldapseach -k -D " cn=Babs Jensen, o=University of
Michigan, c=US" sn=smith cn

15.2.4 Associate a Kerberos Name with the "rootdn" (optional)

If you want to use Kerberos to authenticate as the slapd rootdn (the special DN that is not subject to access control or administrative limits), you should add a rootkrbname directive to the slapd config. file. For example, if bjensen should have the ability to authenticate as the rootdn when she authenticates to Kerberos using an instance of "admin", you would include a line like this in the slapd config. file:
rootkrbname bjensen.admin@umich.edu

15.3 Using Kerberos With slurpd

Slurpd (the replication daemon) is capable of using Kerberos authentication when authenticating to the slave slapds that it is configured to serve. To enable this feature, follow these steps:

15.3.1 Obtain a srvtab File for Your slurpd Server

Create a Kerberos principal entry in your realm's Kerberos database for slurpd. The name and instance can be anything you like (unlike the "ldapserver" and "x500dsa" principals you must use for slapd). You will need to obtain and install a srvtab file that contains this slurpd Kerberos key (install it on the machine where slurpd will run). As mentioned above, you will need to contact your Kerberos administrator to get this file. For the examples that follow, we will assume that you have added a Kerberos database entry and obtained a srvtab file for the principal: slurpd.terminator@umich.edu and installed it in a file called /etc/slurpd.srvtab

15.3.2 Configure the slapd Slaves to Accept Kerberos Authentication

Each slapd slave must be compiled and configured to support Kerberos authentication (as discussed previously). In addition, the updatedn used by slurpd to authenticate when sending updates to the slaves must have a Kerberos Name associated with it that matches the slurpd srvtab file obtained in the previous step. This can be done as for any other entry simply by adding the appropriate krbName attribute value to the updatedn entry in slapd. If you happen to be using the rootdn as the updatedn, then you can just include an appropriate rootkrbname directive in the slapd config. file, e.g.,
rootkrbname slurpd.terminator@umich.edu

15.3.3 Configure slurpd to Use Kerberos When Connecting to the Slaves

You need to use a bindmethod of kerberos and specify the path to an appropriate srvtab file within the replica configuration file options. You will also need to specify the path to the srvtab file. E.g.,

replica host=slave1.umich.edu
"binddn=cn=Manager, o=University of Michigan, c=US"

Don't forget to restart both slurpd and the slapd slaves after making changes to the config. file(s).

[View Previous Section] [Return to Table of Contents]

Send comments about this page to: ldap-support@umich.edu