-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
2.7, 5.1.4, 5.3, 5.6.5, 5.8.15
-
Confluence 2.7 on Tomcat 5.5
LDAP Active Directory
DB MS SQL Server 2005
-
7
-
Severity 2 - Major
-
0
-
When Confluence is integrated with Active Directory, LDAP users that don't have "Domain User" set as their primary group can not connect to Confluence. For exemple, let's say we want to have users in LDAP that can just use Confluence and do nothing else, we'll create them with a single group (thus set as their primary group) actually allowed to get access to Confluence resources. In that case, they are unable to connect and are not shown as member of the group in Confluence.
- relates to
-
CWD-1286 Provide support for Active Directory Primary group memberships (eg. Domain Users, Domain Admins)
- Closed
[CONFSERVER-10561] Active Directory users must have "Domain User" set as primary group to be usable in Confluence.
Still ran into this bug in version : 5.1.4 . Just wanted to note that changing the primary group in AD to something else is a workaround, albeit a poor one.
Robert Borkowski
added a comment - Here's my support ticket: https://support.atlassian.com/browse/CWDSUP-6256
Robert Borkowski
added a comment - Here's my support ticket: https://support.atlassian.com/browse/CWDSUP-6256 Robert Borkowski
added a comment - We also use likewise-open in production and this requires us to set the primary group in order for our Linux systems to set users' GIDs. We use the primary group of a user to control access to very many resources. Can a user log into the production monitoring system? Check the gid if they are part of the sysadm team, can they log into servers? check the GID, this is everywhere.
Now we deploy crowd and find that it doesn't know what the primary group of a user is... Giant pain.
What is the ETA for a fix?
Robert Borkowski
added a comment - We also use likewise-open in production and this requires us to set the primary group in order for our Linux systems to set users' GIDs. We use the primary group of a user to control access to very many resources. Can a user log into the production monitoring system? Check the gid if they are part of the sysadm team, can they log into servers? check the GID, this is everywhere.
Now we deploy crowd and find that it doesn't know what the primary group of a user is... Giant pain.
What is the ETA for a fix? 
Jeremy Nelson
added a comment - This is annoying. I can't see CWDSUP-5339 as referenced above. We have users that aren't members of Domain Users (we don't want them logging into any other systems). We had to create a Dummy Group to give them a primary group other than the one group they need to be part of.
Jeremy Nelson
added a comment - This is annoying. I can't see CWDSUP-5339 as referenced above. We have users that aren't members of Domain Users (we don't want them logging into any other systems). We had to create a Dummy Group to give them a primary group other than the one group they need to be part of. Confirmed this bug:
As discussed in https://support.atlassian.com/browse/CWDSUP-5339, no matter which group is set to be the "primary group", crowd ignores this group on AD sync.
I worked around by setting the primary group to "Domain Guest" (or something like "atlas-tool-user") which has no grants / roles in any other system(s).
So a user with primary group "atlas-tool-user" and secondary group "confluence-users" has just the "confluence-users" group after sync.
A user with "confluence-users" only (which must be set as primary then) has no groups in Crowd.
Please note: The group must be "visible" to the crowd-user which binds to AD. If your BaseDN is set to a path which doesn't include the AD default groups, they can't be "synced" either!
Bug confirmed for Confluence Version 5.3.
Gives us a lot of trouble with restrictions, sharing pages with groups
and delayed the introduction of confluence by 5 months.