Integrated Kerberos-OpenLDAP provider on Debian lenny

This page describes how to set up an OpenLDAP provider server and an MIT Kerberos V master server on the same host so that Kerberos uses LDAP as its back-end database. This combines the excellent security and encryption offered by Kerberos with OpenLDAP's superior replication engine. It is a strategy that is made possible by a package that extends the OpenLDAP database schema to support Kerberos and provides a plugin for the Kerberos server to allow it to use an LDAP directory as its primary database.

In this example, OpenLDAP is installed on a host running Debian 5.0 (lenny). If followed properly, the step-by-step process should produce an OpenLDAP provider server with a new DIT, followed by a Kerberos master server that stores its database in that same DIT. The system also relies heavily on timestamps, so reasonably accurate time synchronization among all participating hosts is essential.

But, before the interesting parts can begin, it will first be necessary to install the operating system on a new host called kls1.example.com. A DNS server must also be available on the network with a zone file to which forward and reverse mappings can be added for this host, as well as an alias for it called kls.example.com. After the initial installation of the operating system, make sure these packages are installed on the system as well:

~# apt-get install ssh ntp ntpdate nmap

Afterwards, edit /etc/ntp.conf so that the machine synchronizes to a common NTP server (preferably a local one) and edit /etc/default/ntpdate to use the same host also. Now the installation of the new server can begin.

On the new host, kls1.example.com, start by installing these two packages:

~# apt-get install slapd ldap-utils

A total of ten packages are installed as a result, including eight dependencies:

ldap-utils                 2.4.11-1+lenny1             OpenLDAP utilities
libdb4.2                   4.2.52+dfsg-5               Berkeley v4.2 Database Libraries [runtime]
libltdl3                   1.5.26-4+lenny1             A system independent dlopen wrapper for GNU libtool
libperl5.10                5.10.0-19lenny2             Shared Perl library
libsasl2-modules           2.1.22.dfsg1-23+lenny1      Cyrus SASL - pluggable authentication modules
libslp1                    1.2.1-7.5                   OpenSLP libraries
odbcinst1debian1           2.2.11-16                   Support library and helper program for accessing odbc ini file
psmisc                     22.6-1                      Utilities that use the proc filesystem
slapd                      2.4.11-1+lenny1             OpenLDAP server (slapd)
unixodbc                   2.2.11-16                   ODBC tools libraries

During the install process, an administrator password will be requested for slapd. Use arietans:

Administrator password: arietans
Confirm password: arietans

Run the following command to test if the OpenLDAP server is actually running:

~# nmap kls1.example.com

This should be among the results:

PORT    STATE SERVICE
389/tcp open  ldap

Perform a quick test by generating an LDIF dump of the contents of a the database:

~# slapcat
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example
structuralObjectClass: organization
entryUUID: 30d98fe4-a7c9-102e-840e-698e4efaba8b
creatorsName:
createTimestamp: 20100207001215Z
entryCSN: 20100207001215.351650Z#000000#000#000000
modifiersName:
modifyTimestamp: 20100207001215Z

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e2NyeXB0fWJEaXNIcmtOVTkuRzY=
structuralObjectClass: organizationalRole
entryUUID: 30dcae36-a7c9-102e-840f-698e4efaba8b
creatorsName:
createTimestamp: 20100207001215Z
entryCSN: 20100207001215.372386Z#000000#000#000000
modifiersName:
modifyTimestamp: 20100207001215Z

~# _

Edit /etc/ldap/ldap.conf and use these two lines:

BASE    dc=example,dc=com
URI     ldap://kls1.example.com/

This configuration file is used to set system-wide defaults for LDAP clients.

Create a basic tree structure. First create a file, ~/tree.ldif, with the following content:

dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups

dn: ou=hosts,dc=example,dc=com
objectClass: organizationalUnit
ou: hosts

Add this information to the LDAP database using the ldapadd command:

