I have a scenario that involves users getting assigned to a pair of Drupal roles, and then group memberships for several groups, all controlled through OG. Users can either be in a basic group with very limited permissions or a moderator level group with a larger set of permissions. Everything is fine for the lower level users, the Drupal role gets assigned, and they also get assigned to all their groups. However, the moderators do not get assigned the OG group memberships unless I remove the Administer Organic groups permission from the second role.

Users in the moderator role get assigned to both the basic role, and the role with more permissions (which needs to provide Administer Organic groups). They should also be assigned to several groups in addition to the Drupal roles. Walking through the debugging messages, LDAP Authorize OG finds the list of groups correctly, but the users do not end up as members of the groups, it just seems to fail quietly. If I remove the offending permission, all group membership assignments happen properly.

I'm not completely sure this is an LDAP module issue, but since the group assignments should be handled here I'm opening the ticket here. If anyone can suggest steps to determine concretely if this is an OG or LDAP issue I'd be happy to do my part.

#10 groups-not-assigned-2064319-10.patch478 bytesrobbertnl
Members fund testing for the Drupal project. Drupal Association Learn more


johnbarclay’s picture

Status: Active » Postponed (maintainer needs more info)

What version of OG are you using?

acrosman’s picture

Status: Postponed (maintainer needs more info) » Active

Sorry, OG 7.x-2.3, and here's the LDAP Config file I created for a previous issue.

acrosman’s picture

Issue summary: View changes

fixed typo

micahw156’s picture

alberghini’s picture

Issue summary: View changes

I just encountered this error today. I set up a fresh install of Drupal 7.26 with LDAP 7.x-2.0-beta8 and Organic Groups 7.x-2.6.

I set up the LDAP server, roles and OG groups. LDAP Authorization - Drupal Roles works fine.

LDAP Authorization - OG appears to work fine in testing, but will not actually add some users to the OG groups on login.

A user with Administer Organic groups permissions is not added to the groups.

A user without the permission is added correctly to the Organic Groups.

johnbarclay’s picture

Issue tags: +D7+stable+release+blocker
johnbarclay’s picture

Issue tags: -D7+stable+release+blocker +D7 stable release blocker
potassiumchloride’s picture

We are experiencing this issue as well, with LDAP Authorization - Drupal Roles enabled but with LDAP Authorization - OG NOT enabled.

We haven't stored groups in LDAP that map to organic groups so we just use LDAP Authorization - Drupal roles. This has consistently worked for us in the past.

Now, with 7.x - 2.0-beta11 a user with a Drupal role that gives "Administer Organic Groups permissions" has his/her organic group membership stripped upon login.

This issue appears to be related to #2188147 and #2148047.

Robert_W’s picture

Now, with 7.x - 2.0-beta11 a user with a Drupal role that gives "Administer Organic Groups permissions" has his/her organic group membership stripped upon login.

I can confirm this issue with LDAP 7.x 2.0-beta11.

potassiumchloride’s picture

Version: 7.x-2.x-dev » 7.x-2.0-beta11
robbertnl’s picture

Looks like the account object is not fully loaded. I made a quickfix which might help making a final fix.

micahw156’s picture

Version: 7.x-2.0-beta11 » 7.x-2.x-dev

Setting version back to dev branch. This affects all existing beta releases for this branch, and is not specific to beta11.

micahw156’s picture


I can understand why you'd want to add this, but I don't think adding user_load() here will work. It's more likely that $account is incomplete because login is still in process, and from reading the rest of this function, that change might even cause wrong information to be written back to the LDAP directory if two-way synchronization is enabled.

I could be wrong, and I haven't dug through the code myself yet, but don't think the actual problem is in ldap_user. It's probably in either the ldap_authorization or ldap_authorization_og module.

grahl’s picture

Component: Miscellaneous » Code
Status: Active » Closed (works as designed)


So I really wanted to get these old issues out of the way and have tried reproducing this, which I was able to in the test form and in general. I've just committed a simplified version of ldap_authorization_og, which removes og1 support since it's unsupported and removes some static caching to make sure we don't have any side-effects.

The primary reported problem still exists and is a side-effect of og, I believe. The cause is that relevant groups reported back are 2 and 3 for member and admin. When revoke is enabled, ldap_authorization will in some (but not all) cases then consider group 2 not assigned 3 assigned, causing a revoke of 2 after a grant has taken place. This will cause the removal from the group entirely. I've tried to do revokes before grants to get around this but these functions can be called multiple times and then don't work deterministically.

What I've found to be a decent workaround is actually specifying the member AND the admin group as permissions:

students|node:Students:administrator member (raw: node:1:3)
students|node:Students:member (raw: node:1:2)

One would expect the user to switch between admin and member in that case but as far as I can tell this does not happen and rights stay consistently on admin.

Therefore I believe we have a solution that works with OG, even though ldap_authorization_og is being very weird here.

If anybody still has issues with this workaround on latest dev, feel free to reopen this issue.


grahl’s picture

Assigned: Unassigned » grahl
Status: Closed (works as designed) » Needs work

This broke a test, requires more work. Rolling back for now.

grahl’s picture

Assigned: grahl » Unassigned
Status: Needs work » Closed (works as designed)

Issue resolved, cache within the controller has been added back, workarounds described above still relevant.