Ldap – How to debug SASL authentication via LDAP towards active directory

active-directoryldapsaslsaslauthd

I am trying to configure SASL running on Centos 6.5 to allow authentication towards the corporate active directory server. The end goal is to authenticate access to some subversion repos which are running on this server, but at this stage I am just trying to get saslauthd to authenticate, and testing it using testsaslauthd.

Authentication fails every time with the following in the log:

saslauthd[20843] :do_auth         : auth failure: [user=MYUSER] [service=svn] [realm=MYREALM] [mech=ldap] [reason=Unknown]
saslauthd[20843] :do_request      : response: NO

This is my /etc/saslauthd.conf:

ldap_auth_method: bind
ldap_servers: ldaps://ldap.ad.mycompany.com:3269/
ldap_bind_dn: MYBINDDN
ldap_password: xxxxxxxxxx
ldap_search_base: DC=mycompany,DC=xx
ldap_filter: (&(cn=%u)(objectClass=person))
ldap_referrals: yes
log_level: 10

Note that I know the ldap server URI, bind DN, password, search base and filter are correct because I have a perl script which uses these to perform authentication for a web site and it works fine. The perl script uses Net::LDAP, binds to the AD, searches for the user using the search base and filter, then attempts to bind using the user's DN and password. As I understand it this is exactly what SASL should be trying to do the way I have configured it.

My first observation is that despite having set log_level to 10, I get only one line telling me it failed with reason unknown. I am starting saslauthd from the shell with the -d (debug) option. What else can I do to get more debugging output?

Is there any way to get the LDAP interaction to be logged?

Finally, can anyone see anything wrong with my configuration? Perhaps some AD quirks that require special settings in the SASL configuration?

Best Answer

In the end I was not able to get saslauthd to output any better debug information, but in case it helps anyone else here is the process I followed to resolve my problem.

First I started saslauthd with strace, like this:

# strace -f saslauthd -d -a ldap

I could then see all the system calls being made by saslauthd. It looked as though it was failing during the initial exchange with the AD server, possibly during TLS negotiation.

I decided to see if I could reproduce similar behavior using the command line ldapsearch tool provided with openldap. I gave a command like this:

$ ldapsearch -d 9 -H ldaps://ldap.ad.mycompany.com:3269/ -D MYBINDDN -w xxxxxx \
   -b DC=mycompany,DC=xx '(&(cn=myuser)(objectClass=person))'

The -d 9 finally gave me some useful debugging output:

TLS: certificate [CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US] is not valid - error -8179:Peer's Certificate issuer is not recognized..

Reading the man page for ldap.conf I found that I should set TLS_CACERT and/or TLS_CACERTDIR to point to certificate bundles and files. I am using Centos 6, which has these in /etc/pki/tls/certs/, so I set the following:

TLS_CACERT    /etc/pki/tls/certs/ca-bundle.crt
TLS_CACERTDIR /etc/pki/tls/certs/

After that the ldapsearch worked, and after restarting saslauthd, authentication towards the AD server was successful.

Related Topic