it.nat I suspect you are talking about in JIRA not in Crowd?

This particular bug report pertains to the problem in Crowd ... the same bug is also reported against JIRA at JRA-36555
JRA-36555 states that this bug is fixed in JIRA 6.2 ... if you are still seeing problems I suggest you raise a support request.

Has this fix be lost again 6.2 ?

I have updated Crowd in JIRA so this fix should be part of JIRA 6.1.6 release.

awesome, thanks.

it.nat,

Apologies if I wasn't clear enough. By "the behaviour described in the previous comment is not a bug. It's the intended behaviour" I meant that Crowd is not trying to be smarter than the LDAP server, and it is not re-creating the bi-directional links if the LDAP server does not produce them. As far as I can tell, this has always been the behaviour of Crowd, and it hasn't changed recently.

As onevalainen points out, in Crowd 2.7 we introduced an improvement to the authentication process (CWD-3429) which, when combined with the mentioned behaviour, creates a regression for some customers. We're currently working to fix this regression.

I'll edit my previous comment to clarify this point.

Hi it.nat

Unfortunately Confluence is already affected (see CONF-31338). We do consider this a bug as it is a regression and will strive to fix it so that changes are not required in LDAP.

And does this also mean confluence will adopt this behaviour at some future release? We have 3000 users of confluence that use the same LDAP server for authentication and group based ACLs and its worked this way for several years, if confluence changes to use this latest version of CROWD then that will break confluence as well.

not all LDAP servers maintain those bi-directional links, if you are saying this is not a bug and to live with it then thats going to break an awful lot of stuff.

The behaviour described in the previous comment (namely, that Crowd does not re-create the bi-directional link if the LDAP server does not produce it) is not new. It has been the behaviour for years when these two conditions are met:

• You're using a LDAP connector (other than AD) with the Use the user membership attribute option checked, and
• Your LDAP server does publish the 'memberOf' attribute from the user side, but does not publish a symmetrical 'member' attribute from the group side.

The Use the user membership attribute means: use the 'memberOf' attribute to list the users-of-a-group, but use the usual query (that is, the 'member' attribute of the group) when querying the list of groups-of-user. It's an optimisation for the case in which we know that both attributes are available in the LDAP server.

LDAP servers can maintain these bi-directional links automatically if configured to. For instance, in OpenLDAP you can use overrides.

If the LDAP server does not publish the bi-directional links (let's say it only publishes the 'memberOf' attribute from the user to the group, but not the 'member' from the group to the user), then enabling Use the user membership attribute will produce divergent results when querying groups-of-user and users-of-group, as the relationship will be only visible from one side.

This was not affecting products other than Crowd (until they upgraded to Crowd 2.7), because products were using cached directories. Cached directories are not affected because:

• When the cache is synchronised, the membership information is always retrieved in only one direction (using findDirectMembersOfGroup()). Therefore, there was no divergence.
• Once cached, the membership information is symmetrical in the database, therefore all queries share the same view of the information.

After upgrading to Crowd 2.7 and picking CWD-3429, all products suffer a regression because when the user authenticates, the products make a query to findGroupMembershipNames which (except for AD), delegates to findGroupMembershipNamesOfUserViaMemberDN. This method always uses the 'member'/'uniqueMember' attribute, never the 'memberOf' attribute (regardless of the Use the user membership attribute setting). Therefore, if the LDAP server is not publishing the 'member' attribute of the group (only the 'memberOf' attribute of the user), then the query will not retrieve the groups, causing them to be removed from the user in the cache and potentially preventing the user from logging in.

Investigation continues. If you set up an uncached directory with exactly the same configuration, then the relationship between the user and the group is visible when listing the users of the group, but not when listing the groups of the user. See attached screenshots.

Note that listing the groups of the user is exactly the query that happens when the memberships are updated on authentication, so this is consistent with the observed effect.

Tracing the execution shows that Crowd is using the following LDAP filter to retrieve the list of groups of the user: (&(objectclass=groupOfUniqueNames)(uniqueMember=cn=user,dc=example,dc=com)), which returns no results given the LDAP data described above (see screenshots). Compare that to the LDAP filter used when retrieving the list of users of a group: (&(objectclass=inetorgperson)(postalCode=cn=mygroup,dc=example,dc=com)) (which is correct).