users_ldap: LDAP connection not flexible enough (e.g., SSL)

[Georges Racinet]

Only LDAP connections with TLS options are supported.
This makes it impossible to bind on a server that accepts SSL connections only.
users_ldap currently stores in res.company.ldap a host/port pair, which in turn forces it to generate the UIR from code (see the code extract below)

The best way to specify a connection would instead be to specify the URI. Otherwise we'll have to re-implement all the variations unthought of one by one, creating useless bloated code, bugs reports etc.
Some basic validation of the URI syntax would of course be welcomed.

Besides, having just one field is easier to update if there are many such lines (I have 3 different on the same server, for different user templates).

Code extract:
    def connect(self, conf):
        """
        Connect to an LDAP server specified by an ldap
        configuration dictionary.

        :param dict conf: LDAP configuration
        :return: an LDAP object
        """

        uri = 'ldap://%s:%d' % (conf['ldap_server'],
                                conf['ldap_server_port'])

        connection = ldap.initialize(uri)
        if conf['ldap_tls']:
            connection.start_tls_s()
        return connection

(seen on 6.1-1, 6.1 current HEAD and trunk)

I can of course contribute the direct URI implementation, if there is positive feedback about it, but I'm in immediate need of this, and a bit reluctant to maintain a fork for such a simple change if not convinced it has a chance to be merged one day. I'll solve my immediate problem with a custom addon for now.

[xrg (xrg)]

On Tuesday 03 July 2012, you wrote:
> Public bug reported:
>
> Only LDAP connections with TLS options are supported.

According to the Wikipedia, anything but TLS is now deprecated:

http://en.wikipedia.org/wiki/Ldap#Protocol_overview

Quote:
> The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was
> never standardized in any formal specification. This usage has been
> deprecated along with LDAPv2, which was officially retired in 2003.

[Georges Racinet (gracinet)]

Being deprecated does not mean that there are not servers around requiring it.

Splitting a connection URI into parts is an unecessary complication.
It's a bit like requiring to specify an HTTP server with host and port fields, not implementing the https case, building an URL internally to the lib that takes care of the connection. Even if HTTPS gets some day deprecated in the same way, would you do that ?

So, agreed, LDAPS is not 100% standard, but it's widespread, because server-side, it's a practical way to be sure nobody will ever attempt to bind on an unencrypted channel.
Why block it with useless code that will need to be maintained if more options appear in the future ?

In the immediate need I have, I'm actually the one administrating the ldap server, and that's OpenLDAP 2.4.23. If you know how to enforce once that only TLS is allowed on the public interface and clear-text connections are allowed on the loopback, with enough confidence that encryption is really enforced, I'm interested.

Cheers,

[Stefan Rijnhart (Opener) (stefan-opener)]

George,

came across this thread by accident. Without commenting on whether or not the configuration should take an LDAP URI, in order to solve your immediate problem you can have a look at this post:

http://old.nabble.com/Re%3A-Starttls-and-SSL-p30733776.html

It uses the 'ssf' directive in ACLs to force encryption for certain queries over certain interfaces. See http://www.openldap.org/doc/admin23/security.html for an overview of the possible settings of this directive.

Cheers,
Stefan.

[Georges Racinet (gracinet)]

Thanks Stefan,

thanks for the pointers, the use of ssf is interesting, indeed, but it behaves exactly as I feared after a quick read of the doc at the time I filed the bug. Quoting that post:

    Warning, this does not prevent clients to send a password unencrypted,
    it just make it useless.

[Kevin Deldycke (kevin-deldycke-deactivatedaccount)]

My comment may be off-topic, but I had a similar issue regarding SSL LDAP and managed to make it work with a convoluted patch. See this ticket for more information: https://bugs.launchpad.net/openobject-addons/+bug/1083529