The original Helix docs were ambiguous as to what the search filter in a Helix ldap spec should contain. Until we started using the user sync feature of ldapsync, we were fine with the simplest value:
When we tried to use the user feature, we hit a snag. The ldapsync command does not allow the '@' or '#' characters in the AttributeUid field (set to sAMAccountName). When it hits an LDAP (in our case, AD) account name with one of those characters, it complains and bails out. The LDAP records causing the issue were actually groups, not users! The "-u" (user) option of ldapsync refers only to what gets updated on the Helix side. What happens against AD is purely based on the Search*variables in the ldap spec. This makes sense, but isn't necessarily intuitive.
Restricting the search to an object class of %user% both eliminates this problem and speeds up the search. The command used in testing was:
% time p4 ldapsync -u -U -n myLDAPspec
The following times were against a test server with only 10 users.
SearchFilter Run time / (min:sec)
That last time was cut in half by adding a clause to ignore disabled accounts, but (at least ion 2019.1) it turned out that at least some valid LDAP users were no longer recognized by Helix, so I removed it: (userAccountControl:1.2.840.1135126.96.36.1993:=2)
The following configurables needed to be set or modified for ldapsync to work against the user database.
Configurable Value Notes
auth.ldap.timeout As needed Default is 30 seconds, not enough for large LDAP databases.
auth.ldap.pagesize As needed Our Windows pagesize is large.
dm.user.numeric 1 Only available in 2018.2 and later.
- I filed a request that the behavior be changed to simply warn of this and skip that record.
- Realizing the problem had the happy side effect of getting us to look at the AD groups and clean up some group names.
- Randall said he would update the KB based on this.