• Type: Suggestion
• Resolution: Low Engagement
• Fix Version/s: None
• Component/s: Directory - LDAP
• Labels:

  • cleanup-seos-fy25

[CWD-5670] During connector synchronisation, we will unnecessarily synchronise two times user base

Aakrity Tibrewal (Inactive) made changes - 27/Apr/2025 12:43 PM

Resolution		New: Low Engagement [ 10300 ]
Status	Original: Gathering Interest [ 11772 ]	New: Closed [ 6 ]

Aakrity Tibrewal (Inactive) made changes - 27/Apr/2025 12:39 PM

Labels

New: cleanup-seos-fy25

SET Analytics Bot made changes - 19/Apr/2025 4:22 AM

Support reference count

New: 1

g made changes - 05/Jan/2021 9:42 AM

Description

Original: h3. 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. h3. Steps to Reproduce  # Make a connection to the OpenDS directory.  # Set ldap.user.username as "uid".  # Synchronise userbase. h3. Expected Results On the LDAP side, we will see only 3 synchronizations. Only *one* for users, one for groups, and one for memberships. h3. Actual Results We will see 2 synchronizations of the whole userbase in the LDAP logs. Notice the attrs part in both requests: {code} [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 {code} h3. Workaround  Currently, there is no known workaround for this behavior. A workaround will be added here when available h3. Ask Remove unnecessary synchronization of users from the membership method.

New: h3. 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. h3. Steps to Reproduce  # Make a connection to the LDAP directory.  # Set ldap.user.username as "uid".  # Synchronise userbase. h3. Expected Results On the LDAP side, we will see only 3 synchronizations. Only *one* for users, one for groups, and one for memberships. h3. Actual Results We will see 2 synchronizations of the whole userbase in the LDAP logs. Notice the attrs part in both requests: {code} [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 {code} h3. Workaround  Currently, there is no known workaround for this behavior. A workaround will be added here when available h3. Ask Remove unnecessary synchronization of users from the membership method.

g made changes - 05/Jan/2021 9:42 AM

Summary

Original: During connector synchronisation, we will unnecessarily synchronise two times user base when using OpenDS

New: During connector synchronisation, we will unnecessarily synchronise two times user base

g made changes - 05/Jan/2021 8:56 AM

Description

Original: h3. 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. h3. Steps to Reproduce  # Make a connection to the OpenDS directory.  # Set ldap.user.username as "uid".  # Synchronise userbase. h3. Expected Results On the LDAP side, we will see only 3 synchronizations. Only *one* for users, one for groups, and one for memberships. h3. Actual Results We will see 2 synchronizations of the whole userbase in the LDAP logs. Notice the attrs part in both requests: {code} [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 {code} h3. Workaround  Currently, there is no known workaround for this behavior. A workaround will be added here when available

New: h3. 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. h3. Steps to Reproduce  # Make a connection to the OpenDS directory.  # Set ldap.user.username as "uid".  # Synchronise userbase. h3. Expected Results On the LDAP side, we will see only 3 synchronizations. Only *one* for users, one for groups, and one for memberships. h3. Actual Results We will see 2 synchronizations of the whole userbase in the LDAP logs. Notice the attrs part in both requests: {code} [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 {code} h3. Workaround  Currently, there is no known workaround for this behavior. A workaround will be added here when available h3. Ask Remove unnecessary synchronization of users from the membership method.

g made changes - 05/Jan/2021 8:49 AM

Description

Original: h3. 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. h3. Steps to Reproduce  # Make a connection to the OpenDS directory.  # Set ldap.user.username as "uid".  # Synchronise userbase. h3. Expected Results On the LDAP side, we will see only 3 synchronizations. One for users, one for groups, and one for memberships. h3. Actual Results We will see 2 synchronizations of the whole userbase in the LDAP logs: {code} [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=t-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=t-person)(!(organizationalStatus=something)))] [attrs: uid] [controls: (oid=2.16.840.1.113730.3.4.2)] SEARCH {code} h3. Workaround  Currently, there is no known workaround for this behavior. A workaround will be added here when available

New: h3. 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. h3. Steps to Reproduce  # Make a connection to the OpenDS directory.  # Set ldap.user.username as "uid".  # Synchronise userbase. h3. Expected Results On the LDAP side, we will see only 3 synchronizations. Only *one* for users, one for groups, and one for memberships. h3. Actual Results We will see 2 synchronizations of the whole userbase in the LDAP logs. Notice the attrs part in both requests: {code} [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 {code} h3. Workaround  Currently, there is no known workaround for this behavior. A workaround will be added here when available

g created issue - 05/Jan/2021 8:47 AM