I am building a fairly complicated LDAP and OG integrated site. When an LDAP users logs in the first time the system properly assigns Drupal roles and OG groups based on their LDAP groups membership. When the same users logs in a second time it revokes all their OG memberships. During subsequent authentications it alternates between assigning and revoking membership on each login.

I updated the site from 7.x-2.0-beta5 to the current dev without success. I don't see any issues in the queue reporting similar problems (although obviously I could have missed it), so I'm sure there are other issues in play since it seems like lots of people would complain if it were common. I'd be happy to provide additional information, but I'm not sure what would be useful. I believe the basic mappings are correct, since it successfully assigns the correct groups 1/2 the time.

I had to tweak the requested config information to hide the information about who owns the site, but it's very close to accurate. Like I said, it connects to the server every time, and works end-to-end 50% of the time.


acrosman’s picture

After more review I figured what's causing this, and a work around for anyone else that gets this far.

The issue came up because we have multiple roles defined within OG. During the first pass, og2Grants() correctly adds the user to both the role they are assigned to and the base member group. During the second pass the system notices that the base member group isn't in the mapping, and revokes their group membership, while preserving their role that's in the mapping. During the third pass, the module again, correctly, recognizes that the user is not a member of the group and re-adds both the role and the base membership.

The work around is to place two rows into the OG Authorization map, one for the "member" role, and the second for any additional roles.

og2Grants(), og2Revoke(), or (probably better) grantsAndRevokes() should recognize what's happening here and provide a more robust solution. If it's going to automatically add a user to multiple groups, it should not flag that as an error on the next pass and remove the automatic membership.

jlashomb’s picture

Priority:Normal» Major

I can confirm this issue. Our site has a lot of memberships and the module seems to have problems when you have over 225 lines in the configuration for OG, so it's not really feasible for us to double every assignment to also include a member roles assignment.

I'm marking this as major seeing how it's completely broken every other time someone logs in.

micahw156’s picture

This is similar to #2144637: LDAP Authorization 7.x-2.0-beta6 and OG 7.x-2.4 - roles only assigned on initial login, but that issue does not discuss the problems assigning roles. I've experienced problems similar to both issues, but role assignment has worked for me at all. (I only get member, not any custom roles.)

P.Suppers’s picture

Issue summary:View changes

I can confirm this issue. I've tried version 7.x-2.0-beta8 but after each logon the user is a member > not a member > a member > not a member ...

I found a not so nice workaround by disabeling "Revoke OG groups previously granted by LDAP Authorization but no longer valid." resulting in an out of sync AD security group vs OG group.

dillweed’s picture

Priority:Major» Critical

I am having the same problem. This problem really is a deal breaker for our company intranet. Would it be permissible to change this to critical?

vgalindus’s picture

I have had the same problem, the issue comes from having a mapping for users directly mapping to a role and with no member role. If this happens when ldap does a diff between drupal og group roles and the roles provided from the AD member role is set to remove it from the user and in the code there is a check to unregister user from that group if member role is present in revoke function.

if (in_array($authenticated_rid, $revoking_rids) || count($remaining_rids) == 0) {  // ungroup if only authenticated and anonymous role left
           $entity = og_ungroup($group_entity_type, $gid, 'user', $user->uid);

I think this can be removed, at least it works fine for me but needs to be tested in other configurations.

Attached patch.

johnbarclay’s picture

johnbarclay’s picture

acrosman’s picture

I don't have my test environment for this one up at the moment, but the approach in the patch from #6 doesn't look right to me.

If the authenticated role ID is in $revoking_rids, than they should be removed from the group. It seems like the $authenticated_rid shouldn't be in the list of to be revoked in the first place, and this code would behave as it should.

That said, I'll try to find time in the next couple weeks to retest in the environment I first discovered this issue it it see if the patch works in that configuration.

kenorb’s picture

Status:Active» Needs review
joshua.albert’s picture

I was having this problem, as well. I had an LDAP group mapping for normal group users, as well as an LDAP group mapping for group admins. When I mapped to a group admin user, every other time I logged in as that user, it would revoke, and then grant the group I assigned the user as an admin to.

I was able to solve it by explicitly mapping the normal group member role AND the admin role.
In other words, this presented the alternating revoke/grant problem:


...while this fixed it:


Where 5 is normal group user role and 6 is an admin role.

peronas’s picture

new2.51 KB

I've been running up against this issue as well the last day or two. I dug through and found a couple of calls to og_roles in the flow for normalizing the mappings that were coded to pull the roles for group 0 rather than the group specified in the mapping. This was resulting in the mapping normalizing to the wrong role IDs and in turn the expected authorization mapping used in the diff step did not include the role IDs for the actual groups roles. Since the actual groups roles weren't in the mapping they get revoked.

I changed the og_roles calls to use the actual groups ID and this has resolved it for me.

Note: On the 7.x-2.x branch the attribute query code seems to have changed slightly from beta8 so I also needed to add the member attr to the attributes needed list.