Integrating LDAP and Kerberos: Part Two (LDAP)

Juliet Kemp explains how to install and configure LDAP, and get it working with Kerberos, to provide a powerful solution for secure authentication.

In the first installment we covered setting up Kerberos. Now it’s time to set up LDAP and ensure that it works happily ever after with Kerberos.


OpenSSL enables you to run a secure LDAP server (over ldaps:/// on port 636). The relevant Debian packages are libssl-dev, openssl, ca-certificates, and libssl0.9.8.

To generate a self-signed certificate:

  1. First generate a certificate authority:
  2. cd /etc/ssl
    /usr/lib/ssl/misc/CA.sh -newca

    The CN asked for here must be the FQDN of the LDAP server. Do not use the “challenge password” attribute, but do set the PEM passphrase (and remember it!).

  3. Create the certificate:
    openssl req -new -x509 -nodes -out newreq.pem -keyout newreq.pem -days 365

    The -nodes switch is important in order to create an unencrypted certificate, so that it will work with LDAP. Again, when asked for the CN, it needs to be the FQDN (fully qualified domain name) of your server, e.g. ldapserver.example.com.

  4. Sign the certificate:
    /usr/lib/ssl/misc/CA.sh -signcert

    Again, do not use a challenge password. The new certificate will be in newcert.pem. (Note: this script looks for the file newreq.pem and signs that; if you have used another file in the certificate creation you will need to rename or copy it.)

If you want Verisign or another Certificate Authority to sign your certificate, the process is easier — you only need step 2, and should leave out the -x509 switch. Check the instructions from your CA as to what you should do with the certificate request.

Once LDAP is installed, you will move the certificate files to the LDAP directory as explained below.

LDAP server setup

The Debian packages you need are libldap2, slapd, ldap-utils, libdb3-dev, and libdb3 (these last two provide the BerkeleyDB database backend). Set the admin password when asked during dpkg-configure.

To use SASL correctly, you need to put the certificates generated above in the correct places:

    mv /etc/ssl/newcert.pem /etc/ldap/servercrt.pem
    mv /etc/ssl/newreq.pem /etc/ldap/serverkey.pem
    mv /etc/ssl/demoCA/cacert.pem /etc/ldap/cacert.pem
    chmod go-r /etc/ldap/serverkey.pem
    chown openldap /etc/ldap/serverkey.pem
    chmod a+r /etc/ldap/servercrt.pem

Edit /etc/default/slapd to include these lines:


LDAP configuration

To use LDAP with Kerberos, you need to get a copy of krb5-kdc.schema and put it in /etc/ldap/schema/.

Edit /etc/ldap/slapd.conf:

include         /etc/ldap/schema/krb5-kdc.schema
include         /etc/ldap/schema/openldap.schema

# ... other things that can stay as provided ...

TLSCACertificateFile    /etc/ldap/cacert.pem
TLSCertificateFile      /etc/ldap/servercrt.pem
TLSCertificateKeyFile   /etc/ldap/serverkey.pem

# ... other things that can stay as provided ...

# this section rewrites principals as needed for Kerberos authentication
authz-policy from
sasl-realm      EXAMPLE.COM
sasl-host       ldapserver.example.com

include         /etc/ldap/slapd.access

# ... rest of file ...

Edit /etc/ldap/slapd.access to set your permissions. I’ve provided a basic example; you can complicate it about as much as you want!

# Everyone can read everything
access to dn.base="" by * read

# The admin dn has full write access
access to *
        by dn="uid=ldapadm,ou=people,dc=example,dc=com" write
        by * read

# Temporary lines to allow initial setup
rootdn "cn=admin,dc=example,dc=com"
rootpw secret

Note that you must not have comment lines between the ‘access’ and ‘by’ lines in this file, or it won’t work.

The ACLs should also go before the database backend definitions (so they apply globally) — this means that the include slapd.access line in /etc/ldap/slapd.conf must occur before the database backend definitions.

Put this line in /etc/ldap/ldap.conf:

TLS_REQCERT      allow

This allows clients to request the TLS server certificate from the server, thus saving you having to copy it everywhere.

If you need it, there is more config information for TLS/SSL in the OpenLDAP FAQ.

To separate out the slapd logs from the general systems logging, edit /etc/syslog.conf and add the following line:

local4.* /var/log/slapd.log

LDAP and Kerberos

Add the LDAP server to kerberos, by running kadmin -p krbadm from the LDAP host, and executing these commands:

addprinc -randkey ldap/server.example.com
ktadd -k /etc/ldap/ldap.keytab ldap/server.example.com

You should extract the server key to a keytab other than the system one at /etc/krb5.keytab (this is what the -k flag does), since the LDAP keytab must be owned by the LDAP user. Change the file ownership appropriately.

You also need to ensure that slapd is looking at this keytab. Add the following line to /etc/default/slapd:

export KRB5_KTNAME=/etc/ldap/ldap.keytab

Now, restart slapd.

If there are problems with startup, change the log level in /etc/ldap/slapd.conf to 16383 to get verbose logging in the log file. Change it back before you go into production, as verbose logging makes the server very slow.

Setting up the database

To set up the database, you first use the authentication in the rootdn and rootpw directives, to add the root entry, the People group, and an admin user (e.g. ldapadm — you should have added this user when you set up Kerberos).

For this you need to create a “setup” LDIF file (setup.ldif). You need to choose your base domain, which will depend on your organization. It’s a good idea to use a base domain that is related to your Kerberos domain and also to your IP domain. Here we use dc=example,dc=com.

# setup.ldif
dn: dc=example,dc=com
objectclass: organization
objectclass: dcObject
objectclass: top
o: Example Company
dc: example
description: root entry

dn: ou=people,dc=example,dc=com
objectclass: organizationalUnit
ou: people
description: Users

dn: uid=ldapadm,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: LDAP admin account
uid: ldapadm
uidNumber: 1002
gidNumber: 100
homeDirectory: /etc/ldap
loginShell: /bin/false

Note that the LDAP user cannot log in directly.

To add this, use ldapadd:

ldapadd -x -D "cn=admin,dc=ph,dc=ic,dc=ac,dc=uk" -W -f setup.ldif

-W is the option which causes the password to be demanded, -x uses an anonymous bind.

After this, edit /etc/ldap/slapd.conf again to remove the rootdn and rootpw entries. From now on you can authenticate as the ldapadm user to add or modify entries. Restart slapd.


Before you fully populate the database, it’s time to check that it works. Try the below, first from the server. Once that’s working, set up a client (see below) and try it from there.

  • ldapsearch -x -H ldaps://server.example.com (The -x option gives a simple bind.)
  • ldapsearch -x -H ldaps://server.example.com -ZZ -TLS (This test TLS startup.)
  • kinit username; ldapsearch -H ldaps://server.example.com (This to test kerberos auth.)

Troubleshooting notes:

  • Add -d 16383 to the ldapsearch line to enable copious debugging output.

  • Check the permissions on /etc/ldap/cacert.pem — it needs to be world-readable.

  • Check /etc/hosts if the hostname is resolving incorrectly (this will show up in the debugging output — your client needs to be trying server.example.com, not just server).

  • If you get the error “Key version for principal in keytable is incorrect”, there is a mismatch between the kerberos keytab and the master server. On the LDAP host, run kadmin -p krbadm and execute the following:

    ktrem ldap/server.example.com
    delprinc ldap/server.example.com
    addprinc -randkey ldap/server.example.com
    ktadd ldap/server.example.com

  • If you get the error “GSSAPI Error: Miscellaneous failure (Permission denied)”, check that the LDAP keytab is readable by the ldap user, and that slapd is looking at the correct keytab. You can test this quickly by also adding ldap/server.example.com to the system keytab at /etc/krb5.keytab and making that world-readable. If that starts things working then your keytab may be the problem. Remember to change it back to root-only afterwards!

  • Note that having high levels of debugging will slow things down dramatically — turn debugging off or down once things are working. If you are not getting errors, but ldapsearch appears to be hanging, try reducing the log levels in /etc/ldap/slapd.conf and restarting slapd.

Populating the LDAP database

You have many options to populate the database. If you already have users, you’ll want to migrate your data — PADL provide tools (the migrationtools package on Debian). This works fine for regular Unix setup (/etc/passwd, /etc/shadow, /etc/groups), and also for NIS. With some adjustment it will also work for NIS+.

You will, however, need to migrate your passwords to Kerberos by hand. This may be a good time to make everyone change their passwords.

To import an existing database: stop slapd, run slapadd -l existing_database.ldif, and restart slapd (where existing_database.ldif is an LDIF dump of an existing database).

You may need to empty the database first: do this by stopping slapd and removing the contents of the database directory — this is specified in /etc/ldap/slapd.conf by the directory directive.

Remove the rootdn and rootpw entries from slapd.conf, then start and stop slapd again before importing the database. If you have startup problems, check that the database directory is owned by the LDAP user (openldap on Debian).

Finally, you need to make sure that you have no password references in your user database — Kerberos will be handling passwords for you, and the easiest way to make this happen is simply to remove all password references from LDAP.

Run kinit ldapadm, and then use ldapsearch to get the attributes for any user: for example, to search for a user named “jkemp” you’d use ldapsearch ("uid=jkemp"). Look for any password attributes. Then for any individual user, you can create the following ldapmodify file:

dn: cn=username,ou=People,dc=example,dc=com
changetype: modify
delete: userPassword

Replace userPassword as appropriate. Then run ldapmodify -f modifyfile. You can put multiple users in the same file: use the same syntax as above, but separate each instance with a blank line.

Alternatively you can of course edit any data migration tool so as not to take the password data.

Client setup

You’ll need the following packages: ldap_utils, libnss-ldap, autofs-ldap (if you use automount), and nscd.

After installing the packages, edit /etc/nsswitch.conf as follows:

passwd:     compat files ldap
shadow:     compat files ldap
group:      compat files ldap

hosts:      files dns

services:   db files ldap [NOTFOUND=return]
networks:   db files ldap [NOTFOUND=return]
protocols:  db files ldap [NOTFOUND=return]
rpc:        db files ldap [NOTFOUND=return]
ethers:     db files ldap [NOTFOUND=return]

automount:  files

It’s important that compat and files entries appear before ldap for passwd, shadow, and group — otherwise if your LDAP server fails (or the client connection to it does) you won’t be able to log in at all. You can use ldap for hosts as well if you prefer.

Edit /etc/libnss-ldap.conf so that the only lines uncommented are:

base dc=example,dc=com
uri ldaps://ldapserver.example.com
ldap_version 3

Edit /etc/ldap/ldap.conf as follows — some of these may be auto-filled from installation questions.

BASE    dc=example,dc=com
URI     ldaps://ldapserver.example.com

The last line enables the client to request the server’s certificate, and saves you installing it on every client.

To set up automount to read from LDAP, you need the autofs-ldap package. Note that you want to use files in /etc/nsswitch.conf (as above) rather than ldap — this seems more reliable. Edit /etc/auto.master as follows:

/home   ldap:nisMapName=auto_home,dc=example,dc=com

Customize as appropriate for your setup. Here the dn uses nisMapName, which is for automounts which were converted from NIS+. You can also use automountMapName.

To test your setup, try the following on the client:

ldapsearch -d 1 -x

You should see the TLS info at the top and bottom of the debug output (generated with the -d 1 flag). If you have any problems, try specifying the server with -H ldaps://ldapserver.example.com — if this works, check the values in /etc/ldap/ldap.conf.

Finally, test that Kerberos auth is working by typing kinit, then ldapsearch (i.e. without the -x simple bind option).

Now you’re there!

Using LDAP

The basic LDAP commands are ldapadd, ldapmodify, and ldapdelete. Execute kinit ldapadm before any of these, to authenticate yourself.

  • ldapadd:
    • ldapadd -f newuser.ldif

    • newuser.ldif could look like this:

      dn: uid=username,ou=People,dc=example,dc=com
      uid: username
      objectClass: account
      objectClass: posixAccount
      objectClass: top
      objectClass: shadowAccount
      loginShell: /bin/tcsh
      uidNumber: userid
      gidNumber: groupid
      homeDirectory: /home/username
      gecos: Real Name
      cn: Real Name
      dn: cn=username,nisMapName=auto_home,dc=example,dc=com
      objectClass: nisObject
      cn: username
      nisMapEntry: server:/export/home/username
      nisMapName: auto_home

      This would create both a user entry, and an entry for the autofs map to set up their home directory. Note the blank line between the two entries.

  • ldapsearch:
    • ldapsearch "(uid=username)"
  • ldapmodify (again you need to authenticate first):
    • ldapmodify < modify_file
    • Example of modify_file:

      dn: uid=jkemp,ou=People,dc=example,dc=com
      changetype: modify
      replace: loginShell
      loginShell: /bin/bash

      This would change the user’s login shell to /bin/bash.

    • Another example, which adds a field:

      dn: uid=jkemp,ou=People,dc=example,dc=com
      changetype: add
      add: emailAddress
      emailAddress: user@example.com

  • ldapdelete:
    • Run ldapdelete "cn=isis,ou=Hosts,dc=example,dc=com" — you need to specify the DN of the entity you wish to delete.

    • You can also use ldapdelete -f file, where file contains a list of DNs, one per line, all of which will be deleted in turn.

Your site should now be happily Kerberized and LDAP-ized. You can set up various other applications to use LDAP as a directory server (e.g. mail clients, to get an address book) and Kerberos for authentication (e.g. your Web server).

Comments on "Integrating LDAP and Kerberos: Part Two (LDAP)"


LDAP has been a wonderous change to our developers network this past year. After reading this, I believe Kerberos and LDAP combined will provide the added security we need to have in place.

Thank you.


I don’t get the “kerberos security.” What’s the difference between ldap+kerberos and ldap+ssl+sasl+digest-md5?




anyone on the local network can bind to ldap server anonymously and get the list of all UID + GID’s. this is absolutely ugly AND insecure. disclosing the UID information to everyone is just wrong concept.



Can I map the kerberos username to a different LDAP user? Does the name have to be the same in ldap as the kerberos principal?
Specifically, can I authenticate with my kerberos credentials as user1@REALM and have that log me in as a local unix or NIS user after authentication? I cannot figure that part out!! I can authenticate fine with Kerberos but in order to login I need a matching user account name on the box or NIS or I get rejected. With winbind I can login using kerberos without having a local account but I have no control over the unix UID I am assigned and that is only good for shares anyway. What I am looking to accomplish is to authenticate using kerberos but have it log me in as a existing unix user. I know it is possible as on some of our AIX and Redhat boxes, we login with our Active directory (kerberos credentials) and after authenticating you are logged into the box as a local unix uid. I cannot figure out how to make this happen but am almost certain it is LDAP. The reason is we have an existing Unix infrastructure with permissions set up. Corporate IT wants the boxes joined to AD but when you log into the box with AD credentials the permissions do not match to my uid.


Maybe this what ur looking for
man pam_krb5

Look /.k5login


While following this article (and Part One), I finally managed to install Kerberos and OpenLDAP together. However, I ran into some problems with the howto posted here on the way. I’ve made an effort to describe how I fixed them as well as I can, and I hope it helps others attempting to do the same thing. I installed this on Ubuntu 8.04, and some of the corrections come from a partially finished guide at https://help.ubuntu.com/community/SingleSignOn. However, if I’ve inadvertently made any mistakes in these comments, please post that as well so others won’t be misled.

(Continued from Part 1)

Problems/Comments in Part 2:
1) I had problems putting the slapd.access line before the suffix definition in slapd.conf, so I put it after.
2) I managed to get LDAP working without the krb5-kdc.schema, though perhaps that was more of an accident.
3) The installation scripts had already created a root DN, so I only added one that looked like:
dn: ou=people,dc=domain,dc=com
objectclass: organizationalUnit
ou: people
description: Users

