Jump to content

Notes on ldapsync behavior, especially the SearchFilter field

  • Please log in to reply
1 reply to this topic

#1 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts

Posted 29 May 2019 - 03:58 PM

The forum editor has serious issues. It just erased part of this article when I edited it. Hopefully I have everything back.

The original Helix docs were ambiguous as to what the search filter in a Helix ldap spec should contain.[3] Until we started using the user sync feature of ldapsync, we were fine with the simplest value:

SearchFilter:   (sAMAccountName=%user%)

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.[1] 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[2] 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)

(sAMAccountName=%user%) 1:28
(&(objectClass=user)(sAMAccountName=%user%)) 1:06

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.113556.1.4.803:=2)

P4D configurables

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.

#2 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 135 posts

Posted 30 May 2019 - 06:26 PM

It turns out that using the part of the filter that ignored disabled accounts had a side effect of making at least some valid accounts no longer function. The post was edited to reflect that.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users