tls / ldaps support for ldap plugin

[bkw@…]

It would be great to have tls or at least ldaps support for the ldap connection. More and more servers only allow ldaps or tls these days. Python-ldap seem to support both.

[Emmanuel Blot]

I agree, however I never set up a LDAPS server yet (I use a ssh tunnel).

Need to investigate. If you have some proposal, please let me know.

[Tiziano Müller]

Patch (against revision 1254) of the ldap-plugin to add TLS support.

[Tiziano Müller]

Improved version. SSL works now too.

[Tiziano Müller]

In the second patch I've removed the host and port variables and replaced them with the uri. It would probably make sense to add the following as well:

            self._ds.x_tls_demand = True
            self._ds.x_tls_require_cert = True

If you now want to use SSL, set uri = ldaps://<YOURHOST> (if the port is not specified, the standard port will be used). If you want TLS instead, set uri = ldap://<YOURHOST> and start_tls = yes.

[Emmanuel Blot]

Not sure why the Trac release has been set to ​0.8, but it is very unlikely the plugin may work with such an outdated release of Trac.

[Tiziano Müller]

This changes the call to TracError to include the 'info' part from the exception. Helps a lot to find the reason of connection failures.

[anonymous]

Ok, there's a bug in the patch. That "self._ds.x_tls..." stuff doesn't work. But it seems that when you use Apache+mod_python+mod_authz_ldap, all LDAP parameters are taken from the Apache configuration. Since I switched to mod_fcgid, I couldn't connect anymore because the client-certificates weren't loaded. This patch might break the whole thing on Apache again, since it sets the certs, etc. to empty values if they are not specified. Conditionally setting them would be the solution.

[Tiziano Müller]

The new patch.

[Emmanuel Blot]

New version of the LdapPlugin (0.5.0) w/ basic TLS connection: [1426]

The patch has not been merged in the plugin, there are a couple of issues to fix; for example, it is not valid to hardcode a path that is OS-specific (such as '/etc/ssl').

[Baptiste Grenier]

It's seems that usually a TLS connection is an LDAP start_tls extented request done one the standard port (389) and using the standard ldap protocol (ldap://).

The ldaps:// protocols seems to be reserved for LDAP over SSL on port 636, whithout TLS and start_tls request and it seems to be deprecated. See ​http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html#1.0 or ​http://www.openldap.org/faq/data/cache/185.html for some more information.

With the actual state of the extension, it's impossible to connect to a LDAP server requesting a TLS operation and listening only to the standard port/protocol (ie, ldap:// and 389 port and not ldaps:// and 636 port). If you don't want to default to ldap:// protocol when using TLS, if in the trac.ini we could put the host address in the form ldap://hostname or ldaps://hostname it could allow us to easily select what protocol we want.

[Joachim Mairböck]

This adds back support for the start_tls extension. The new option is called use_start_tls to be consistent with the existing use_tls option.

[Joachim Mairböck]

I have just seen that #3142 proposes roughly the same changes as my patch, and it seems that their implementation is better than mine. I have not tested it, however.

It seems that this ticket could be closed, maybe even as a duplicate in favor of #3142.

[Ryan J Ollos]

Closing as a duplicate of #3142.