Following up on the above: we have implemented Crowd in between our Confluence installation and Active Directory. It does pull primary group memberships.

We did not anticipate that this architecture breaks the "User Profile Plugin" from Communardo, which fills a serious gap in the Confluence user profile page by filling in Department, Position, Phone Number, etc., from AD.

Starting with Crowd, 2.7, Crowd does pull the primaryGroupId attribute from ActiveDirectory. If you're experiencing difficulties with this feature in Crowd 2.7 or later, can you please fill an issue and provide details to reproduce the problem?

It's bit unclear from the above, but it's worth restating: this is not resolved.

The fundamental problem is that Crowd does not pull the PrimaryGroupID (or its resulting nested groups) from the user object, and that by design, Active Directory does not return the PrimaryGroupID along with MemberOf. (http://support.microsoft.com/kb/275523)

Right or wrong, AD has been like this for more than a decade, so it would be nice if Crowd could accurately query the most commonly occurring implementation of LDAP in the world.

After some further testing here is a possible work-around that works for the moment for me:

I am a bit rusty with AD delegation, so in my example I used that AD admin account as Binding User Account.

1) Set your Base DN to your domain e.g. DC=mydomain,DC=com --> this allows you to the entire AD
2) Go to the Configuration tab and add for User DN: "CN=Users" --> that, combined with the filter for users only will let you see all users
3) In the Group configuration further down on the page add for Group DN: "OU=Crowd,OU=Applications"... I created those to folders in the AD first. Below the hierachy:

-mydomain.com
¦
-Users
-...
-Applications (created by me)
¦
-Crowd (Created by me too)

--> Once these additional settings are set one can see all users (also the one's that are newly created in the AD) + Create new groups and see groups only below the hierachy especially created for Crowd + Assing users to these groups only.

Not sure if the this still needs fixing now???

Just tried something else but without success:

Define base DN: DC=mydomain,DC=com

--> Now I can see all the users (except of course in Domain Users)
--> So I tried to create new group in my delegated OU: OU=Crowd,OU=Applications

But that does not work either, the ldap string gets always distorted:

mygroup,OU=Crowd,OU=Applications
=
cn=mygroup\,OU\=Crowd\,OU\=Applications,DC=mydomain,DC=com

If that would work, one could give the crowd service account read access to the base dn and full delegation on the actual Crowd OU. One would still be a bit poluted by the other AD Groups, but at least, with a bit of naming convention one could get a security matrix done properly... any way to implement that as a quick-fix?

Cheers & thx

FYI - for my problem above I am using a nice Samba 4 Active Directory. It worked perfectly for a Sharepoint, SQL Server 2012, Project Server POC... and trust me, Sharepoint is picky

Please fix this

I am just trying to implement a fully fletched POC for Crowd with Jira, Confluence, Bamboo, Fisheye, Stash and SSO via Active Directory and central User management of all IT Users is a part of this.
In my case, I do not understand why, the "Nested Groups" feature for AD does not seem to work at all. What I am trying to achieve is to create a separate container in the AD "Crowd" in which I can give full delegation rights to Crowd. The objective is to manage all security groups through crowd. But I am hitting a couple of Bumps here:

e.g.: If I configure my BASE DN to something like: CN=Crowd,CN=Applications,DC=mydomain,DC=com and delegate all rights for this folder to the crowd service account I can create groups and do anything I want. But if I add a group e.g. "AllUsers" and add "Domain Users" to this group OR any user directly it is impossible to see the users.

I tried also to connect with the Domain Admin Account - but nothing works.
Not sure if anybody has the same problem? I am just thinking, how would you ever be able to build a proper security matrix without being able to include groups in others?
Please fix this - this is the single best feature to help implement a proper Altassian stack in a company with a badly organized AD + working around resistance to create all the AD Groups by Domain Admins.

Cheers & thx

Thanks for the additional info, guys. I'm not much of an LDAP/Crowd guru, so my knowledge is fairly superficial.

@Chad:

I believe your workarounds don't apply when using the Seraph SSO authenticator.

It's possible to write an SSO Authenticator that integrates with Crowd to support this - what SSO authenticator are you using? Here's a working example: https://bitbucket.org/jaysee00/example-confluence-sso-authenticator/src/381eb95ebc08/src/main/java/com/atlassian/confluence/seraph/example/ExampleSSOAuthenticator.java

Also, the term "built-in group" is inaccurate. I just had a discussion with our enterprise identity management admin and we have been going back and forth on this problem. He finally got through to me that for any group, once you set it as your PrimaryGroup then you are removed from the group's "member" attribute. So, even when we create our "confluence-users" group in AD with 1,000 users in its "member" attributes... as soon as one of those members sets "confluence-users" as their "PrimaryGroup" then there will be only 999 "member" attributes in the group. AD, however, still reports 1000 members of the group.

I'll update the issue description to refer to "Primary Groups" rather than "built-in groups".

Crowd's AD connector is not compliant with Active Directory as long as it continues to use a single attribute to determine group membership.

What is the process for escalating this bug against the AD connector?

Voting and commenting on this issue is probably the best way to register your interest in having this bug fixed. More details on our bug-fixing policy are here: https://confluence.atlassian.com/display/Support/Atlassian+Bug+Fixing+Policy

@Tom:

That's why I was wondering about the decision to synchronize with AD, because as soon as you start dealing with the underlying schema, you have to re-implement all the subtleties and idiosyncrasies of the LDAP server that sits on top of that schema, which gives rise to issues like this one. It's similar to accessing a SQL database directly instead of going through the applications API to alter the data. There's nothing stopping Microsoft from changing the schema of a future Active Directory which could potentially break Atlassin's sync mechanism.

We don't interrogate the Active Directory schema directly, all our integration with Active Directory is via LDAP. It really doesn't have a great deal to do with our synchronisation approach - Crowd simply just doesn't support constructing the right LDAP query for group memberships that are not explicitly described in the LDAP schema via memberOf attributes. Because primary group memberships in Active Directory are determined differently to normal LDAP groups, even if we did not synchronise user information into the Atlassian App, Crowd would still need a more intelligent LDAP query in order to determine the additional primary group membership.

Chad, it's true what you say. That's why I was wondering about the decision to synchronize with AD, because as soon as you start dealing with the underlying schema, you have to re-implement all the subtleties and idiosyncrasies of the LDAP server that sits on top of that schema, which gives rise to issues like this one. It's similar to accessing a SQL database directly instead of going through the applications API to alter the data. There's nothing stopping Microsoft from changing the schema of a future Active Directory which could potentially break Atlassin's sync mechanism.

If performance is a problem, AD already has a replication mechanism built-in, so any installation with a high-latency connection to AD could technically setup a local replica. It's a little extra work, but it would only be a very small percentage of people that would have to take that measure.

This may be of help:
Setting Primary Group Excludes the User from the Group Membership in Active Directory