TLS configuration for LDAP

I've successfully configured LDAP authentication against our Windows 2008 r2 server, but was wondering if someone had documentation on configuring TLS? There wasn't much to go off within the dialogs and I've couldn't find much online in the way of references. I tried searching for various combination of PERL and SSL keywords w/o luck and did lots of experimenting with equally poor success. I do know for sure that I can connect via SSL by testing with the Softerra LDAP browser, so hopefully it's just a matter of grabbing the right cert and putting it in the right spot.

Thanks!

---

Do you want help configuring TLS on the server, or in foswiki?

I tested TLS on the server using perl:

perl -we "use Net::LDAP; print Net::LDAP->new ('ad.unsw.edu.au')->start_tls(verify => 'require', capath => '/etc/ssl/certs/')->{errorMessage}"

and using ldapsearch:

ldapsearch -ZZ -h ad.unsw.edu.au  -x

-- JayenAshar - 29 Dec 2011

I believe the server side is fine but in looking at this again, I'm seeing that my testing with Softerra LDAP browser on Windows was actually using SSL on 636 rather than TLS on 389. I thought the Windows admin had confirmed it was running but will need to double check.

Specifically, I was getting hung up on the documentation regarding certificates and which ones needed to be where and in what format. Hadn't been able to find anything that explained how to pull them off the AD server and whether or not I needed to generate one for the Linux host that's running Foswiki and if so, how that's done.

I do have Foswiki correctly authenticating on LDAP w/o TLS so that part is confirmed functional. I wasn't thrilled about passwords flying around in plaintext and would be thrilled to be able to get this working so we can roll it out company-wide.

Ran into some problems with the commands you suggested, but will do some more testing. I don't appear to have the -ZZ or -x options in the ldapsearch on my system (Ubuntu 10.04) but perhaps I've got an older version.

john@whasys02:~$ perl -we "use Net::LDAP; print Net::LDAP->new ('whasys02.wha.local')->start_tls(verify => 'require', capath => '/etc/ssl/certs/')->{errorMessage}"
Can't call method "start_tls" on an undefined value at -e line 1, <DATA> line 275.

Really appreciate the help on this, even if it's just pointing me to some resources with some additional detail...

-- JohnV - 30 Dec 2011

I tried from an ubuntu 10.04 machine and got an unknown error code with ldapsearch. that command i gave above doesn't do any authentication/binding or searching. it's just to check the TLS certificate. If you use the LDAP server I have above, you should get "hostname does not match CN in peer certificate"

you shouldn't have to get any certificates manually. it should all happen in the TLS connection.

using the perl command on the same 10.04 box, i got no error. i don't know why your Net::LDAP->new function returned undef . Maybe it couldn't resolve the host? can you try:

perl -we "use Net::LDAP; Net::LDAP->new ('whasys02.local') or die $@"

-- JayenAshar - 30 Dec 2011

The or die $@ is courtesy of http://search.cpan.org/~gbarr/perl-ldap/lib/Net/LDAP.pod#SYNOPSIS the Net::LDAP pod

-- JayenAshar - 30 Dec 2011

Ok, a bit more testing on this. I noticed that I pasted in the wrong host in the previous test output and meant to be connecting to our AD server which is actually whadc02.wha.local. Testing against that generates the following:

john@whasys02:~$ perl -we "use Net::LDAP; print Net::LDAP->new ('whadc02.wha.local')->start_tls(verify => 'require', capath => '/etc/ssl/certs/')->{errorMessage}"
SSL connect attempt failed with unknown errorerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I was hoping this meant that I was potentially making progress and my next thought was to try and grab the certificate files for the CA and whadc02, convert them to PEM format, and put them in whasys02:/etc/ssl/.

john@whasys02:~$ perl -we "use Net::LDAP; Net::LDAP->new ('whadc02.wha.local') or die $@"
john@whasys02:~$ 

Should there be more output on this? I get the same result on an Ubuntu 11.04 system.

I wasn't able to resolve your AD server so perhaps that is an internal hostname or access only.

Does this help narrow the potential issue down any? Thanks for your assistance.

-- JohnV - 04 Jan 2012

that error message is fine, and is also what i get with my AD server. i have grabbed the certificate files for the CA, but that has no effect on foswiki, as it seems to ignore this error.

there should not be more output on your second command, but if you had used a bad hostname, you would have gotten:

IO::Socket::INET: Bad hostname 'whadc02.wha.local'      ...propagated at -e line 1, <DATA> line 522.

So I guess I don't know what your issue is, then. What symptoms are you having? What behaviour are you expecting?

-- JayenAshar - 05 Jan 2012

