Benutzer:Philip/Kerberos and LDAP

aus Metalab, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Wechseln zu: Navigation, Suche

Kerberos, SASL and OpenLDAP

This is a small memo to get openldap running with sasl/gssapi and kerberos 5. Thanks to, who happened to just know what to do (in contradiction to the various crappy howtos out there)

It is based on:

  • Ubuntu Feisty
  • Openldap
  • MIT Kerberos (but i guess heimdal will work just as well)

I use <> brackets to indicate that you need to fill something in. Please mind that <BLAH> stands for SOMETHING IN UPPERCASE and <blah> for something in lowercase.

fqdn: fully qualified domain name realm: kerberos realm user existing kerberos/ldap user

what you need to know

Considering the high potential of neverending frustration and agony when deploying LDAP & Kerberos, you should ask yourself if you are really firm with all of the used software products, which include OpenLDAP, Kerberos, gcc and a text editor.

In particular you should know how to:

  • Manage an OpenLDAP directory service (ldapsearch, ldapadd, ldapwhoami, configuring/starting/stopping slapd)
  • Manage a Kerberos KDC, either MIT or Heimdal. This includes know-how about how to set up a realm, create policies, add/delete/change principals and so on
  • Manage the required infrastructure, such as DNS and NTP
  • Test your network and system for misconfiguration
  • SASL is just a library used by client and server to negotiate authentication. no more, no less.

server prerequisites

Check prerequisites for the openldap server:

  • DNS MUST be ok:
    • host <ipaddress that you want to use to connect to ldap> must return a hostname (DNS PTR record)
    • host <hostname returned previously> must return the same ip address (DNS A record)
    • that is, host <ip> and host <hostname> must return the equal opposite
  • OpenLDAP server must give read access to root DSE on anonymouse binds
  • have libsasl2-modules-gssapi-mit installed
  • have libsasl2-dev installed

client prerequisites

Check prerequisites for the openldap client:

  • you should be able to ldapsearch on the server
  • OpenLDAP must be working (and should already have useraccounts to test with)
  • Kerberos must be working (= get tickets for users)
  • have libsasl2-dev installed

create a keytab

  • Create a ldap service keytab on your kdc:
 kadmin.local -q "ank -randkey ldap/<fqdn>@<REALM>"
 kadmin.local -q "ktadd -k ldap-host.keytab -e \"des3-hmac-sha1:normal\" ldap/<fqdn>@<REALM>"
  • Copy ldap-host.keytab to the openldap server to /etc/ldap
  chown openldap.openldap /etc/ldap/ldap-host.keytab

test with SASL example code

  • Now, try if you can get SASL running with the example server/client thing:
do on client/server:
  gcc -o sample-client /usr/share/doc/libsasl2-dev/examples/sample-client.c -I. -I /usr/include/sasl -lsasl2
  gcc -o sample-server /usr/share/doc/libsasl2-dev/examples/sample-server.c -I. -I /usr/include/sasl -lsasl2
in one terminal (as root, on the server):
export KRB5_KTNAME=/etc/ldap/ldap-host.keytab
./sample-server -s ldap
in another terminal (on the client):
kinit <user>
./sample-client -s ldap -n <fqdn> -u <user>
crosspaste the S: and C: lines
do yourself a favour and do not continue unless you made the negotiation work (it makes sure that everything you need regarding sasl/kerberos is set up correctly).

prepare slapd startup

  • edit /etc/defaults/slapd and add the line
export KRB5_KTNAME=/etc/ldap/ldap-host.keytab
  • edit /etc/slapd.conf and add the lines
sasl-realm              <REALM>
sasl-host               <fqdn>
  • restart slapd

try GSSAPI bind

  • try
kinit <user>
ldapwhoami -Y GSSAPI
you should get a message indicating success with:

setup SASL<->LDAP user mapping

  • now, depending on your ldap setup, add something along the lines of
saslRegexp    uid=(.*),cn=<realm>,cn=gssapi,cn=auth ldap:///ou=Users,o=organisation,c=org?sub?uid=$1
saslRegexp    uid=(.*),cn=(.*),cn=gssapi,cn=auth ldap:///ou=Users,o=$2,c=org?sub?uid=$1
depending on if you want to authenticate against more than one realm.
The first example will make ldap map the <user> part of <user>@<REALM> to a posixAccount uid found below ou=Users,o=organisation,c=org
The second example will try to search in <realm> below the hierarchy of c=org. You can improve that by writing a better regex which extracts the domain from the realm.
  • you could also use $2 to also map the realm in the username accordingly.
  • restart slapd

try it!

  • get a ticket and look what you have here:
kinit <user>
ldapwhoami -Y GSSAPI
should tell you your correct dn.
  • if you want to always use GSSAPI, put the line
mech_list: GSSAPI
in the file /usr/lib/sasl2/slapd.conf - no, thats NOT a typo.


Please feel free to add questions here. I will answer them within a few days (questions by email have a lesser chance to be answered ;))

HI I read your howto. it is great but i have a few questions. Im usin debian etch and i cant see any diffrences between ubuntu and etch. I configured sasl and tested it but ive used sasl-sample-server and client from sasl2-bin package. when i followe tutoriam it seems ok. but I found in cyrus-sasl docs options, mech_list: GSSAPI and keytab option. You used mech_list. I thought if keytab option shows path to keytab file why don't use it instead export KRB5_KTNAME i thing the effect shoult be the same.

But unfortunately i get this error sasl-sample-server: SASL Other: GSSAPI Error: Miscellaneous failure (No such file or directory) sasl-sample-server: Starting SASL negotiation: generic failure (generic failure) it shows when i dont export KRB5_KTNAME. Do you know why it is not working?

If I edit /etc/default/slapd where exacly i shoutld export KRB5...

This is the file: "# System account to run the slapd server under. If empty the server

  1. will run as root.


  1. System group to run the slapd server under. If empty the server will
  2. run in the primary group of its user.


  1. Path to the pid file of the slapd server. If not set the init.d script
  2. will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf)


  1. Configure if the slurpd daemon should be started. Possible values:
  2. - yes: Always start slurpd
  3. - no: Never start slurpd
  4. - auto: Start slurpd if a replica option is found in slapd.conf (default)


  1. slapd normally serves ldap only on all TCP-ports 389. slapd can also
  2. service requests on TCP-port 636 (ldaps) and requests via unix
  3. sockets.
  4. Example usage:
  5. SLAPD_SERVICES="ldap:// ldaps:/// ldapi:///"
  1. Additional options to pass to slapd and slurpd


export KRB5_KTNAME=/etc/ldap/ldap-host.keytab SLURPD_OPTIONS="" "

is this good place. I'm new with sasl and rest. thank for help Wojtek Giel


If you find a place where this Howto seems most appropriate to you, please feel free to copy it there. But please drop me a note so that I can still update it: philip (at) linuxteam (dot) at.