Details
-
Suggestion
-
Resolution: Unresolved
-
None
-
None
Description
Issue Summary
By design, the connector will run 3 synchronizations to the User Directory. AbstractCacheRefresher.synchroniseAll will first synchronize users, then synchronize groups, and then synchronize memberships.
If we look into RFC4519Directory.getMemberships method, it will search for usernames before returning membership iterator.
Steps to Reproduce
- Make a connection to the LDAP directory.
- Set ldap.user.username as "uid".
- Synchronise userbase.
Expected Results
On the LDAP side, we will see only 3 synchronizations. Only one for users, one for groups, and one for memberships.
Actual Results
We will see 2 synchronizations of the whole userbase in the LDAP logs. Notice the attrs part in both requests:
[2020-12-10T15:20:20.384+01:00] [OUD] [TRACE] [OUD-24641551] [PROTOCOL] [host: xxxxx] [nwaddr: x.x.x.x] [tid: 150] [userId: xxxx] [ecid: 0000NPD1Z8W6yG_pLO^Aye1VjtqU01xxF1,0:1] [category: REQ] [conn: 2098559] [op: 1] [msgID: 2] [base: ou=xxx,ou=xxx,o=xxx] [scope: sub] [filter: (&(objectclass=person)(!(organizationalStatus=something)))] [attrs: mail,givenName,uid,sn,cn] [controls: (oid=2.16.840.1.113730.3.4.2)] SEARCH [2020-12-10T15:20:32.008+01:00] [OUD] [TRACE] [OUD-24641551] [PROTOCOL] [host: xxxxx] [nwaddr: x.x.x.x] [tid: 192] [userId: xxxx] [ecid: 0000NPD1_y86yG_pLO^Aye1VjtqU01xxM8,0:1] [category: REQ] [conn: 2098575] [op: 1] [msgID: 2] [base: ou=xxx,ou=xxx,o=xxx] [scope: sub] [filter: (&(objectclass=person)(!(organizationalStatus=something)))] [attrs: uid] [controls: (oid=2.16.840.1.113730.3.4.2)] SEARCH
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available
Ask
Remove unnecessary synchronization of users from the membership method.