LDAP sychronization challenge

Question

Hi,

I face the following challenge in our JIRA implementation:

We have a corporate MS Active Directory, that we have integrated with JIRA using the User Directory feature.  This sync is configured as ReadOnly with Local Groups and is mainly meant to get all employees into the jira-users group.

So far so good. We have now the additional requirement, to have certain AD groups being also synced. As the users are already synced by the first user dictionary this would be mainly about the group membership. By creating now a second user dictionary of type "read-only" and setting respective filters on groups and users, expected this to happen. But actually I face the following:

* a group with the correct name is created

* the users are NOT assigned to this group.

Checking the application server logs I can see, that users and the respective memberships are selected, but no assignments are done. (Ie. I see no members in the groups assigned)

=> Would you say the approach taken (with 2 user dictionaries) should work or do you have any alternative proposals?

Here an extract from the logs:

2017-12-07 13:47:16,065 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [crowd.directory.ldap.SpringLdapTemplateWrapper] Timed call for lookup with mapper on cn=xxxx,ou=dl,ou=msx,ou=resources,dc=global,dc=corp took 60ms
2017-12-07 13:47:16,065 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [directory.ldap.cache.AbstractCacheRefresher] found [ 12 ] remote user-group memberships, [ 0 ] remote group-group memberships in [ 131ms ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] synchronising [ 12 ] user members for group [ DL Dummy ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] internal directory has [ 12 ] members
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 12 ] user members from [ DL Dummy ] in [ 0ms ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DirectoryCacheImplUsingChangeOperations] removing [ 0 ] users from group [ DL Dummy ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DirectoryCacheImplUsingChangeOperations] adding [ 0 ] users to group [ DL Dummy ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DirectoryCacheImplUsingChangeOperations] synchronised [ 12 ] user members for group [ DL Dummy ] in [ 0ms ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] synchronising [ 0 ] group members for group [ DL Dummy ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 0 ] group members from [ DL Dummy ] in [ 0ms ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DirectoryCacheImplUsingChangeOperations] removing [ 0 ] group members to group [ DL Dummy ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DirectoryCacheImplUsingChangeOperations] adding [ 0 ] group members from group [ DL Dummy ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DirectoryCacheImplUsingChangeOperations] synchronised [ 0 ] group members for group [ DL Dummy ] in [ 0ms ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 TRACE ServiceRunner [directory.ldap.cache.AbstractCacheRefresher] migrated memberships for group - (1/1 - 100.0%) 132ms elapsed
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [directory.ldap.cache.AbstractCacheRefresher] Applied remote memberships in [ 132ms ]
2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 INFO ServiceRunner [atlassian.crowd.directory.DbCachingRemoteDirectory] FULL synchronisation complete for directory [ 10201 ] in [ 376ms ]

Andy Heinzer · Answer

Ah, that explains it.  I did not realize you were using two different user directory connections in Jira. Jira does not aggregate group memberships across user directories.   I believe that Crowd and Confluence can do this.  But Jira does not work this way.

In order to place a user to a group that comes from an external user directory, that user object has to also originate from the same user directory that this group is coming from.   Even if you have two different user directories connected to the same LDAP, Jira does not treat these as the same user directory.  Logically they are separated and distinctly different as far as Jira is concerned.  In turn the groups and users that come from each connection won't be able to overlap (ie, you can't add user accounts from LDAP1 into groups that come from LDAP2).

When working with Jira using multiple user directories, it is important to also remember that the order in which the directories appear in Jira matters.  If a particular username exists in both user directories, then the user can only login to the top ordered, enabled, directory within Jira.   That also means that this user can only belong to groups that come from that logical user directory (or possibly a group that is local to the Jira internal directory).  That user cannot belong to a group that is getting added to Jira by a second user directory.

So with that information perhaps you can eliminate this secondary user directory connection in Jira as a means to fix this problem.  Alternatively, the use of local groups with Jira is another way some admins have gotten around this kind of problem.   That option will allow you to add users from different user directories to a group that exists in the local Jira internal users directory.  But of course the problem with this tends to be that you then have to manage membership to that within Jira directly as opposed to managing it in your LDAP directory directly.

Tobias Haak · Answer

Hallo Andy,

I tried all 4 permutations.... Still no result. :-(

The log also seems to show, that the memberships were found:

2017-12-07 13:47:16,066 atlassian-scheduler-quartz1.clustered_Worker-3 DEBUG ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] synchronising [ 12 ] user members for group [ DL Dummy ]

=> So some setting/information seems to prevent the final persistence of the membership information.

I wonder, if the problem is maybe with the fact, that we have 2 AD integrations running? One, which gets more or less the whole AD as "jira-users" and now mine, which should assign only a dedicated AD group to a dedicated JIRA group...

So maybe the initial question would be: can I have multiple LDAP/AD integrations running at the same time assigning the same user to multiple JIRA groups based on their AD membership?

Andy Heinzer · Answer

Since you are seeing both the users and the groups populate in Jira, then the problem is clearly with the way that membership is being determined.

For a Microsoft Active Directory instance setup to work with Jira, in most cases I find that the way to get this work is to try to toggle the two different membership attributes under the user directory setting for this directory in Jira.

It's hard to say for sure which is appropriate for your instance without knowing a lot more about your AD instance, but given what you have indicated so far, I don't thin it would be a problem to try one of these options, then save this change, and then try to sync the directory once more with Jira to see if this works.

If it doesn't get the memberships, then try the other option, save, and sync again to see if this resolves this.

Try this and let me know the results.

Andy