Problem/Motivation

I can successfully authenticate, but no matter what I do, I can't seem to get authorization working.

I am trying to use an LDAP entry per role with multiple memberUid attributes whose values are the cn's for each user in that role.

So, something like:

DN: cn=Admins,ou=blah,ou=blah2,o=IC.
objectClass: Top
objectClass: groupOfNames
objectClass: posixGroup
cn: Admins
gidNumber: 11
description: Administrators
fullName: All the CMS users in the Administrator role.
memberUid: test1
memberUid: test2
memberUid: test3
memberUid: test4
memberUid: test5

test1 - test5 each have their own entries in the directory. And I can successfully sign in with them.

On admin/config/people/ldap/authorization/edit/drupal_role:
* Selected my server, and enabled this configuration.
* Ignored II.A and II.B.
* II.C:
** "roles exist as LDAP entries where a multivalued attribute contains the members' CNs" is checked
** LDAP DNs is set to: cn=Admins,ou=blah,ou=blah2,o=IC.
** Attribute holding roles members is set to: memberUid.
** Search all enabled ... checkbox is checked.
* III.A I've tried several things:
** cn=Admins,ou=blah,ou=blah2,o=IC|administrator
** cn=Admins,ou=blah,ou=blah2,o=IC | administrator
** Admins | administrator
** Use LDAP group to drupal roles filtering is checked.
* IV all checked except "Manually or via another module."

The LDAP Authorization debug message in the Recent Logs report says:

test1:
LdapAuthorizationConsumerAbstract grantsAndRevokes() method log. action=grant:
no actions

I just downloaded the latest dev release of 1.0 today.

Comments

seancoy023’s picture

seancoy023 commented

I thought I was having the same problem as you where the roles were not being assigned.

I have a fairly identidcal setup with usernames as memberUid attributes of a group; cn=Groupname,ou=Groups,dc=blah,dc=blah2.

II.a and II.b are blank

I changed II.c to

LDAP DNs containing roles (one per line)
ou=Groups,dc=blah,dc=blah2

Attribute Holding Roles Members
memberUid

III.a
Groupname|<some drupal role>
"Use LDAP group to drupal roles filtering" is checked

IV.B
"When a user logs on" is checked

IV.C
"Re grant drupal roles previously granted by LDAP Authorization but removed manually." is checked
"Create drupal roles if they do not exist." is checked

After changing to this setup it worked. I get an annoying php error,
# Notice: Undefined index: drupal_role in ldap_authorization_test_form_submit() (line 125 of /var/www/html/sites/all/modules/ldap/ldap_authorization/ldap_authorization.admin.test.inc).
but users in Groupname can login and be assigned <some drupal role>.

jerrac’s picture

jerrac commented
Version: 7.x-1.x-dev » 7.x-1.0-beta4
Priority: Normal » Minor

Hmm... I think I actually tried that config, and it didn't work for me. I must have had some setting set to something different.

I did get it working though. I just had to change from using II.C to using II.B and add a groupMembership to each of my users.

But shouldn't my initial config have worked?

seancoy023’s picture

seancoy023 commented

** LDAP DNs is set to: cn=Admins,ou=blah,ou=blah2,o=IC.

I would think that this line would cause you to recursively search inside of Admins for Admins.

johnbarclay’s picture

johnbarclay commented

Nested or recursive groups are not supported. Here is the feature request: #1016728: LDAP Authorization: Nested group recognition for authorization in group strategy IIB and IIC

jerrac’s picture

jerrac commented

First off, my understanding of LDAP is very basic. The only reason I'm dealing with it at all is that the guy who normally dealt with it left. So, perhaps I'm just not understanding what you mean by 'group'.

The way I think II.C works is this:

Have an a single entry in the LDAP directory, doesn't matter where, just one entry. In that entry have multiple memberUid attributes that are the CN's of the users. Then map every user in that entry, to a single Drupal role.

So, the code would look at cn=Admins,ou=blah,ou=blah2,o=IC, grab all the memberUid's, then use those values to see if the user signing in belongs to the administrator role.

Is that not the way it is supposed to work?

joverstreet’s picture

joverstreet commented
Priority: Minor » Normal

I'm also having this issue and have tried a variety of configurations. Has anyone gotten Authorization to work with II.C? Can you list what your settings are?

I also get the Error/Notice:
Notice: Undefined index: drupal_role in ldap_authorization_test_form_submit() (line 125 of /drupal/sites/all/modules/ldap/ldap_authorization/ldap_authorization.admin.test.inc).

Any help would be greatly appreciated as we've been spending way too much time trying to get this to work.

johnbarclay’s picture

johnbarclay commented

The unit tests themselves don't work, so I doubt this will work for anyone. Here is the other bug report: #1317816: LDAP Authorization: II.C. Simpletests for all Derive From Entry Cases are broken

soundasleep’s picture

soundasleep commented

I also had option II.C selected, and configured as:

cn=DRUPAL_ADMINISTRATORS,ou=Groups,dc=foo,dc=org

With III.A, the mapping and filtering, set to:

cn=DRUPAL_ADMINISTRATORS,ou=Groups,dc=foo,dc=org|administrator

And it wasn't working at all for me either. After some digging in #1317816: LDAP Authorization: II.C. Simpletests for all Derive From Entry Cases are broken, it turns out that II.C is defined correctly, it's just that III.A needs to instead be set to:

DRUPAL_ADMINISTRATORS|administrator

However, the documentation for III.A suggests that it should be the former, not the latter. All that might be required is a fix to the documentation.

johnbarclay’s picture

johnbarclay commented
Version: 7.x-1.0-beta4 » 7.x-1.x-dev
Component: Code » Documentation
Category: support » bug

So maybe the list below should match IIA-IIC examples and have the example # before it. Like?

III.A. LDAP TO DRUPAL ROLE MAPPING AND FILTERING

The settings in part II generate a list of "raw authorization ids" which need to be converted to drupal roles. Raw authorization ids might look like the following depending on which of the options in II. are chosen:

  • IIA: Campus Accounts
  • IIB. ou=Underlings,dc=myorg,dc=mytld,dc=edu
  • II.C. not sure what an example would be for this?

(II.B and II.C. should generate DNs for raw authorization ids as in the first 2 examples. II.A. will generate a simple string such as the third example.)

dddanmar’s picture

dddanmar commented

Woah! Been ripping my hair out all day with this, convinced I was doing something horrible wrong.

However, soundasleep was right on the money.

I had previously:
cn=rolegroup1@domain.com,dc=domain,dc=com|level1

I changed it to just
rolegroup1@domain.com|level1.

Worked immediately. Thank for for that soundasleep!!! Life saver!

johnbarclay’s picture

johnbarclay commented
Title: Authorization: Roles not being granted » LDAP Authorization: Roles not being granted
Category: bug » support
Status: Active » Closed (fixed)

this has turned into a support request, so I'm closing it. Please try to add this sort of thing to the documentation or comments in the documentation. That way we can get the common use cases in the documentation.

johnbarclay’s picture

johnbarclay commented

Strategy 3 in ldap authorization is still problematic for some use cases. See #1412076: LDAP Authorization: Rework Strategy 3: groups as entries to meet more use cases

kenorb’s picture

kenorb commented
Related issues: +#1412076: LDAP Authorization: Rework Strategy 3: groups as entries to meet more use cases
kenorb’s picture

kenorb commented
Related issues: +#2164883: LDAP server test returns no group/role memberships