Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-5670

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

XMLWordPrintable

    • 1

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      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

      1. Make a connection to the LDAP directory.
      2. Set ldap.user.username as "uid".
      3. 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.

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

            Aakrity Tibrewal made changes -
            Resolution New: Low Engagement [ 10300 ]
            Status Original: Gathering Interest [ 11772 ] New: Closed [ 6 ]
            Aakrity Tibrewal made changes -
            Labels New: cleanup-seos-fy25

            Aakrity Tibrewal added a comment -
            Atlassian Update - 27 April 2025

            Hello,

            Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.

            Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.

            Please note the comments on this thread are not being monitored.

            You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.

            To learn more about our recent investments in Crowd Data Center, please check our public roadmap.

            Kind regards,
            Crowd Data Center

            Aakrity Tibrewal added a comment - Atlassian Update - 27 April 2025 Hello, Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself. Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years , including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap. Please note the comments on this thread are not being monitored. You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here. To learn more about our recent investments in Crowd Data Center, please check our public roadmap . Kind regards, Crowd Data Center
            SET Analytics Bot made changes -
            Support reference count New: 1
            g made changes -
            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 -
            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 -
            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 -
            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 -

              Unassigned Unassigned
              gpaunovic g
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: