Plone 5, ldap/AD and TLS


it from discussions that both and pas.plugins.ldap can be made to work with plone 5. It is unclear if pas.plugins.ldap works with AD however.

Is there a good reason to want to use pas.plugins.ldap over p.a.ldap?

It is also unclear if either work with TLS binding using a certificate. I found some references to either patching python-ldap or doing some system level ldap configurations to make that work. Is there a better way?

btw, here is the previous thread about LDAPS (ie LDAP over TLS) -

it works with AD if there are no alias entries used, see
The fix is very simple and described there. @rnixx and I are overloaded with work, but if a PR is provided I can cut a release.

TLS with Python and LDAP is a PITA. Providing certificates on OS level and let them pick up by python/python-ldap/node.ext.ldap is probably a good idea. pas.plugins.ldap/node.ext.ldap is already prepared to make this configurable TTW, but it is not finished nor tested.

There are several reasons to not use, but if it works for you in your environment there's also no reason to switch.

pas.plugins.ldap is in several ways more flexible and also gives you sane group handling and sane configuration. It's not a bunch of stacked layers around an old-style UserFolder. It does not need monkey patches all the way down. And it is supported and active developed.

1 Like

Perhaps if many are interested in improving AD support with TLS we could do what we did last year: Fundraising campaign for new LDAP feature

Is it started? Maybe a branch somewhere @jensens?
How hard would it be for me to finish? I have a to connect to AD via TLS in the next couple of days so I have to weigh up fiddling around with certificates on the OS level (which I'd prefer not to do given its a shared zope instance) vs making this software change.

@jensens trying to understand the code that is there and how to finish it

It looks like node.ext.ldap is already got the code it needs, its just a matter of configuring the properties page to enter the data. I'm wondering if it might be better to store the cacertfile in a blob and then pass the location of the blob file instead of making users deploy certs to OS location and then having to know that location when configuring?
Perhaps the clkeyfile and clcertfile can also be stored in blobs, perhaps generated automatically by default? I'm not sure on the security implications of storing the key however in the zodb. What do you think?

Indeed this was never implemented. My customers never had TLS at their internal LDAP enabled. So, it just configures python-ldap it should be no problem to do so. Using a blob as a certificate sounds like a good idea. Contributions are welcome!