Jan 2016

Configuring a Basic OpenLDAP Passthrough

In Configuring an OpenLDAP Server installing, configuring and using a basic LDAP Server was discussed. In this article the topic of setting up a pass through mechanism for the password only is presented. In the scenario presented the OpenLDAP server is talking to the LDAP server of a Windows Domain. Additionally it was decided since in the Linux/BSD/Unix side of the house where this was setup we wanted to maintain our own settings of the following:

  • Central POSIX Password Management for non Domain users
  • Central POSIX Group Management
  • Central Wheel group for sudo access
  • Two admins with management rights
  • Users can change their own LDAP entry

There are a few different mechanisms to accomplish this, SASL was the one used. In order to execute it the following is needed:

  • The LDAP URL of the domain server
  • A valid domain account (admin service account) that can allow password authentication.
  • A working OpenLDAP server (obviously)
  • A few packages installed (this example uses CentOS6.X)

These are in addition to LDAP:

yum install -y cyrus-sasl cyrus-sasl-ldap

For the example our Domain Controller (DC) is called ldap.systhread.net, account is stadm and the password for the service account is qwerty77 (I would NOT use that password in the real world...)

Installation Steps (with examples)

cd /etc/sysconfig && vi saslauthd

Here we want to set up a few configuration items for SASL:

SOCKETDIR=/var/run/saslauthd
MECH=ldap
FLAGS="-O /etc/saslauthd.conf"

Of course your mileage may vary and you might want to change those settings they just happen to be what we used on our server.

cd /etc && vi saslauthd.conf

Now for the fun one, notice where the DC ldap server is defined, the service account username and the service account password. If you are using SELinux you might want to make this file as secure as possible:

 ldap_servers: ldap://ldap.systhread.net
 ldap_search_base: cn=Users,dc=systhread,dc=net
 ldap_timeout: 10
 ldap_filter: sAMAccountName=%U
 ldap_bind_dn: cn=stadm,cn=Users,dc=systhread,dc=net
 ldap_password: qwerty77
 ldap_deref: never
 ldap_restart: yes
 ldap_scope: sub
 ldap_use_sasl: no
 ldap_start_tls: no
 ldap_version: 3
 ldap_auth_method: bind

Next up the slapd conf:

cd /etc/sasl2 && vi slapd.conf

 

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

Also in /etc/sasl2 the smtpd conf file is setup the same way:

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

Last and not least crack open /etc/openldap/ldap.conf and make it aware of sasl:

TLS_CACERTDIR/etc/openldap/certs
sasl-host localhost
sasl-secprops none

Then fire it up:

service saslauthd start

And of course make sure it will fire up at the next reboot:

chkconfig saslauthd on

Changing a Record

Now edit an LDIF to modify a user and set them up for passthrough:

dn: uid=jrf, ou=Users, dc=systhread,dc=net
changetype: modify
replace: userPassword
userPassword: {SASL}jrf@systhread.net

When this changeover was actually being done I had to write a one off script to automatically generate about 150 LDIFs that were going to be imput to the LDAP server. The next step was to cat all of them into one really big LDIF that was submitted to the server, so a set of say three users might look something like this:

dn: uid=jrf, ou=Users, dc=systhread,dc=net
changetype: modify
replace: userPassword
userPassword: {SASL}jrf@systhread.net

dn: uid=anx, ou=Users, dc=systhread,dc=net
changetype: modify
replace: userPassword
userPassword: {SASL}anx@systhread.net

dn: uid=dba, ou=Users, dc=systhread,dc=net
changetype: modify
replace: userPassword
userPassword: {SASL}dba@systhread.net
...

And feed it to the beast:

 ldapmodify -f jrf_mod.ldif -H  \
   ldap:///  -D "cn=Manager,dc=systhread,dc=net" -W

Summary

This text makes it look a lot easier than it actually was. It took awhile to figure out which files needed what setup then came the fun part of testing. However, if you need simple passthrough to an AD domain controller, this is definitely an easy way to go about it. Another side effect of the new way of OpenLDAP using LDIFs was that I ended up having to write a handful of utilities to add users to the server for the staff so everyone wouldn't have to muck around with LDIF files. Perhaps the next article will examine that process as it was both interesting and very much needed!