~# ldapadd -xWD cn=admin,dc=example,dc=com -f ~/tree.ldif
Enter LDAP Password: arietans
adding new entry "ou=people,dc=example,dc=com"

adding new entry "ou=groups,dc=example,dc=com"

adding new entry "ou=hosts,dc=example,dc=com"

~# _

A quick ldapsearch should show the new objects:

~# ldapsearch -xLLL
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups

dn: ou=hosts,dc=example,dc=com
objectClass: organizationalUnit
ou: hosts

~#

On the new host, kls1.example.com, start by installing these three packages:

~# apt-get install krb5-{admin-server,kdc-ldap,user}

A total of six packages are installed as a result, including three dependencies:

krb5-admin-server          1.6.dfsg.4~beta1-5lenny2             MIT Kerberos master server (kadmind)
krb5-config                1.22                                 Configuration files for Kerberos Version 5
krb5-kdc                   1.6.dfsg.4~beta1-5lenny2             MIT Kerberos key server (KDC)
krb5-kdc-ldap              1.6.dfsg.4~beta1-5lenny2             MIT Kerberos key server (KDC) LDAP plugin
krb5-user                  1.6.dfsg.4~beta1-5lenny2             Basic programs to authenticate using MIT Kerberos
libkadm55                  1.6.dfsg.4~beta1-5lenny2             MIT Kerberos administration runtime libraries

During package installation, the default realm is automatically set to EXAMPLE.COM. A few questions are asked regarding the krb5-admin-server package that should be answered as follows:

Kerberos servers for your realm: kls1.example.com
Administrative server for your Kerberos realm: kls.example.com

Following this automated configuration sequence for the package, two problems appear. First, a comment is displayed to inform xinetd users that manual conversion to xinetd format is necessary for a hashed-out kpropd entry that has been added to /etc/inetd.conf. This is for the Kerberos V database propagation daemon, which in this scenario will not be used, so it can be ignored.

The second problem is that kadmind, the administration daemon, failed to start. This is because the realm, EXAMPLE.COM, or rather a database for it, has not yet been created; an issue that will be dealt with later.

Since the idea is for Kerberos to use OpenLDAP as its back-end database, see to it that the Kerberos KDC and administrative services start up after slapd by changing the names of the symbolic links for their respective startup scripts:

~# mv /etc/rc2.d/S18krb5-kdc /etc/rc2.d/S20krb5-kdc
~# mv /etc/rc2.d/S18krb5-admin-server /etc/rc2.d/S20krb5-admin-server
~# _

Edit /etc/krb5kdc/kadm5.acl and enable/add the following two lines:

*/admin *
admin *

This is to allow certain principals, admin and names ending in /admin, to perform any operation.

This version of Kerberos includes the V to IV ticket conversion daemon, krb524d. Unfortunately, it suffers from a type of bug, called a file descriptor leak, that manifests itself when running Kerberos together with an LDAP back-end. The bug causes slapd to slowly run out of file descriptors and eventually become unresponsive. Since it is unlikely that the Kerberos developers will address this problem (krb524d has been removed from current Kerberos V releases), a workaround is necessary. Create a file, called /usr/local/bin/slapd-check, with the following contents:

#!/bin/sh

PATH=/usr/bin:/bin

openfiles=`lsof |grep -c slapd` 

daemonactive=`ps ax |grep -c krb524d`

if [ $daemonactive -gt 0 ] && [ $openfiles -gt 100 ]; then

        killall krb524d
        krb524d -m
fi

exit 0

This script checks if krb524d is running, and if so, whether the number of files that slapd has open is greater than 100. If both these tests are true, only krb524d is killed and restarted.

Make the new script executable:

~# chmod 750 /usr/local/bin/slapd-check

Finally, have cron (crontab -e) run this script every fifteen minutes:

*/15 * * * * /usr/local/bin/slapd-check

Unzip and copy the Kerberos schema file to the OpenLDAP server's schema directory:

~# gunzip -c /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz > \
   /etc/ldap/schema/kerberos.schema

