Recently upgraded to LDAP 7.x-1.0-beta12 about 2 weeks ago. Since then, when we add users to LDAP groups mapped to roles that existed prior to the installation of beta12, they are never successfully added to the mapped roles when the users login. However, if we create a *new* role since the installation of beta12, with a new mapping, and a new LDAP group, then users are successfully added to those new roles when they login.

Also, when we remove users from groups mapped to roles created prior to installation of beta12, they are not automatically removed from those roles upon login. However, if we remove a user from a group created *after* installation of beta 12, then they are automatically removed from the mapped role that was also created after installation of beta 12 upon user login.

Long story short... Installing beta12 seemed to hose all of our existing roles and mappings.

I can still manually add users to Drupal roles, and manually remove them, using the Drupal web interface to do so, not the LDAP module. And if the roles existed prior to installation of beta12, then these manual role configurations are left intact. For roles created/mapped after installation of beta12, any manual role population/depopulation is undone upon login by user, which is as expected.

How do we fix this? Please help us!!! Any help is greatly appreciated.

- John

Comments

johnbarclay’s picture

johnbarclay commented

I would say this is a duplicate of #1744240: LDAP Authorization: II.B. DERIVE DRUPAL ROLES BY ATTRIBUTE issue where roles are revoked after upgrade, but perhaps is related to #1066608: module is not checking the OU roles object by looking for a member that is the DN comment 48 to 52. Sounds like the mapping is correct if it works for new users, so don't think #1066608: module is not checking the OU roles object by looking for a member that is the DN is related.

I suspect that has to do with case sensitivity of the authorization ids and the best way to debug it is trace through these functions and see what is happenning. Do you have "regrant" authorizations checked?

ldap_authorization/ldap_authorizatin.inc/_ldap_authorizations_user_authorizations_set()
ldap_authorization/ldap_authorizatin.inc/_ldap_authorizations_user_authorizations()

If you don't have trace setup, you can also enable ldap_help module and check detailed logging on the main ldap config page that will put more data in the watchdog logs.

NimbyDagda’s picture

NimbyDagda commented

Hi John,

We are also getting the same error, as soon as we updated none of the new users are getting the role assigned to them. I have tried all the variations of the previous case issues and that doesn't fix it. Having seen this I have tried adding a new role and that doesn't get assigned either. Basically it seems that since the most recent beta update, the roles have just stopped being applied automatically.

So just turning on LDAP Help the only added value in the log file is

LdapAuthorizationConsumerAbstract grantsAndRevokes() method log. action=grant: %consumer_ids_log#012

I will get round to setting up tracing but maybe not today.

--Ash

MrSasquatch’s picture

MrSasquatch commented

Yes, we have the "regrant" option checked.

NimbyDagda, it is comforting to know that someone else is experiencing this. For us, it doesn't seem to have anything to do with users created before versus after the LDAP module upgrade. It seems to have more to do with group-to-role mappings added before versus after the upgrade. Mappings added before no longer work. Mappings added after work fine.

I will do whatever I can to troubleshoot and help this module. But I don't know how to "trace." I also don't know what "watchdog logs" are. I am an advanced Drupal "site builder," but I have no experience debugging modules. Nevertheless, I am happy to do whatever legwork I can if someone can point me in the right direction for this tracing and logging. I want to learn more, and I want to help. ...and this bug is affecting mission-critical stuff here, so of course that motivates me too. :) Please advise.

Thank you in advance for any continued assistance with this.

Thanks,
John

MrSasquatch’s picture

MrSasquatch commented

Yes, we have the "regrant" option checked.

NimbyDagda, it is comforting to know that someone else is experiencing this. For us, it doesn't seem to have anything to do with users created before versus after the LDAP module upgrade. It seems to have more to do with group-to-role mappings added before versus after the upgrade. Mappings added before no longer work. Mappings added after work fine.

