LDAP auth and TLS

[Russell Fulton]

Hi

Am I right in thinking that ELSA does not use TLS when one asks for LDAP authentication or does Perl’s LDAP use starttls?

ELSA stopped working last night with network errors “No route to Host” on the connections to LDAP in both Connect.pl and User.pl and I have spent much of the day trying to figure out what is going on. My conclusion is that ELSA is ignoring the port config in web.conf and is using port 398 for ldap binds.

Changing the calls to LDAP to use port 636 results in a message “peer closed connection” — I have established that this happened when the BIND was attempted. I then changed the calls to use LDAP rather than LDAP::Express and added a scheme => ‘ldaps’ to the call got the bind working but now the search for the user fails as evidenced by ERRORs in web.log.

A confounding issue is that one of our two data centres is ‘down’ for air conditioning upgrade and I am sure that that is what triggered then change in behaviour although what exactly changed I do not know.

What I want to know at this stage is which ports and protocols ELSA expects to use for LDAP authentication. I would hope that it is port 389 and start_tls if available.

Russell

[r.fu...@auckland.ac.nz]

I have now established that ELSA talks unencrypted to our AD ldap server on port 389 and that there is no way (that I can see) of changing that without modifying ELSA itself *and* Authen::Simple::LDAP.pm.

ELSA does not use a port config if you supply one in web.conf and even if it did it that is not enough to get encryption -- you need to tell Net::LDAP to use "scheme = ldaps" or to call the start_tls method after instantiation .  The real sticking point is that Authen::Simple::LDAP.pm does not expose any encryption options at all. 

The initial auth done in Web.psgi uses Authen::Simple::LDAP.pm and I can not see any way of doing this securely, i.e. without exposing credentials on the network.

I would be delighted if someone would point out a flaw in my 'facts' or reasoning above!

[Russell Fulton]

I have now established that ELSA uses port 389 and no encryption if you configure ldap authentication. If you give a different port number in the config it is ignored.

It turns out that getting ELSA to do encrypted LDAP is mostly straight forward. LDAP calls occurr in three contexts:
1/ initial authentication called from the web server Web.psgi. This uses Authen::Simple( ::LDAP if you are doing ldap)
2/ User.pm. and Controller.pm (uses Net::LDAP::Express) - this is effectivly authorisation not authentication .

The authorisation stuff is straight forward to fix. It requires two addtional parameters to the call the the LDAP module to pass the port and scheme parameters from the elsa_web.conf (you need to add these to the ldap section in the config ).

Web.psgi is more problematic. It uses a perl module Authen::Simple to do all the initial authentication. If you select LDAP then it uses Authen::Simple::LDAP (surprise ;) which has no options for doing encryption. To get around this I patched web.psgi to define a new perl class Authen::Simple::LDAPS which effectively copies the original code and adds the scheme parameter to the call to Net::LDAP. This is messy : (

I have put in feature request on github forAuthen::Simple to add an parameter to use encryption.

Russell

> --
> You received this message because you are subscribed to the Google Groups "enterprise-log-search-and-archive" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to enterprise-log-search-...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Russell Fulton]

One last word on this thread. *** Ignore everything I have said so far *** Sigh…

The way you get ELSA to use LDAPS is to give a URI in the host field.

From my config:

"host" : "ldaps://ldap.uoa.auckland.ac.nz",

This presumably is why the port is ignored it really is not needed Net::LDAP will default to 636 for ldaps

Russell