Edit /etc/ldap/slapd.conf and make a number of changes to it. Starting at the top of the file, add a line to include support for the Kerberos schema in the DIT:

# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/kerberos.schema

Comment out the logging option, which will return it to its default value (256):

#loglevel "none"

Later on, after the configuration is finished and the whole system is working properly, it will likely be desirable to once again return the loglevel value to "none", because Kerberos tends to cause a lot of slapd log output (at least once every minute) as it accesses its back-end database. This level of logging may also affect performance.

Add these two index directives for the uid and krb5principalname attributes:

index           objectClass eq
index           uid eq
index           krbPrincipalName eq,pres,sub

The first eq index will facilitate searches for uid entries, while the second will do the same for Kerberos principal entries. Both will speed up the login process.

Last, modify the ACLs to look like this:

access to attrs=userPassword,shadowLastChange
        by dn="cn=admin,dc=example,dc=com" write
        by anonymous auth
        by * none

access to dn.subtree="ou=krb5,dc=example,dc=com"
        by dn="cn=admin,dc=example,dc=com" write
	by dn="cn=adm-srv,ou=krb5,dc=example,dc=com" write
	by dn="cn=kdc-srv,ou=krb5,dc=example,dc=com" read
	by * none

access to attrs=loginShell
	by dn="cn=admin,dc=example,dc=com" write
        by self write
	by users read
        by * none

access to dn.base=""
	by * read

access to *
	by dn="cn=admin,dc=example,dc=com" write
	by users read
	by * none

Edit /etc/default/slapd and allow the LDAP service to listen for IPC connections (i.e. Unix domain sockets) by adding this line to the end of the file:

SLAPD_SERVICES="ldap:/// ldapi:///"

This will instruct slapd to listen on IPC, instead of only TCP port 389, which is the default.

Having saved these changes, restart the LDAP service:

~# /etc/init.d/slapd restart
Stopping OpenLDAP: slapd.
Starting OpenLDAP: slapd.
~# _

Edit the Kerberos realm configuration file, /etc/krb5.conf. This file is initially created by the Debian installer and contains information about the realms of a number of famous institutions, but none of that is necessary in this case. Instead, replace its contents with this:

[libdefaults]
	default_realm = EXAMPLE.COM
	forwardable = true
	proxiable = true

[realms]
	EXAMPLE.COM = {
		kdc = kls1.example.com
		admin_server = kls.example.com
		database_module = openldap_ldapconf
	}

[domain_realm]
	.example.com = EXAMPLE.COM
	example.com = EXAMPLE.COM

[dbdefaults]
	ldap_kerberos_container_dn = ou=krb5,dc=example,dc=com

[dbmodules]
	openldap_ldapconf = {
		db_library = kldap
		ldap_kdc_dn = cn=kdc-srv,ou=krb5,dc=example,dc=com
		ldap_kadmind_dn = cn=adm-srv,ou=krb5,dc=example,dc=com
		ldap_service_password_file = /etc/krb5kdc/service.keyfile
		ldap_conns_per_server = 5
	}

[logging]
	kdc = FILE:/var/log/krb5/kdc.log
	admin_server = FILE:/var/log/krb5/kadmin.log
	default = FILE:/var/log/krb5/kadmin.log

See this section for a more detailed explanation of this file.

Note the absence of the ldap_servers statement from the list of openldap_ldapconf options. This is possible because the Kerberos daemons use IPC to connect to the LDAP back-end by default, while slapd was configured to support IPC in the previous step.

After /etc/krb5.conf has been saved, create the Kerberos log directory:

~# mkdir /var/log/krb5
~# _

To prevent the log files from growing too large, create a pair of logrotate configuration files. First, edit /etc/logrotate.d/krb5-kdc and give it the following contents:

/var/log/krb5/kdc.log {
	daily
	missingok
	rotate 7
	compress
	delaycompress
	notifempty
	postrotate
		/etc/init.d/krb5-kdc restart > /dev/null
	endscript
}

Then edit /etc/logrotate.d/krb5-kadmin and give it this slightly different configuration:

