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.
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.
Follow these steps to configure slapd for Kerberos authentication.
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 141.211.164.2 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:
ldapserver.terminator@umich.edu
and
x500dsa.terminator@umich.edu
(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.
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.
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:
principal.instance@realm
(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
krbName=bjensen@umich.edu
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"
Password:secret
ldapseach
-k -D " cn=Babs Jensen, o=University of
Michigan, c=US"
sn=smith cn
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
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:
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
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
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"
bindmethod=kerberos
srvtab=/etc/slurpd.srvtab
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