dn: uid=ldapadm,ou=people,dc=domain,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: LDAP admin account
sn: LDAP Admin
uid: ldapadm
uidNumber: 1002
gidNumber: 100
homeDirectory: /etc/ldap
loginShell: /bin/false

4) When I tried installing this setup on a different system, the sasl and authz lines given in the howto didn’t work. I’m not sure why, and I haven’t debugged further, but I had to use these instead:
sasl-secprops noanonymous,noplain,noactive
sasl-regexp uid=([^/]*),cn=GSSAPI,cn=auth uid=$1,ou=People,dc=example,dc=com

5) I had to add apparmor profiles for slapd so it could access the files it needed. This is described in detail in https://bugs.launchpad.net/ubuntu/+source/openldap2.2/+bug/229252

6) The package name should be ldap-utils, not ldap_utils, in the Client setup section.

7) In Ubuntu, the configuration for libnss-ldap is actually in /etc/ldap.conf (which is NOT the same thing as /etc/ldap/ldap.conf – that’s used by other client LDAP utilities, while /etc/ldap/slapd.conf is used by the slapd server)

In addition to many useful sites out there is http://research.imb.uq.edu.au/~l.rathbone/ldap/gssapi.shtml


Just to clarify, in #4, the last sasl-regexp line should be one line – it should not be split up into two.


