Active Directory Synchronization Excludes User From Their Primary Group

[Tom Wardrop]

I've noticed a really unusual issue while trialing Jira. Synchronisation with LDAP (users and groups) works perfectly, except that users do not appear in a group if that group is set as their Primary Group.

Active Directory has a concept of a primary group which is mainly to provide compatibility with the Unix/Linux permissions model of owner:group. This is set to Domain Users for all of our users (this is the active directory default). Because of what I can only conclude as a bug in Jira, the Domain Users group remains unpopulated after synchronisation. If I set change the primary group of my own domain account, say to Domain Admins, and then resynchronise Jira, my account appears in the Domain Users group, but it disappears from the Domain Admins group.

I've never seen this behavior with any LDAP-integrated products. I hope my description of the issue has been clear enough. If you need any further details I'm happy to provide them.

[Dave C]

I have raised an improvement request for this to be added to the Embedded Crowd engine within JIRA, JRA-29187. Given that Embedded Crowd is shared across multiple applications, if this is implemented into one application, it's likely to be implemented into them all.

There is a workaround to provide all users with a default membership, as in our Default Group Membership functionality, however this won't bring over the Primary Group - it will allow you to set a default group for all users.

If you're interested in the functionality, please vote on the following issues:

• CWD-1286
• CONF-7629
• JRA-29187

[Sam Kenny]

Hello, I was just wondering whether there had been any further news on the above. We've been evaluating Crowd and it is a pain (and we very confusing) to find group members 'disappear' when their primary group was set.

[Jeffrey Goldschrafe]

In a more general sense, this is something that has plagued all Atlassian projects I've ever used since the dawn of time. The reason is that Active Directory group memberships for secondary groups are stored in a user's memberOf attribute, while the primary group is stored as an Active Directory RID in a user's primaryGroupID attribute. This is similar to the way that many LDAP implementations handle Unix accounts: the group's numeric ID is specified using the gidNumber attribute and the group's name may not appear in the memberOf attribute. Unfortunately, because of the extra legwork required to find the appropriate group entry, this isn't fixable with a simple attribute mapping.

We've tried to work around this by using the Domain Users group (which Confluence/JIRA already don't support) as the primary, but it's often broken other things like Unix user/group/world permissions. We still don't have a good solution.

As far as I can tell, there's no immediate workaround today, but with any luck the stars will align and the Atlassian folks will fix this someday.

In a more specific sense, Active Directory contains several domain security principals that don't actually exist in the directory -- for all intents and purposes, they're not real groups. Wrap your head around that one.

[Tom Towkach]

Hi Tom,

Can't tell right now if it is a bug, a problem in some configuration or needs to be an improvement.

Can you check your log files to see if there's an error when you do this?

Quick check in JAC (jira.atlassian.com) I didn't see any issues related to your desciption of the problem.

I did find this open issue: https://jira.atlassian.com/browse/CWD-1286 .

[hhung]

Hi Tom

Thanks for your feedback and I apologise that this issue has not yet been resolved. I'm the new product manager for Crowd and want to let you know that your comments certainly do not go unnoticed. This particular issue is most definitely on our radar, but I can't give you a solid expected release date for this just yet. However I'm happy to chat with you about your concerns if you'd like, feel free to contact me at hhung@atlassian.com

Cheers, Helen

[Tom Wardrop]

Since raising this, I've found other reports of this problem from well before I posted this. I'm a little concerned with how long it's taking to address what seems like a relatively simple thing to fix, but which seems to affect so many people in a pretty fundamental way.

It doesn't give me a lot of confidence in Atlassin's ability to respond to issues, especially one as fundamental as this.

[Tom Towkach]

I've been busy with the new Global IT JIRA project and we are about ready to go to live. If the workaround doesn't fix this, then I guess the only option is to redo the groups in AD or find another product? I'd hate to swtich from Crowd since it's doing a great job expect for this 1 issue and the users really like the SSO Federated implementation with their windows log in. Yea, no we can't switch so Atlassian needs to get his fixed.