Heimdal Kerberos, SASL, and OpenLDAP Integration on FreeBSD – Part III

Part III – SASL Integraton with OpenLDAP

In Part III, OpenLDAP pass thru authentication with a Kerberos Backend using SASL will be demonstrated.

 

Prerequisites:

In addition to a fully functional Master/Slave Kerberos Server combination as described in Part I and Part II of this series, a working OpenLDAP Directory with GSSAPI and saslauthd options is needed.  As mentioned previously, consistent network time across the servers and clients, as well as, a DNS Server with forward and reverse DNS Resolution for all host names is required.

 

OpenLDAP Server Configuration Options:

At this point, a functional OpenLDAP Server is required.  To view the configured compile options, please use the following command:

# cd /usr/ports/net/openldap24-server/
# make showconfig

 

Reviewing the configuration options ensure the following are selected as on:

GSSAPI=on:With GSSAPI support (implies SASL support)
SASL=on: With (Cyrus) SASL2 support

* If the above port’s build options are not selected, please recompile openldap24-server with these build options

 

Modify /usr/local/etc/openldap/slapd.conf:

Add the following to /usr/local/etc/openldap/slapd.conf and, of course, change your settings to match your environment

 

# SASL
sasl-host          bsd220.loga.us
sasl-realm         loga.us

# Authentication

authz-policy       from
authz-regexp       uid=([^,]*),cn=loga.us,cn=gssapi,cn=auth
                   uid=$1,ou=Users,dc=loga,dc=us

 

Create /usr/local/lib/sasl2/slapd.conf with the following contents:

*When creating this file, ensure no spaces or unnecessary lines are appended to the end of the file

 

mech_list: plain GSSAPI
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux

 

Edit /etc/rc.conf:

Add the following to /etc/rc.conf.  This starts the saslauthd daemon and tells the requesting service to use ‘kerberos5’ as an authentication method.

 

saslauthd_enable="YES"
saslauthd_flags="-a kerberos5"

*Note: To set debug mode change flag to “-a kerberos5 -d” then restart saslauthd service

 

The default installation includes the ‘wheel’ group permissions to the saslauthd socket directory.

 

# cd /var/run/
# ll
drwxr-x---  2 cyrus  wheel      512 Dec 17 11:24 saslauthd/

 

Change the group membership to ‘ldap’ in order for the slapd daemon to access the socket

 

# cd /var/run
# chgrp ldap saslauthd

 

Initialize Services:

# service slapd restart
# service saslauthd start

 

Modify /etc/krb5.keytab:

# cd /etc/
# chgrp ldap krb5.keytab
# chmod 660 krb5.keytab

Note:  This is to ensure the ldap service can read the Kerberos Keytab

 

Create a suitable dn in the OpenLDAP Directory:

To create a dn that matches our Kerberos Principal of ‘zloga’, please import the following ldif file into your directory.  Of course, use your own user names.

# Entry 1: uid=zloga,ou=Users,dc=loga,dc=us
dn: uid=zloga,ou=Users,dc=loga,dc=us
cn: zloga
displayname: zloga
gidnumber: 10000
givenname: zloga
homedirectory: /Users/zloga
loginshell: /bin/bash
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: zloga
uid: zloga
uidnumber: 10241
userpassword: {SASL}zloga@LOGA.US

 

*Please note the userpassword is {SASL}zloga@LOGA.US.  This indicates to OpenLDAP the password is not local, but instead, will use SASL authentication utilizing the username@REALM format.

 

Testing the OpenLDAP Configuration with GSSAPI authentication:

Issue the following commands highlighted in Red and compare the output

# ldapsearch -x -b '' -s base supportedSALSMechanisms
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: supportedSASLMechanisms 
#

#
dn:
supportedSASLMechanisms: GSSAPI

# kinit zloga
# zloga@LOGA.US's Password:
 
# klist
# Credentials cache: FILE:/tmp/krb5cc_0
        Principal: zloga@LOGA.US

  Issued                Expires               Principal
Dec 17 07:46:54 2015  Dec 17 17:46:54 2015  krbtgt/LOGA.US@LOGA.US

# ldapwhoami
SASL/GSSAPI authentication started
SASL username: zloga@LOGA.US
SASL SSF: 56
SASL data security layer installed.
dn:uid=zloga,ou=users,dc=loga,dc=us

 

Checking the SASL installation to test authentication:

# testsaslauthd -u zloga@LOGA.US -p Password
0: OK "Success."

If the authentication was not successful, the output looks like this:

0: NO "authentication failed"

*Note: To turn on debugging mode.  See earlier note in Section: “Modifying /etc/rc.con”

 

Let’s attempt a simple bind with our user ‘zloga’:

# ldapwhoami -x -D 'uid=zloga,ou=Users,dc=loga,dc=us' -W -ZZ
Enter LDAP Password: 
dn:uid=zloga,ou=Users,dc=loga,dc=us

*Note: -ZZ is used to force TLS Connections.  Only use if TLS is enabled on the OpenLDAP Server

 

# ldapsearch -x -D uid=zloga,ou=Users,dc=loga,dc=us -W -b dc=loga,dc=us -ZZ
Enter LDAP Password: 

The search should return normal results.  If not, check the various logs for OpenLDAP and Kerberos.  In addition, place saslauthd in debug mode as mentioned earlier in this post.

 

Summary:

The beauty of this configuration is it allows OpenLDAP users in the user=uid format to authenticate against the Kerberos Server while all others authenticate via OpenLDAP.  The SASL Libraries and Components are very flexible and easy to configure for your particular environment.

 

References:

Cyrus SASL Documentation

Heimdal Kerberos Github Wiki

MIT Kerberos Documentation

FreeBSD Handbook Chapter on Kerberos

Leave a Reply

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