Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-26073

User Directory Sync using Microsoft AD pulls in groups and users from sub-domains when not requested.

XMLWordPrintable

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      In 4.4.1 we have users which have duplicate accounts because of their separate account which is in a sub-domain. I have given the User Directory Sync the base DN, but it should not traverse to the sub-domain unless i explicitly tell it to do so. All other applications which search LDAP for Microsoft AD do not traverse to any sub-domains unless you tell it to do so. This is causing even more issues when i tested an upgrade to 4.4.3.

      In 4.4.3 the User Directory Sync will not even run successfully because it gets to a group which is also in the sub-domain and throws an error.

      2011-10-26 09:26:31,445 QuartzWorker-0 ERROR ServiceRunner [atlassian.crowd.directory.DbCachingDirectoryPoller] Error occurred while refreshing the cache for directory [ 10000 ].
      java.lang.IllegalArgumentException: duplicate key: Guests
      at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:62)
      at com.google.common.collect.ImmutableMap$Builder.fromEntryList(ImmutableMap.java:210)
      at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:196)
      at com.google.common.collect.Maps.uniqueIndex(Maps.java:456)
      at com.atlassian.crowd.directory.ldap.cache.AbstractCacheRefresher.synchroniseMemberships(AbstractCacheRefresher.java:126)
      at com.atlassian.crowd.directory.ldap.cache.AbstractCacheRefresher.synchroniseAll(AbstractCacheRefresher.java:44)
      at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher.synchroniseAll(UsnChangedCacheRefresher.java:223)
      at com.atlassian.crowd.directory.DbCachingRemoteDirectory.synchroniseCache(DbCachingRemoteDirectory.java:619)
      at com.atlassian.crowd.manager.directory.DirectorySynchroniserImpl.synchronise(DirectorySynchroniserImpl.java:63)
      at com.atlassian.crowd.directory.DbCachingDirectoryPoller.pollChanges(DbCachingDirectoryPoller.java:50)
      at com.atlassian.crowd.manager.directory.monitor.poller.DirectoryPollerJob.execute(DirectoryPollerJob.java:34)
      at org.quartz.core.JobRunShell.run(JobRunShell.java:195)
      at com.atlassian.multitenant.quartz.MultiTenantThreadPool$MultiTenantRunnable.run(MultiTenantThreadPool.java:72)
      at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)

      This is going to cause major issues and hence prevents us from even thinking about upgrading to any newer version than 4.4.1.

      I have also looked into using the LDAP filter to filter out the sub-domain or only filter in the OUs that i want to Sync, but that is impossible. Due to the LDAP standard for Microsoft AD, you cannot use wildcards when filtering by distinguishedName, so it can't be filtered by OU by that method.

            [JRASERVER-26073] User Directory Sync using Microsoft AD pulls in groups and users from sub-domains when not requested.

            Kerrod Williams (Inactive) added a comment -

            Thanks for taking the time to raise this issue.

            Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts. In part, that means concentrating on those issues that resonate the most with our users.

            I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue.

            Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me.
            Kind Regards,
            Kerrod Williams
            JIRA Product Management
            kerrod.williams at atlassian dot com

            Kerrod Williams (Inactive) added a comment - Thanks for taking the time to raise this issue. Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts . In part, that means concentrating on those issues that resonate the most with our users. I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue. Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me. Kind Regards, Kerrod Williams JIRA Product Management kerrod.williams at atlassian dot com

            Lynn Huang added a comment -

            I met similar problem, and the option Follow Referrals didn't work (as I thought), I need the user info from sub-domain, but want to use Parent domain groups only (or groups from both domain is fine) because the roles and permissions are prepared for Parent domain, how to resolve this, via configuration or it's unsupported now? Thanks.

            Lynn Huang added a comment - I met similar problem, and the option Follow Referrals didn't work (as I thought), I need the user info from sub-domain, but want to use Parent domain groups only (or groups from both domain is fine) because the roles and permissions are prepared for Parent domain, how to resolve this, via configuration or it's unsupported now? Thanks.

            ChrisA added a comment -

            Moved to an improvement as disabling Follow Referrals should resolve the issue in most cases, and the toggle to use or not use subdomains is a separate feature we'd need to include.

            ChrisA added a comment - Moved to an improvement as disabling Follow Referrals should resolve the issue in most cases, and the toggle to use or not use subdomains is a separate feature we'd need to include.

            Adam Barylak added a comment -

            Mark-

            Well, it is a pretty simple setup. Top domain is dc=company,dc=com (which is what the Base DN is set to). Then we have a sub-domain which would be dc=testeng,dc=company,dc=com.

            So, i only wanted to sync in users and groups from dc=company,dc=com. However, it was syncing in all users and groups from the testeng domain as well. In each Microsoft AD deployment has a group called guests which is the first group that it errored out on, and i am assuming that it would be many more such groups which are the same which it would error out on.

            I was actually able to get it to not sync in the other domain by unchecking the option for Follow Referrals in the user directory configuration. This option was turned on because during our upgrade from 4.0 to 4.4.1, it was a required option in the osuser.xml file, and therefore i assumed that it was required for sync to work at all. However, it is not required for our implementation and therefore, i have no idea why it was required during upgrade. However, that option is not very specific and should probably either not traverse to sub-domains still or explicitly explain that it will.

            I assume the Follow Referrals option was placed in there for other reasons not related to pulling in sub-domains, so my suggestion would be to include an alternate checkbox which is something like "Restrict to currect domain" or "Include sub-domains" whichever way you want to say it in order to put in some logic in order to reduce the confusion and also give the product more flexibility.

            Let me know if you have any questions.

            Adam

            Adam Barylak added a comment - Mark- Well, it is a pretty simple setup. Top domain is dc=company,dc=com (which is what the Base DN is set to). Then we have a sub-domain which would be dc=testeng,dc=company,dc=com. So, i only wanted to sync in users and groups from dc=company,dc=com. However, it was syncing in all users and groups from the testeng domain as well. In each Microsoft AD deployment has a group called guests which is the first group that it errored out on, and i am assuming that it would be many more such groups which are the same which it would error out on. I was actually able to get it to not sync in the other domain by unchecking the option for Follow Referrals in the user directory configuration. This option was turned on because during our upgrade from 4.0 to 4.4.1, it was a required option in the osuser.xml file, and therefore i assumed that it was required for sync to work at all. However, it is not required for our implementation and therefore, i have no idea why it was required during upgrade. However, that option is not very specific and should probably either not traverse to sub-domains still or explicitly explain that it will. I assume the Follow Referrals option was placed in there for other reasons not related to pulling in sub-domains, so my suggestion would be to include an alternate checkbox which is something like "Restrict to currect domain" or "Include sub-domains" whichever way you want to say it in order to put in some logic in order to reduce the confusion and also give the product more flexibility. Let me know if you have any questions. Adam

            Mark Lassau (Inactive) added a comment -

            I have given the User Directory Sync the base DN, but it should not traverse to the sub-domain unless I explicitly tell it to do so

            JIRA doesn't have concept of a sub-domain or even look at AD as a "Domain Controller", just as an LDAP tree that stores users and group.
            We start at the base DN node and find all users in that subtree that satisfy the search criteria.

            Mark Lassau (Inactive) added a comment - I have given the User Directory Sync the base DN, but it should not traverse to the sub-domain unless I explicitly tell it to do so JIRA doesn't have concept of a sub-domain or even look at AD as a "Domain Controller", just as an LDAP tree that stores users and group. We start at the base DN node and find all users in that subtree that satisfy the search criteria.

            Mark Lassau (Inactive) added a comment -

            Adam please tell us about how your LDAP tree is setup.
            What is the Distinguished Name for the two groups with the same name?
            What is the Base DN you have configured in the LDAP User Directory settings in JIRA?
            What is the DN of the LDAP sub-tree where your subdomain lives?

            Mark Lassau (Inactive) added a comment - Adam please tell us about how your LDAP tree is setup. What is the Distinguished Name for the two groups with the same name? What is the Base DN you have configured in the LDAP User Directory settings in JIRA? What is the DN of the LDAP sub-tree where your subdomain lives?

              Unassigned Unassigned
              c1ff22f20cdf Adam Barylak
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: