Aktuelle Version vom 12. Dezember 2007, 16:58 Uhr

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 ;))

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

will run as root.

SLAPD_USER="openldap"

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

SLAPD_GROUP="openldap"

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

SLAPD_PIDFILE=

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

SLURPD_START=auto

slapd normally serves ldap only on all TCP-ports 389. slapd can also
service requests on TCP-port 636 (ldaps) and requests via unix
sockets.
Example usage:
SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"

Additional options to pass to slapd and slurpd

SLAPD_OPTIONS=""

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

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.

@@ Zeile 1: / Zeile 1: @@
-This is a small write-up to get openldap running with sasl/gssapi and
+=Kerberos, SASL and OpenLDAP=
-kerberos5. Thanks to sxw@freenode, who just knew what to do (in opposite to the
+''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)''
-various crappy howtos out there)
 It is based on:
-* Ubuntu Feisty
+* '''Ubuntu Feisty'''
-* Openldap
+* '''Openldap'''
-* MIT Kerberos (but i guess heimdal will work just as well)
+* '''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
@@ Zeile 12: / Zeile 11: @@
 lowercase.
-fqdn=fully qualified domain name
+'''fqdn''': fully qualified domain name
-realm=kerberos realm
+'''realm''': kerberos realm
-user=existing kerberos/ldap user
+'''user''' existing kerberos/ldap user
-* Check prerequisites for the openldap server:
+===what you need to know===
-** DNS MUST be ok:
+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.
-*** 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
-* Check prerequisites for the openldap client:
+In particular you should know how to:
-** you should be able to ldapsearch on the server
+* Manage an OpenLDAP directory service (ldapsearch, ldapadd, ldapwhoami, configuring/starting/stopping slapd)
-** OpenLDAP must be working (and should already have useraccounts to test with)
+* 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
-** Kerberos must be working (= get tickets for users)
+* Manage the required infrastructure, such as DNS and NTP
-** have libsasl2-dev installed
+* 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>"
@@ Zeile 39: / Zeile 50: @@
     chown openldap.openldap /etc/ldap/ldap-host.keytab
-* Now, try if you get SASL running with the example server/client thing:
+===test with SASL example code===
-** do on client/server:
+* 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):
+: in one terminal (as root, on the server):
   export KRB5_KTNAME=/etc/ldap/ldap-host.keytab
-  ./sample-server.strace ./sample-server -s ldap
+  ./sample-server -s ldap
-** in another terminal (on the client):
+: in another terminal (on the client):
   kinit <user>
   ./sample-client -s ldap -n <fqdn> -u <user>
-** crosspaste the S: and C: lines
+: 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).
+: 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
@@ Zeile 63: / Zeile 76: @@
   sasl-host               <fqdn>
-** restart slapd
+* restart slapd
-* try ldapwhoami -Y GSSAPI
+===try GSSAPI bind===
-** you should get a message indicating success with:
+* 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=(.*),cn=gssapi,cn=auth ldap:///ou=Users,o=organisation,c=org?sub?uid=$1
+  saslRegexp    uid=(.*),cn=<realm>,cn=gssapi,cn=auth ldap:///ou=Users,o=organisation,c=org?sub?uid=$1
-** this will make ldap map the <user> part of <user>@<REALM> to a posixAccount uid found below ou=Users,o=organisation,c=org
+: or
+ saslRegexp    uid=(.*),cn=(.*),cn=gssapi,cn=auth ldap:///ou=Users,o=$2,c=org?sub?uid=$1
-** you could use $2 to also map the realm accordingly.
+: depending on if you want to authenticate against more than one realm.
-** restart slapd
+: 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.
+  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.
+: 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 ;))
+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
+# will run as root.
+SLAPD_USER="openldap"
+# System group to run the slapd server under. If empty the server will
+# run in the primary group of its user.
+SLAPD_GROUP="openldap"
+# Path to the pid file of the slapd server. If not set the init.d script
+# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf)
+SLAPD_PIDFILE=
+# Configure if the slurpd daemon should be started. Possible values:
+# - yes:   Always start slurpd
+# - no:    Never start slurpd
+# - auto:  Start slurpd if a replica option is found in slapd.conf (default)
+SLURPD_START=auto
+# slapd normally serves ldap only on all TCP-ports 389. slapd can also
+# service requests on TCP-port 636 (ldaps) and requests via unix
+# sockets.
+# Example usage:
+# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
+# Additional options to pass to slapd and slurpd
+SLAPD_OPTIONS=""
+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
+==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.

Benutzer:Philip/Kerberos and LDAP: Unterschied zwischen den Versionen

Aktuelle Version vom 12. Dezember 2007, 16:58 Uhr

Inhaltsverzeichnis

Kerberos, SASL and OpenLDAP

what you need to know

server prerequisites

client prerequisites

create a keytab

test with SASL example code

prepare slapd startup

try GSSAPI bind

setup SASL<->LDAP user mapping

try it!

FAQ

Notes

Navigationsmenü

Seitenaktionen

Seitenaktionen

Meine Werkzeuge

Navigation

Werkzeuge

Suche