/var/log/krb5/kadmin.log {
	daily
	missingok
	rotate 7
	compress
	delaycompress
	notifempty
	postrotate
		/etc/init.d/krb5-admin-server restart > /dev/null
	endscript
}

Create the entries mentioned in the /etc/krb5.conf file that will support the new Kerberos server. First create a file, ~/krb5.ldif, with the following contents:

dn: ou=krb5,dc=example,dc=com
ou: krb5
objectClass: organizationalUnit

dn: cn=kdc-srv,ou=krb5,dc=example,dc=com
cn: kdc-srv
objectClass: simpleSecurityObject
objectClass: organizationalRole
description: Default bind DN for the Kerberos KDC server
userPassword: gabonica

dn: cn=adm-srv,ou=krb5,dc=example,dc=com
cn: adm-srv
objectClass: simpleSecurityObject
objectClass: organizationalRole
description: Default bind DN for the Kerberos Administration server
userPassword: nasicornis

Although the last two of these entries require only simple authentication (clear-text passwords), this is not an issue because, as opposed to using the network, only IPC will be used during the authentication of these accounts. After saving ~/krb5.ldif, add the new objects to the DIT with this command:

~# ldapadd -xWD cn=admin,dc=example,dc=com -f ~/krb5.ldif
Enter LDAP Password: arietans
adding new entry "ou=krb5,dc=example,dc=com"

adding new entry "cn=kdc-srv,ou=krb5,dc=example,dc=com"

adding new entry "cn=adm-srv,ou=krb5,dc=example,dc=com"

~# _

To create the new realm, as opposed to the krb5_newrealm command, use kdb5_ldap_util:

~# kdb5_ldap_util -D cn=admin,dc=example,dc=com \
   -H ldap://kls1.example.com create -r EXAMPLE.COM -s
Password for "cn=admin,dc=example,dc=com": arietans
Initializing database for realm 'EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: parviocula
Re-enter KDC database master key to verify: parviocula
~# _

Use the slapcat command to verify the creation of the new database.

Passwords are needed for the two Kerberos services to access the Kerberos database in LDAP DIT. These passwords will be stashed in a file called /etc/krb5kdc/service.keyfile. First, create the stash for the KDC service, represented by the cn=kdc-srv object and referred to in /etc/krb5.conf with the ldap_kdc_dn option:

~# kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw \
   -f /etc/krb5kdc/service.keyfile cn=kdc-srv,ou=krb5,dc=example,dc=com
Password for "cn=admin,dc=example,dc=com": arietans
Password for "cn=kdc-srv,ou=krb5,dc=example,dc=com": gabonica
Re-enter password for "cn=kdc-srv,ou=krb5,dc=example,dc=com": gabonica
~# _

Then create a stash for the Kerberos administration server, represented by the cn=adm-srv object and referred to in /etc/krb5.conf with the ldap_kadmind_dn option:

~# kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw \
   -f /etc/krb5kdc/service.keyfile cn=adm-srv,ou=krb5,dc=example,dc=com
Password for "cn=admin,dc=example,dc=com": arietans
Password for "cn=adm-srv,ou=krb5,dc=example,dc=com": nasicornis
Re-enter password for "cn=adm-srv,ou=krb5,dc=example,dc=com": nasicornis
~# _

Start up the local administrative interface for the new Kerberos database and create a principal for the admin user:

~# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc admin
WARNING: no policy specified for admin@EXAMPLE.COM; defaulting to 
no policy
Enter password for principal "admin@EXAMPLE.COM": arietans
Re-enter password for principal "admin@EXAMPLE.COM": arietans
Principal "admin@EXAMPLE.COM" created.
kadmin.local:  _

Still in the local Kerberos administrative interface, use it now to allow more flexible lifetime and renewal time frames for the ticket granting ticket (TGT) service. The commands and their responses should look like this:

kadmin.local:  modprinc -maxlife "1 day" -maxrenewlife "90 day" \
               krbtgt/EXAMPLE.COM@EXAMPLE.COM