I will do whatever I can to troubleshoot and help this module. But I don't know how to "trace." I also don't know what "watchdog logs" are. I am an advanced Drupal "site builder," but I have no experience debugging modules. Nevertheless, I am happy to do whatever legwork I can if someone can point me in the right direction for this tracing and logging. I want to learn more, and I want to help. ...and this bug is affecting mission-critical stuff here, so of course that motivates me too. :) Please advise.

Thank you in advance for any continued assistance with this.

Thanks,
John

MrSasquatch’s picture

MrSasquatch commented

Any progress with this issue? This is a mission critical work-stopping issue for us. Please let me know how I can do that "tracing" or "debugging" on our end.

Thanks,
John

johnbarclay’s picture

johnbarclay commented

Apologies. I wrote up an explanation of the trace and debugging and must have not posted it. I added some notes to http://drupal.org/node/1141764 related to debugging ldap authorization. For this issue I would enable detailed logging, logon with a new user, and look through the watchdog logs. The how tos of this are on that page. You might also look at the $user->data array and compare what it looks like for new mappings and from older mappings.

I would also consider rolling back to the last version that worked for you.

Tracing and Debugging are terms for working with an IDE and webserver/php to step through code while seeing the values of variables and following the branching. How you set it up depends on your IDE; but you will setup xdebug on the local or remote server (http://2bits.com/articles/setting-up-xdebug-dbgp-for-php-on-debian-ubunt...) and enable your IDE to communicate with it. Here's a video of debugging with java to illustrate the process.

Much like version control and automated testing, setting up and becoming familiar with debugging environments pays off in the mid to long term.

NimbyDagda’s picture

NimbyDagda commented

So having tried my best to debug it, it seems that the authorization code (at least in our case) just isn't being called on login.

Being more specific, if I test each of the users that is failing using the authorization test facility, it identifies the mapping correctly, i.e. if the authorization code runs then it does the right thing. What seems to happen is that on logon the authorization mapping isn't executed, despite it being set to run on logon.

MrSasquatch’s picture

MrSasquatch commented

NimbyDagda, that is exactly what I am experiencing. Like you, the authorization test results are fine. But nothing happens in the live scenario when people actually log in. But like I said, this bug only affects roles/mappings that existed prior to the latest version. Any new roles/mappings I add work fine.

NimbyDagda, I'd be curious to see what results you get if you add a new LDAP group and mapping and then log in with a user who is in that new group. I suspect it will create the new Drupal role just fine, assuming you have your authorization configured to do so. Again, my point is that the bug only seems to affect roles/mappings that existed prior to the current version.

MrSasquatch’s picture

MrSasquatch commented

Thanks, johnbarclay, for your continued help with this. Much appreciated. I hope we can get this fixed soon. In the meantime, is 7.x-2.x-dev a possible remedy?

MrSasquatch’s picture

MrSasquatch commented

I believe we have discovered the cause of the problem. It turns out it has nothing to do with changes in beta12, groups/roles/mappings created after beta12 versus before, etc. The reason we thought the change to beta12 had something to do with it is because, in one or two of the betas prior to beta12, mappings and role names were suddenly forced to be lower case, which changed all of our authorization mappings to lower case upon saving. Well, now, with beta 12, that no longer happens, and suddenly everything's case sensitive. Long story short, by changing our mapping rules so that the case sensitivity of the role name in the mapping matched the role name in Drupal, now everything works.

johnbarclay’s picture

johnbarclay commented

Thanks for following through on this. Dev then beta13 will have to address this.

NimbyDagda’s picture

NimbyDagda commented

I think our problem may be different then. The first thing I tried to resolve this was changing all the roles cases to see if it was related to those various fixes. I will go through setting everything up again from scratch and see if it makes any difference.

johnbarclay’s picture

johnbarclay commented
Priority: Critical » Normal
Status: Active » Closed (won't fix)

I believe this is a duplicate of case sensitivity issues and some other ldap authorization issues. Closing as not a useful thread.