Pas.plugins.ldap and searching for fullname in the sharing tab

Has anyone been able to use full name searching in the sharing tab for users coming from ldap with pas.plugins.ldap ?

With Plone.app.ldap setups I have mapped plone fullname in the LDAP schema to an LDAP property (often cn) and then I can search for a first name or last name and the user shows up. Not so with pas.plugins.ldap, I can only search for the exact username. What am I missing?

When I've figured out how pas.plugins.ldap compares to plone.app.ldap I'd like to add an upgrade guide to docs.plone.org, but there are a number of different configuration options between the two plugins.


Other questions on the new plugin:

  • I wonder what the 'reversed key's are for in particular, do they have to do anything with my fullname search problem? When I add an ldap attribute to the reserved keys it's automatically added to User property-sheet attributes.

  • The user property-sheet attributes are limited to 5 items, but I remember reading somewhere that I should then move to ldap-settings.xml GS setup based config of the plugin.

  • Groups can be turned off in plone.app.ldap, but the Groups base DN in pas.plugins.ldap is a mandatory field. What helps is directing the groups base dn to an innocent group and set the groups search scope to one level, this does speed up the search enormous.

  • plone.app.ldap only has the object class for users and groups respectively, for which I've always substitued top,person as something that works. but with pas.plugins.ldap I can also give an extra search query filter that was not available before. Does it help to also filter here (for Users) for examples with "(objectClass=person)" as a search query filter? Or not?

LDAP configuration is a complex topic and the few times I have to change a site's ldap settings my knowledge from the previous setups has faded so much I look up the config from another site. Doesn't work though with a new plugin :stuck_out_tongue:

Have you tried my branches of node.ext.ldap and pas.plugins.ldap? (From GitHub.)

In addition to optimizations, I also added it to search all mapped fields (although, asterisk may still be required for partial searches).

Unfortunately, I had time to only polish a few fixes to upstream and all non-trivial and opinionated optimizations and fixed still remain in my branch. We've been using those with good results ever since, but I have no time this year to refactor more of the "fixes" for upstream :frowning:

@datakurre Hi Asko, thanks for pointing out your patches. I've created local releases and tested your modifications. Everything still seems to work as before, but I see no 'full name' searching. Is there something else I have to configure for that? There are references in your patches to default search attributes, but I have no idea if can set those somewhere.

My alias/propertysheet mapping is the following. displayName from LDAP/AD contains the full name, sAMAccountName is a unique login attribute. Should one of the reserved keys map to the displayName?

For those interested to try Asko's optimisations:
http://pypi.zestsoftware.nl/public/ contains node.ext.ldap, pas.plugins.ldap and bda.cache +datakurre0 local versions. You'll also have to install pylibmc which depends on libmemcached

@fredvd Did you already try the search with asterisk? (like "*Fred*") With the default Plone UI?

You may need to enable debug level logging to see the actual LDAP queries. I simply configured it to create OR query with the search string for each mapped attribute (like (|(uid=John)(displayName=John)(mail=John))).

Root cause of our problems found: we're dealing with an imperfect real world messy LDAP/Active Directory where some of the found 'person' objects don't have our reserved key attributes, in this case sAMAccountName. There are some 'contact' person objects found in the AD tree that do match on searching for their fullname or displayName, but are not 'real' users capable of logging in.

This is in a sense "caused" by extending the search to all property sheet attributes which returns objects that don't have the reserved keys for logging in. :stuck_out_tongue:

We patched both locations, one in node.ext.ldap and the other in pas.plugins.ldap. @datakurre, I've created pull requests to your work, since they are related to adding the full name search. If you can review those when you have time again to merge your improvements to the upstream that would be great.

For usability it would be cool if we can (optionall) add the asterixes automagically when searching through pas.pugins.ldap. Which opens another debate: should you tack them on the end of the search string, every word in the string, only before or after...... And not add anything when there's already an * in the original search string indicating the user knows about the wild cards.

"Fred van*"
"*fred*van*"
"Fred*van*"

And to reply to some of my own first questions: the reserved keys in pas.plugins.ldap are mapped to similar settings in the plone.app.ldap controlpanel global settings or the LDAPUserFolder object in the ZMI in the acl_users. I completely overlooked that tab.

Groups can be turned off with pas.plugins.ldap, but only in the ZMI in the acl_users folder where you can turn of the group plugins on the Activate tab.

It would indeed be good if disabling groups can be done via p.p.ldap UI

FWIW, under load we started seeings weird issues with pylibmc caused by possible bugs in libmemcached. So, we had to drop it. We still want that small speedup, so we'll try libmc next, contribute that to bda.cache and update our branches then.

bda.cache is quite old, but simple and useful. At time of writing we used python-memcached.

Latter has indeed known issues, see also this blog post from 2013 https://freethreads.wordpress.com/2013/10/01/best-python-memcache-client-python-memcached-vs-pylibmc/

So +1 for moving to pylibmc which is, over TCP, also faster, as mentioned in my blog post about RelStorage caching here https://bluedynamics.com/blog/jens/speedup-relstorage-with-memcached-done-right?set_language=en

I am looking forward to merge a PR and make a release.

@jensens I need to clarify that "pylibmc" and "libmc" are completely different libraries. Once we moved from python-memcached to pylibmc, we got all those performance benefits (probably most of them from moving from pickle to cPickle), but then we started getting very hard to debug libmemcached errors. Now we are using libmc, which is a standalone Python memcached library implemented in C++ and Cython.

@fredvd You probably already knew this, but we only now realized that with a lot of groups, also disabling Recursive Groups Plugin (until you really really need it) brings significant performance benefits (it looks like it does not do much caching by itself).

@datakurre The project I tested pas.plugins.ldap on didn't require groups from ldap yet, so we tried to disabled them. However disablling the group plugins from pas.plugins.ldap in acl_useres didn't work, @mauritsvranrees did another patch for that:

@fredvd In the meantime we did some improvements in pas.plugins.ldap (https://github.com/collective/pas.plugins.ldap/pull/53) and node.ext.ldap (https://github.com/bluedynamics/node.ext.ldap/pull/36)

I created PR's from your and Asko's work here https://github.com/collective/pas.plugins.ldap/pull/54 and here https://github.com/bluedynamics/node.ext.ldap/pull/37

@datakurre IIRC you pointed out somewhere that the enocde/decode changes did not bring that much speed as initially assumed. Can you confirm this?

@fredvd, @datakurre I want to integrate your changes step by step. So can you provide a summary which problems are actually addressed by which changes, so we can integrate/cherry-pick change by change?

@rnixx I've added a comment on the PR in github with details on 'our' fixes, but most of them have already been merged to master afaics.