Principal "krbtgt/EXAMPLE.COM@EXAMPLE.COM" modified.
kadmin.local:  q
~# _

The values entered above are instead of 10 hours and 1 day respectively, which are the default values. However, every organization should use values that best suit their own security needs. As for kadmin.local, this is a fail-safe version of the kadmin tool that can only be used on the KDC as root and requires no password to modify the database directly. The kadmin tool, on the other hand, can be used from anywhere on the network.

Now edit /etc/krb5kdc/kdc.conf and modify these two lines to reflect the changes made above:

        max_life = 1d 0h 0m 0s
        max_renewable_life = 90d 0h 0m 0s

Start the Kerberos admin and KDC servers for the first time:

~# /etc/init.d/krb5-admin-server start ; /etc/init.d/krb5-kdc start
~# _

If there are no errors, run the following command to verify that the new MIT Kerberos V master server is indeed available on the network:

~# nmap -sT -sU kls1.example.com

This should be among the results:

PORT     STATE         SERVICE
749/tcp  open          kerberos-adm
88/udp   open|filtered kerberos-sec
464/udp  open          kpasswd5
750/udp  open|filtered kerberos
4444/udp open|filtered krb524

Use kadmin to create a Kerberos principal for the LDAP service and a matching keytab file by issuing a few commands:

~# kadmin -p admin
Authenticating as principal admin with password.
Password for admin@EXAMPLE.COM: arietans
kadmin:  addprinc -randkey ldap/kls1.example.com
WARNING: no policy specified for ldap/kls1.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "ldap/kls1.example.com@EXAMPLE.COM" created.
kadmin:  ktadd ldap/kls1.example.com
Entry for principal ldap/kls1.example.com with kvno 3, encryption type
AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab
WRFILE:/etc/krb5.keytab.
Entry for principal ldap/kls1.example.com with kvno 3, encryption type
ArcFour with HMAC/md5 added to keytab
WRFILE:/etc/krb5.keytab.
Entry for principal ldap/kls1.example.com with kvno 3, encryption type
Triple DES cbc mode with HMAC/sha1 added to keytab
WRFILE:/etc/krb5.keytab.
Entry for principal ldap/kls1.example.com with kvno 3, encryption type
DES cbc mode with CRC-32 added to keytab
WRFILE:/etc/krb5.keytab.
kadmin:  q
~# _

The -randkey switch is used because a machine cannot enter a password. To list the keys in /etc/krb5.keytab, use the klist -ke command. A host (or service) principal and a keytab file should be created for and saved on all of the various client machines that are part of a Kerberos realm.

To kerberize slapd, start by installing this package:

~# apt-get install libsasl2-modules-gssapi-mit

Only one package is installed as a result:

libsasl2-modules-gssapi-mit      2.1.22.dfsg1-23+lenny1      Cyrus SASL - pluggable authentication modules (GSSAPI)

GSSAPI stands for Generic Security Service API. Defined in RFC-2743, it provides a common interface for accessing different security services, one of the most popular of which is Kerberos V. The way that GSSAPI services can be used for SASL authentication and the establishment of a security layer is described in RFC-2222 (Simple Authentication and Security Layer).

Change the permissions and ownership of the Kerberos keytab file to make sure that slapd can access it:

~# chmod 640 /etc/krb5.keytab
~# chown root.openldap /etc/krb5.keytab
~# _

Edit /etc/default/slapd and uncomment a line near the end of the file that will export the location of the Kerberos system keytab file as a variable:

export KRB5_KTNAME=/etc/krb5.keytab

Edit /etc/ldap/ldap.conf and add the following line to the end of the file to specify the authentication mechanism:

SASL_MECH GSSAPI

Now to configure the link that maps GSSAPI-format user names to LDAP names. Once users have been authenticated by Kerberos and have valid Kerberos tickets, the SASL layer redirects them to the GSSAPI mechanism. This results in distinguished names that consist of four parts:

1. uid=user_name
2. cn=realm_name
3. cn=gssapi
4. cn=auth

For instance, the Kerberos admin account becomes cn=admin,cn=example.com,cn=gssapi,cn=auth. The key is to match these GSSAPI-format names to ones that can be used together with the LDAP DIT. This is done by adding one or more authz-regexp directives to /etc/ldap/slapd.conf, which includes regular expressions. Modify this file by adding three such directives to the end of the Global directives section:

tool-threads 1

authz-regexp
     uid=admin,cn=example.com,cn=gssapi,cn=auth
     cn=admin,dc=example,dc=com

authz-regexp
     uid=host/([^/\.]+).example.com,cn=example.com,cn=gssapi,cn=auth
     cn=$1,ou=hosts,dc=example,dc=com

authz-regexp
     uid=([^,]+),cn=example.com,cn=gssapi,cn=auth
     uid=$1,ou=people,dc=example,dc=com

The three authz-regexp directives shown here are each followed by two options: a search pattern that matches one or more of the GSSAPI-format user names from the Kerberos database, and a replacement pattern that changes each name to a format that is compatible with the DIT, usually with the intention to match an existing LDAP entry.

The first of these authz-regexp directives is a specific match for the admin user, the second one matches names that begin with "host/" and changes them to DNs found in ou=hosts, while the third matches all other names and changes them to DNs found in ou=people. These are all examples of direct mapping, which is the generally recommended approach; it not only avoids the expense of searching for user DNs, but also allows mapping to DNs that do not have matching LDAP entries.

The drawback of direct mapping is that it only maps to a single organizational unit. To map to more than one organizational unit, use authz-regexp statements with LDAP URLs, which are referred to as search-based mappings. For instance, consider this stanza:

authz-regexp
	uid=([^,]+),cn=example.com,cn=gssapi,cn=auth
	ldap:///dc=example,dc=com??sub?php
	   (&
	      (|
	         (entryDN:dnSubtreeMatch:=ou=people,dc=example,dc=com)
	         (entryDN:dnSubtreeMatch:=ou=robots,dc=example,dc=com)
	      )
	      (&
		 (uid=$1)
	         (objectclass=person)
	      )
	   )

Note that, unlike the format used here for the sake of clarity, LDAP search URLs must always be written on a single line and without any of the extra spacing! In this example, the search pattern matches all GSSAPI-format names as before, but the replacement pattern searches two organizational units, people and robots, for matching LDAP user names. Unfortunately, this flexibility comes at a price, since it is slower than direct mapping, and it will not map GSSAPI names if no matching LDAP counterparts are found.

Anyway, still editing /etc/ldap/slapd.conf, add this directive, which specifies the Kerberos realm, to the end of the Global section, just below the last authz-regexp statement:

authz-regexp
     uid=([^,]+),cn=example.com,cn=gssapi,cn=auth
     uid=$1,ou=people,dc=example,dc=com

sasl-realm EXAMPLE.COM

This is important, because without it the authz-regexp mechanism will not work.

Having saved the above changes, restart the LDAP service:

~# /etc/init.d/slapd restart
Stopping OpenLDAP: slapd.
Starting OpenLDAP: slapd.
~# _

Run some tests. First try a simple unauthenticated (-x) LDAP query:

~# ldapsearch -xLLL ou=people
No such object (32)
~# _

This does not work, because the default ACL has been set to "allow access to * by none" in slapd.conf. The authenticated version of this query, which is its default operational mode, will also give an error:

~# ldapsearch -LLL ou=people
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
~# _

The solution is to first acquire a Kerberos ticket for the admin user (password arietans):

~# kinit admin
Password for admin@EXAMPLE.COM: arietans
~# _

A verification of the ticket should show a success:

~# klist -5
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@EXAMPLE.COM

Valid starting     Expires            Service principal
02/07/10 04:28:17  02/08/10 04:28:17  krbtgt/EXAMPLE.COM@EXAMPLE.COM
~# _

