Benutzer:Philip/Kerberos and LDAP
Kerberos, SASL and OpenLDAP
This is a small memo to get openldap running with sasl/gssapi and kerberos 5. Thanks to sxw@irc.freenode.net, 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:
"dn:uid=<user>,cn=<realm>,cn=gssapi,cn=auth"
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
- or
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.
FAQ
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 ;))
Notes
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.