Hello,

I am using ldap 7.x-2.0-beta6 and OG 7.x-2.4.

I have users authenticating via LDAP and then am attempting to map them into an OG role. The LDAP authentication works fine, as does the OG role mapping on the initial login but it breaks once the LDAP Authorization is mapping them to a role they already have (administrator).

Steps to reproduce (use a user that has never logged into Drupal before):

1. Map a user's LDAP group to administration role in Drupal (regular overall Drupal admin, not an OG group admin)
2. Map that same LDAP group to an OG membership role in an OG group.
3. Login with that user.

This should work fine, as its the initial login. Everyone gets mapped happily to where the should be. User will be a Drupal administrator and a member of the OG. Now...

4. Remove that user from the group (keep the LDAP->OG mapping, just manually remove the user from the group).
5. Logout and back in with that user.

This will result in the user logging in successfully, but failing to be assigned membership in the organic group.

6. Map them to a new organic group, one that they have not been a member of before.
7. Log out and log back in.

This will also result in the user logging in successfully, but failing to be assigned membership in the organic group.

It seems to happen whenever there is an LDAP Authorization mapping in place that the user already has. In this case, on each login the user would be assigned to 'administrator' role. The first login everything works. On subsequent logins, when the user already has admin status, their OG roles stop getting mapped.

Comments

RyanPrice’s picture

Title: LDAP Authorization 7.2 and OG 7.2 - roles only assigned on initial login » LDAP Authorization 7.x-2.0-beta6 and OG 7.x-2.4 - roles only assigned on initial login

Update version numbers in title.

RyanPrice’s picture

To update, I've narrowed this down to the flushRelatedCaches function that is run after the grant/revoke step. If I kill the process after grant/revoke, the entry is in the DB.

If I let flushRelatedCaches run, the entry is wiped.

RyanPrice’s picture

Ignore my last comment (#2). It is not the flushRelatedCaches, but rather the user_save() function just after the grant/revoke in the LdapAuthorizationConsumerOG.class.php

Obviously user_save won't be touching the og_membership table on its own so I am not trying to identify if there are any hooks called from within the LDAP suite of modules that may be causing this issue...

pahles’s picture

I have the same issue using beta5. The problem is with the user account being a member of the Drupal administrators. As soon as the administrator user logs in, all the og_memberships disappear. Regular users don't seem to have this problem.

micahw156’s picture

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

We're seeing this manifest in a couple of different ways running 7.x-2.x-dev (6a681c9):

  1. As mentioned by previous commenters: site administrators are being removed from all groups.
  2. Some users are being subscribed to all but the first group on the list.

Things I've tried to mitigate the problem for regular users:

  1. Added a dummy group to be the first one on the list.
  2. Unchecked "Revoke OG groups previously granted by LDAP Authorization but no longer valid."

I'm not sure if this has completely solved my problem or not, but it's not a long-term solution anyway.

Here's an example of my current mappings:

DVCPeople|node:142:2
ALLFACULTY|node:142:2
ADMPeople|node:142:2
DVCPeople|node:99:2
ALLFACULTY|node:99:2
ADMPeople|node:99:2
DVCPeople|node:100:2
ALLFACULTY|node:100:2
CURRENTSTUDENTS|node:120:2
CURRENTSTUDENTS|node:121:2

I'm going to dig into the code on this, probably by trying to pick up where #1588068: LDAP Authorization: group memberships removed on login left off and see if I can find any reason why this isn't working right.

This issue appears to be at least similar to:

Edit: I've also set #1907782: LDAP Authorization 7.x-2.x and Organic Groups 7.x-1.5: Group Granting and Revoking back to closed since these issues have essentially replaced that one.

RyanPrice’s picture

Glad to see others experiencing the same issue.

@micahw156;
I've been working my way through the code as well but needed to stop. I plan on coming back, but where I left off was tracing through the code finding out where I could kill the process and people would still in the groups mapped. I left off on field_attach_update in the user_save() function. Killing it before that call, they assigned to the group. Killing it after that call, they were not.

I haven't had time to jump into it deeper and find exactly what hook is removing them, but its a place to start if you wanted to test that yourself and continue.

micahw156’s picture

A little more info here. I've been able to reproduce this reliably (unfortunately) even with none of the LDAP OG related modules enabled.

I'm trying to build a new Open Atrium site and (as a Drupal administrator user) I keep getting booted out of the group every time I log in.

I only have these LDAP-related modules enabled:

  • LDAP Authentication
  • LDAP Authorization
  • LDAP Authorization - Drupal Roles
  • LDAP Query
  • LDAP Servers
  • LDAP User Module

Given that configuration, you would think this shouldn't be even touching OG memberships. I can confirm that on the same site, I have a non-LDAP Drupal Administrator that is not being removed from the same groups on logout. I had to completely disable LDAP Authorization to keep my group memberships intact.

potassiumchloride’s picture

I have a similar problem, too, and it appears that users with the Drupal role "administer organic groups permissions" get their OG group memberships stripped upon login and authorization. This did not happen with 7.x-2.0-beta8 but does with -beta11.

grahl’s picture

Status: Active » Closed (duplicate)

I'm closing this as a likely duplicate of #2064319: LDAP Authorization OG: OG Groups not assigned to users with Administer Organic groups permission. Please reopen the other ticket if the workaround there does not work for you or clarify this ticket to differentiate it from it that one and reopen.