Now the previously attempted authenticated query should work:

~# ldapsearch -LLL ou=people
SASL/GSSAPI authentication started
SASL username: admin@EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

~# _

Also, under these circumstances the ldapwhoami command behaves more like whoami:

~# whoami
root
~# ldapwhoami
SASL/GSSAPI authentication started
SASL username: admin@EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
dn:cn=admin,dc=example,dc=com
~# _

Authentication is now necessary for all LDAP commands, but thanks to Kerberos' single-sign-on technology this is hardly an inconvenience.

Having verified that Kerberos authentication is now working for the admin user, it should be noted that this entry's original LDAP password is still available for use:

~# ldapsearch -xWLLL -D cn=admin,dc=example,dc=com ou=people
Enter LDAP Password: arietans
dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

~# _

Remember that when using simple authentication the passwords are sent as plain text. When this happens over the network it represents a potential security hazard − especially in the case of the admin account. Therefore, this password should be disabled. To do this, create a new file, called ~/admin-pw.ldif, with the following contents:

dn: cn=admin,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: {CRYPT}*
-

This modification will change the admin password to an invalid hash. Apply it with the ldapmodify command:

~# ldapmodify -f ~/admin-pw.ldif
SASL/GSSAPI authentication started
SASL username: admin@EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
modifying entry "cn=admin,dc=example,dc=com"

~# _

As a result, the former search command using simple authentication will no longer work:

~# ldapsearch -xWLLL -D cn=admin,dc=example,dc=com ou=people
Enter LDAP Password: arietans
ldap_bind: Invalid credentials (49)
~# _

• Integrated Kerberos-OpenLDAP consumer on Debian lenny
• Integrated Kerberos-OpenLDAP client on Debian lenny
• Integrated Kerberos-OpenLDAP provider on Debian squeeze

• Eastlake D, Panitz A. 1999. RFC2606 − Reserved Top Level DNS Names. The Internet Society. HTML at the Internet FAQ Archives.
• Hodges J, Morgan R. 2002. RFC3377 − Lightweight Directory Access Protocol (v3): Technical Specification. The Internet Society. HTML at the Internet FAQ Archives.
• Kohl J, Neuman C. 1993. RFC1510 − The Kerberos Network Authentication Service (V5). HTML at the Internet FAQ Archives.
• Linn J. 2000. RFC2743 − Generic Security Service Application Program Interface Version 2, Update 1. The Internet Society. HTML at the Internet FAQ Archives.
• Myers J. 1997. RFC2222 − Simple Authentication and Security Layer (SASL). The Internet Society. HTML at the Internet FAQ Archives.
• Wahl M, Howes T, Kille S. 1997. RFC2251 − Lightweight Directory Access Protocol (v3). The Internet Society. HTML at the Internet FAQ Archives.
• Wray J. 2000. RFC2744 − Generic Security Service API Version 2 : C-bindings. The Internet Society. HTML at the Internet FAQ Archives.
• Yeong W, Howes T, Kille S. 1993. RFC1487 − X.500 Lightweight Directory Access Protocol. The Internet Society. HTML at the Internet FAQ Archives.

• Carter G. 2003. LDAP System Administration. O'Reilly & Associates, Inc. ISBN 1-56592-491-6. 294 pp.
• Massachusetts Institute of Technology. 1985-2007. Kerberos V5 System Administrator's Guide. HTML at the Massachusetts Institute of Technology (MIT). See section 6: Configuring Kerberos with OpenLDAP back-end.
• Milicchio F, Gehrke WA. 2007. Distributed Services with OpenAFS. Springer-Verlag. ISBN-13 978-3-540-36633-1. 395 pp.
• OpenLDAP Project. 2009. OpenLDAP Software 2.4 Administrator's Guide. HTML at OpenLDAP.
• Ubuntu documentation. Ubuntu 9.04. Ubuntu Server Guide, Network Authentication, Kerberos and LDAP. HTML at the Ubuntu 9.04 Server Guide.