Hi, I upgraded to beta9 on Friday 8/5/16 after seeing a security notice. It all seemed to go fine, and I was able to successfully test after upgrading by logging in as user 1, an admin user, and as a regular user, and everything looked OK. However, when I came in this morning there were numerous reports of employees (our site is both our intranet and extranet, using Roles to dictate access to pages and menu items) who could not see menu items and pages that were designated for employees only.

After looking at a few, I could see that many had some of their Roles removed, including the Employee role and Departmental assignments. Basically, things that we have set to get implemented out of the LDAP Authorization module. Here is our I'm not entirely sure yet, but I think I traced it down to the setting on
/admin/config/people/ldap/authorization/edit/drupal_role
in section III where it says to "Revoke drupal roles previously granted by LDAP Authorization but no longer valid." I have had that box checked all this time, but it seems that may be an issue now. Since unchecking that box, employees logging in are still in the "employee" role, and their department roles are still marked

From that page, here are examples of the mapping of LDAP to Drupal Role
cn=Dept-WC,ou=Groups,dc=SITE,dc=LOCAL|Dept-WC
cn=Dept-WC,ou=Groups,dc=SITE,dc=LOCAL|Employee

Basically, when authenticating against LDAP (or AD, in our case), it looks for groups that the person is a MemberOf, and then tags them with a particular department and the "Employee" role. I haven't unwound the code that far, but based on the symptoms, it looks like the revocation of roles happens, then assignment is not happening. Leaving people in existing roles should be OK for us, as people rarely move around and if they do I tend to manually update their roles. But still, this was an unexpected issue.

One wrinkle is that users with the Administrator role seemed to be unaffected.

I can see there have been 2 more beta versions released over the weekend, but I'm wondering if anyone is seeing something like this or if a fix has been rolled up into the latest one.

Comments

taquil created an issue. See original summary.

taquil’s picture

Issue summary: View changes
taquil’s picture

Bonus info:
We just had a new employee start today and it confirms there's an issue in translating AD groups to roles. She was able to log into the site, authenticating against AD, but she was not added into any groups. In checking log messages, there are numerous entries from ldap_authorization, but they seem to indicate something not working exactly right in the group-role assignment. When I compare the entries from her logging in with no roles set, where I'd expect them to get mapped out of AD, one entry reads:

kwestbr : user_authorizations_set results for drupal_role:
1. Initial existing authorizations:
2. Filtered Authorizations:
3. After filtering off previously granted authorizations (if regrant is false):
4a. full consumers array, pre grants: Array ( )
4b. user auth data after grants drupal_role:

Array
(
)

4c. user data after grants for drupal_role:

Array
(
[ldap_user] => Array
(
[init] => Array
(
[sid] => auwv01
[dn] => CN=Kathy Westbrook,OU=Users,OU=Workers Comp,OU=AU,OU=B-Units,DC=SITE,DC=LOCAL
[mail] => kwestbrook@site.org
)

)

[ldap_authorizations] => Array
(
[drupal_role] => Array
(
)

)

)

5a. revokes passed to authorizationRevoke(): none 5b. user auth data after revokes drupal_role:

Array
(
)

5c. user data after revokes for drupal_role:

Array
(
[ldap_user] => Array
(
[init] => Array
(
[sid] => auwv01
[dn] => CN=Kathy Westbrook,OU=Users,OU=Workers Comp,OU=AU,OU=B-Units,DC=SITE,DC=LOCAL
[mail] => kwestbrook@site.org
)

)

[ldap_authorizations] => Array
(
[drupal_role] => Array
(
)

)

)

6a. user_edit pre save :

Array
(
[data] => Array
(
[ldap_user] => Array
(
[init] => Array
(
[sid] => auwv01
[dn] => CN=Kathy Westbrook,OU=Users,OU=Workers Comp,OU=AU,OU=B-Units,DC=SITE,DC=LOCAL
[mail] => kwestbrook@site.org
)

)

[ldap_authorizations] => Array
(
[drupal_role] => Array
(
)

)

)

)

6b. user data post save:

Array
(
[ldap_user] => Array
(
[init] => Array
(
[sid] => auwv01
[dn] => CN=Kathy Westbrook,OU=Users,OU=Workers Comp,OU=AU,OU=B-Units,DC=SITE,DC=LOCAL
[mail] => kwestbrook@site.org
)

)

[ldap_authorizations] => Array
(
[drupal_role] => Array
(
)

)

)

6c. user roles post save:

Array
(
[2] => authenticated user
)

If I manually set her roles (to Dept-WC and Employee) and then have her log in again, the only difference is in section 6c:

6c. user roles post save:

Array
(
[2] => authenticated user
[15] => Dept-WC
[19] => Employee
)

So I'm not sure if usage of the group-role mapping has changed or one of these latter versions isn't handling it correctly.

larowlan’s picture

hi @taquil are you able to use git bisect to track down when this stopped working?

Check out the module via git

git clone --branch 7.x-2.x https://git.drupal.org/project/ldap.git
cd ldap

Then start bisecting

git bisect start
git bisect bad
git bisect good 7.x-2.0-beta8

This will pick a commit in the middle of the two. Get the user to test.
If it fails type

git bisect bad

if it passes type

git bisect good

Keep repeating the process until it tells you which commit broke the feature.

If you can paste that here that'd be great

When you're done

git bisect reset

More docs here https://git-scm.com/docs/git-bisect

Thanks - @larowlan

taquil’s picture

I've gone through all the revisions, I think I followed the instructions properly, but out of 5 steps back I couldn't find any that actually worked. The roles that are set for her do not get updated, but neither do they get removed (which I am now sure was from the "Revoke drupal roles previously granted" checkbox).

I didn't save all the comments, but here were the last 4:
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[85b0be6d359a1a3e2140460e1874dc4eae11867f] Issue #2673448 by rossington350, grahamC: Cannot redeclare drupal_path_initialize()

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[c2fd739f2d65a06f6ab57cd5c24e52c580f46fe3] Issue #2379233 by sheise: Reset password access check not working correctly

Bisecting: 1 revision left to test after this (roughly 1 step)
[7b311bcf96dc5d9fd404bf5e1b362dcf42a78dc5] Issue #156882 by larowlan: Possible to log in as configured service account user without entering password

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[7e65a42a3b50f22cc349872c31869447cfee9787] Issue #2779945 by larowlan: Beta9 breaks integration with email registration module

I had not upgraded since 7.x-2.0-beta5, as I had tried beta6 when it came out and it completely failed to work with our site configuration at the time. However, rolling all the way back to the beta5 code doesn't seem to affect anything as it is not granting roles, either. I believe the upgrade to beta9 included a SQL database update. I don't know exactly what it was but I think it was something to do with forcing something to be lowercase? Something that sounded innocuous but perhaps that actually is affecting something? I didn't save the SQL db from that change.

Is there a place where I can add some diagnostic code or something to dump out what it's doing when it reads from AD or does the group-role mapping, or perhaps does SQL work on the users_roles table (I assume that is what it does)?

larowlan’s picture

There was an update hook added post beta5 - ldap_authorization_update_7204()

diff --git a/ldap_authorization/ldap_authorization.install b/ldap_authorization/ldap_authorization.install
index 61c1f89..3d35e76 100644
--- a/ldap_authorization/ldap_authorization.install
+++ b/ldap_authorization/ldap_authorization.install
@@ -365,4 +365,17 @@ function ldap_authorization_update_7203() {
     }
   }

-}
\ No newline at end of file
+}
+
+/**
+ * make all schema field names lowercase in ldap server to deal with cronic case sensitivity issues
+ */
+function ldap_authorization_update_7204() {
+
+  $schema = ldap_authorization_schema();
+  $field_schema = $schema['ldap_authorization']['fields']['mappings'];
+  if (db_field_exists('ldap_authorization', 'mappings')) {
+     db_change_field('ldap_authorization', 'mappings', 'mappings', $field_schema);
+  }
+
+}
larowlan’s picture

That was added by #2024439: ldap authorization: ldap authorization mapping form limit which was just a change in the column size.

Are you 100% certain you had beta5 and not earlier?

taquil’s picture

Yes it was beta5 for the last couple years. Upgraded my dev server to beta11 and it seems to work now. Will try in production and let you know.

grahl’s picture

Status: Active » Postponed (maintainer needs more info)

Did you ever solve this problem? Others do not seem to have the same issues as you with current versions.

micahw156’s picture

I experienced similar problems, but was unable to track down the actual cause, partially because we're running a custom fork. I can try to reproduce this in our environment and nail it down with the steps outlined in #4 above, but it might take a week or two before I can get to it.

grahl’s picture

Hi @micahw156

I'd appreciate your help in moving this issue forward but it's definitely not time sensitive, whenever you get to it would be fine.

P.S.: How custom is your fork? Are you working with custom patches and Composer or really a hard fork? If the latter, is there a chance of getting you back on the main release if we resolve enough of these issues?

grahl’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

I'm closing this issue since we did not receive additional information.

Feel free to reopen if someone can provide further information.