Great outline. However, i am getting the following error when i try to use the following line:
ldapadd -x -D “cn=admin,dc=ph,dc=ic,dc=ac,dc=uk” -W -f setup.ldif:

ldap_bind: Invalid credentials (49)
conn=0 fd=14 ACCEPT from IP= (ip=
conn=0 op=0 RESULT tag=97 err=49 text=

Any help would be greatful. Was able to get everything else setup.


So do users needed to be added to Kerberos and LDAP independently? With this setup, if I add an LDAP user, should it have a corresponding Kerberos principle automatically?


Anyone know the answer to this? – it doesnt seem clear where the users “live”


>So do users needed to be added to Kerberos and LDAP independently?
I think according to this setup, you have got Kerberos users stored in the principal database for authentication. You also have entries in LDAP for authorization. But there does not seem to be any coupling. If you want the kerberos principals to reside in the directory, you will probably need the kerberos LDAP backend.


Great information. Lucky me I discovered your site by accident (stumbleupon). I have saved as a favorite for later!


whoah this blog is magnificent i like studying your articles. Keep up the good work! You understand, lots of individuals are searching round for this information, you could aid them greatly.


I precisely wished to say thanks once more. I do not know what I would’ve sorted out without the entire tips documented by you about that topic. It became a depressing difficulty in my opinion, however , understanding the specialised avenue you resolved that took me to leap over delight. I will be happy for this help and then wish you know what a great job your are accomplishing educating people thru your blog post. I’m certain you’ve never encountered any of us.


You made some respectable factors there. I looked on the internet for the problem and located most individuals will associate with along with your website.


One of our visitors a short while ago recommended the following website.


ir0Aqh It as grueling to find educated nation by this subject, nevertheless you sound comparable you recognize what you are talking about! Thanks


Just beneath, are many entirely not associated sites to ours, having said that, they may be certainly worth going over.


Please pay a visit to the web-sites we adhere to, including this one particular, as it represents our picks from the web.


Check below, are some completely unrelated websites to ours, nonetheless, they are most trustworthy sources that we use.


Please check out the internet sites we stick to, including this a single, as it represents our picks in the web.


Just beneath, are a lot of absolutely not related web sites to ours, nevertheless, they may be certainly worth going over.


Here are some of the internet sites we advise for our visitors.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>