It's been a while since I had last worked on this, but I'm pretty sure the main issue was a certificate error in the Foswiki logs. The non-TLS LDAP stuff worked well and then when I enabled TLS in the configure window it stopped authenticating me on login. I'll get a better rundown of the error logs on Friday and update this.

For what it's worth, I noticed that the Softerra browser does support TLS as well as just SSL which I verified was functional on our setup today. You can connect normally and then do a start TLS and it worked fine. Presumably that's further evidence that it's just a matter of finding the right settings on the Linux/Foswiki side of things to make it work.

For your setup, did you do any manual certificate copying or have to generate a machine cert or was getting it running a matter of just configuring the server and port and checking the "use TLS" box?

-- JohnV - 05 Jan 2012

I thought I had to download the certificate, but after I did, Foswiki TLS still wasn't working. This was on my test machine. My production machine doesn't have the certificate, and TLS is working in Foswiki. I used openssl s_client to get the certificate from the SSL port. I couldn't figure out how to get the certificate from the TLS port, and I don't have access to the LDAP server to get the certificate directly.

I am using Net::LDAP 0.43 which has a bug and I had to patch it.

(cd cpan/lib/perl5/site_perl/5.10.0/ && wget -O - https://github.com/gbarr/perl-ldap/commit/a3c4f7f.patch | patch -p2)

If you are using a different version of Net::LDAP, then you are probably okay.

-- JayenAshar - 05 Jan 2012

For a brief period of time today, I thought I actually had this working, but tcpdump revealed that in fact passwords were still going across plaintext. Your info on using openssl inspired me to do some more research and one of the pages I came across that was very helpful was http://www.cyberciti.biz/faq/test-ssl-certificates-diagnosis-ssl-certificate/ I'd already grabbed the CA certificate from my Windows test system and converted it into PEM and put it on the Linux host I was working with. I didn't know about c_rehash so I ran that and was able to successfully test on the CLI with

openssl s_client -CApath ~/.certs/whadc02.wha.local/ -connect whadc02.wha.local:636

and not get any cert errors.

Following the openssl tests, I reconfigured Foswiki to use TLS and for the first time ever, I was able to authenticate with that enabled. The logs showed LdapContrib - using TLS which made me think it was actually using TLS. Upon doing a packet trace of the traffic, I saw that it in fact was not. Testing on port 389 and 636 produced the same thing.

sudo tcpdump -i eth0 'port 389 or port 636' -s0 -w /home/john/ldapconnect.pkt

My latest Foswiki config is below. I'll have another attempt at this next week...

$Foswiki::cfg{Ldap}{Host} = 'whadc02.wha.local';
$Foswiki::cfg{Ldap}{Port} = '636';
$Foswiki::cfg{Ldap}{Version} = '3';
$Foswiki::cfg{Ldap}{Base} = 'dc=wha,dc=local';
$Foswiki::cfg{Ldap}{BindDN} = 'cn=$ldapfoswiki,ou=Primary Accounts,ou=Company Users,dc=wha,dc=local';
$Foswiki::cfg{Ldap}{BindPassword} = '';
$Foswiki::cfg{Ldap}{UseSASL} = 0;
$Foswiki::cfg{Ldap}{SASLMechanism} = 'PLAIN CRAM-MD5 EXTERNAL ANONYMOUS';
$Foswiki::cfg{Ldap}{UseTLS} = 1;
$Foswiki::cfg{Ldap}{TLSSSLVersion} = 'tlsv1';
$Foswiki::cfg{Ldap}{TLSVerify} = 'require';
$Foswiki::cfg{Ldap}{TLSCAPath} = '/etc/ssl/certs/';
$Foswiki::cfg{Ldap}{TLSCAFile} = '/etc/ssl/certs/wha-whadc01-ca.wha.local.pem';
$Foswiki::cfg{Ldap}{TLSClientCert} = '';
$Foswiki::cfg{Ldap}{TLSClientKey} = '';
$Foswiki::cfg{Ldap}{Debug} = 1;

-- JohnV - 06 Jan 2012

you configured foswiki to use port 636, so it will use ssl. tls is only on port 389. See my config in Question987.

-- JayenAshar - 08 Jan 2012

I tried both port 389 and 636 with what I think were identical results. I should have some more time again next week to have a closer look at this again.

-- JohnV - 20 Jan 2012

I think this may be working now... I didn't make any changes from the testing a few weeks ago and can't explain why but packet captures taken in the same manner don't appear to contain any plaintext authentication data like they did before. I'm doing my testing back on port 389 and can see the startTLS sequence in the flow which wasn't previously present.

I'll do some more testing as this seems like a much more promising situation but I'm optimistic that it really is all working right.

Thanks again for your input on this Jayen!

-- JohnV - 27 Jan 2012

Commenting is disabled while not logged in