LDAP Authorization does not map ldap groups to drupal roles

Does the ldap_authorization test produce any results for this user?

Marked LDAP Authorization/SSO: 'user/login/sso' authenticates but does not log user in as duplicate issue.

@Dimas_: Did you ever resolve this issue with your install? I'm having the exact same problem, except that my "After Mappings and Filters Applied" sections says the following:

Use Mappings as Filter = 1
Configured Mappings
CN=DrupalAuthor,OU=Security Groups,OU=All Users,DC=SERVERNAME,DC=com|author
CN=DrupalEditor,OU=Security Groups,OU=All Users,DC=SERVERNAME,DC=com|editor
...and so on...

Also for me, this is what the debug logs say when I test the Authorization setup against my username "jayhawkfan75":

jayhawkfan75 : testing with consumer type drupal_role. ldap authenticated=yes
ldap_search() call: base_dn: ou=all users,dc=SERVERNAME,dc=com, filter = (samaccountname=jayhawkfan75), attributes: dn,mail,,samaccountname, attrsonly = 0, sizelimit = 0, timelimit = 0, deref = , scope = 3
jayhawkfan75 :_ldap_authorization_ldap_authorization_maps_alter:
deriveFromDn authorization ids: 
deriveFromAttr authorization ids: 
merged authz_ids authorization ids:
jayhawkfan75 : initial proposed authorization for drupal_role: .
jayhawkfan75 : filtered authorization for drupal_role: .

@Domas_: That stinks. I hope that I don't have to resort to that, as it's one of the coolest features of this module. I really want user's accounts to be automatically-updated by this setup.

@johnbarclay: Is there any word on the status of this issue report?

After some further testing and debugging, I solved my own issue by checking the Authorization test closely using the "Use 10 random users" option. (This is a very nice debug feature!)

So I thought I'd share what worked for me:

1. I noticed that some Drupal roles were actually created for other users although mine weren't.
2. I then ran the Server test, and noticed a longer DN. Compared to the Authorization DN under "Mapping of LDAP to drupal role, I could see that the "ou" attribute was missing.
3. When I copied and pasted each DN from that test and re-ran the Authorization test, the roles were mapped to Drupal roles properly.

Hi..I've got a problem with the mapping.

I created a new ROLE called "members".
And this is the my user's DN (for example):

uid=1234444,OU=Dipendenti,OU=Astro,O=Astro Group

Now I'd like to assign role called "members" to my user "1234444" or...if it's possible...to all user of OU "Dipendenti".

Can you tell me how to configure the section "Mapping of LDAP to drupal role (one per line)" ?

Thanks.

Sure. I can share how I've set it up. I first created three new security groups in Active Directory named DrupalAuthor, DrupalEditor and DrupalNews.

Then I added the following three mappings under "Mapping of LDAP to drupal role (one per line)":

CN=DrupalAuthor,OU=Drupal Groups,OU=Security Groups,OU=All Users & Groups,DC=MYDOMAIN,DC=com|author
CN=DrupalEditor,OU=Drupal Groups,OU=Security Groups,OU=All Users & Groups,DC=MYDOMAIN,DC=com|editor
CN=DrupalNews,OU=Drupal Groups,OU=Security Groups,OU=All Users & Groups,DC=MYDOMAIN,DC=com|news

So I guess in your case, after you've created a AD security group named "DrupalMembers" or something similar, you'd enter the following under that section:

CN=DrupalMembers,OU=Drupal Groups,OU=Security Groups,OU=All Users & Groups,DC=YOURDOMAIN,DC=com|members

The "OU=Drupal Groups,OU=Security Groups,OU=All Users & Groups" part all depends on how you set that up in AD.

Hope it helps.

So, is the requirement that the GROUP be listed FIRST?? I also have it such that my users specific name is listed first as the CN. "CN=User Name, OU=My Users, etc...".

Aside from changing the AD itself, is there a way to tweak the plugin to search for the group name further down the DN?

I *think* that it all depends on how you have your server set up at admin/config/people/ldap/servers. I currently have one server set up to use group settings, so it searches for the groups. You may be able to set up that section to use users instead, and then reference them on the Authorization's mapping section at admin/config/people/ldap/authorization/edit/drupal_role.

But I'd need verification of that from someone more knowledgeable.

I have the same problem here but the solution that jayhawkfan75 said didn´t work for me. Using devel to check the DN here I just copied and pasted to the field: 'Mapping of LDAP to drupal role (one per line)'.

I wonder if the attribute 'cn' is really needed because in our corporation we only use 'ou' and 'dc' (ou=users;dc=domain;dc=com) to organize the ldap server. Can anyone please give me a light?

Prefiltered and Final Mappings
Below are the "raw authorizations" and which strategy they are derived from. If enabled, the mapping filter is applied to these.
Derive from DN (without filter)
inativo
Groups DNs (without filter)
Mostrar After "Convert full dn to value of first attribute before mapping"
Esconder After Mappings and Filters Applied
Use Mappings as Filter = 1
Configured Mappings

cn=group1,ou=groups,ou=intranet,ou=services,dc=dominio,dc=com|node:group1:member (raw: node:3:5)
cn=group2,ou=groups,ou=intranet,ou=services,dc=dominio,dc=com|node:group2:member (raw: node:2:5)
cn=group3,ou=groups,ou=intranet,ou=services,dc=dominio,dc=com|node:group3:member (raw: node:5:5)
cn=group4,ou=groups,ou=intranet,ou=services,dc=dominio,dc=com|node:group4:member (raw: node:4:5)
cn=group5,ou=groups,ou=intranet,ou=services,dc=dominio,dc=com|node:group5:member (raw: node:6:5)

Also I am not able to map the groups, someone came to the solution?, Above is my output when I test the organic groups

I'm seeing this as well. I have it working in D6, and while it's deriving groups from the LDAP DN, it isn't searching any groups. It just isn't doing it.

gash7: try turning off "use mappings as filter". That filters out the groups, rather than including them. (There doesn't appear to be a way to have both includes and a filter.)

Debugging note, when I include a Test Group LDAP Entry, it is returning an arrays of cn, objectclass, and uniquemembers (which is correct, as far as I can see). So, that part works. It's just not doing the next steps...

.. (Array, 8 elements)
cn (Array, 2 elements)
count (Integer) 1
0 (String, 3 characters ) TestGroup
0 (String, 2 characters ) cn
objectclass (Array, 3 elements)
count (Integer) 2
0 (String, 18 characters ) groupOfUniqueNames
1 (String, 3 characters ) top
1 (String, 11 characters ) objectclass
uniquemember (Array, 192 elements)
2 (String, 12 characters ) uniquemember
count (Integer) 3
dn (String, 37 characters ) cn=TestGroup,ou=TestGroups,dc=example,dc=com

(Note, this is from the server config test. Where it's failing is in the Authentication, where it's deriving default DN fine, but not even looking for groups.)

eta: In Drupal 6 there was a box for "LDAP DNs containing groups". That seems to be missing.

I found a working setting!

In ldap configuration, "LDAP Group Configuration",
Name of Group Object Class: group
uncheck "A user LDAP attribute such as memberOf exists that contains a list of their groups...."
LDAP Group Entry Attribute Holding User's DN, CN, etc.: member
User attribute held in "LDAP Group Entry Attribute Holding...": dn

The weird point is that you have to uncheck the memberOf related setting to make it working.

#19 worked for me! Thank you kinglok!

I spent a couple of days spinning my wheels trying all sorts of combinations to try to get the roles to map over from Active Directory. I could see the roles when I would test "Server configuration" page but not when I would run a test from the LDAP Authorizations page.

This has got to be a bug! Apache Directory Studio shows the memberOf attribute with a list of group DNs. I could not understand why one test would show the roles and another would not.

I agree with @nullkernal

#19 also worked for me after days of trying to asses why this was not working. MemberOf "should" work but it seems to do nothing.

#19 worked for me too.

Thank you very much kinglok!

I found some clues while looking into this (2008 ActiveDirectory), I suspect that ldap_servers_attributes_needed() is not returning all the fields required

Name of Group Object Class = "groups"
Attribute in User Entry Containing Groups = "memberOf"
LDAP Group Entry Attribute Holding User's DN, CN, etc. = "distinguishedname"
User attribute held in "LDAP Group Entry Attribute Holding..." = "dn"
Groups are derived from user's LDAP entry DN. is ENABLED
Attribute of the User's LDAP Entry DN which contains the group = "ou"
LDAP TO DRUPAL ROLE MAPPING AND FILTERING = "CN=drupal,OU=webadmin,DC=drupal,DC=local|editor"

When LdapServer::groupUserMembershipsFromUserAttr() is called $user['attr'][$this->groupUserMembershipsAttr] was empty, this was my first clue - I knew I set that value but it's not set in the $user attributes returned from the LDAP server, I performed a command line query and could confirm the values I was after were coming across the wire

In userUserNameToExistingLdapEntry(..) it loads the attribute maps that are required

     $attribute_maps = ldap_servers_attributes_needed($this->sid, $ldap_context);
     $attributes = array_keys($attribute_maps);

But $attributes does NOT contain distinguishedname nor memberOf

The ldap_servers_attributes_needed(...) implements a hook_ldap_attributes_needed_alter.

There is ldap_user_ldap_attributes_needed_alter and ldap_authorization_ldap_attributes_needed_alter which adds DN, mail_attr (mail), picture_attr (picture) etc BUT never $ldap_server->groupMembershipsAttr nor $ldap_server->groupUserMembershipsAttr values

So, it seems to be
1 - ldap_authorization_ldap_attributes_needed_alter(...) never adds groupMembershipsAttr to the $user attr, ever.
2 - ldap_authorization_ldap_attributes_needed_alter(...) is called with an $ldap_context of 'all' which means it's skipping adding 'groupUserMembershipsAttr' to the $user attr.

This feels to me like the concept of 'contexts' needs a little bit of a tidyup, supplied patch got me going but I'm not sure it's totally the right way forwards

The steps I followed are at https://www.drupal.org/node/1302070

Hello!

Just in case this helps anyone else, #19 SORTA worked for me :)

The only thing is, the Name of Group Object Class for my LDAP setup is "posixgroup" and not "group"

I agree with #19 as well, though I had a completely different configuration than https://www.drupal.org/node/1302070, so here it is if it helps:

Connection Settings
Machine name: anything
Name: Anything
Enabled: Checked
LDAP Server Type: Active Directory
LDAP Server: IP address of our server
LDAP Port: 389
Use Start-TLS: Unchecked
Follow LDAP Referrals: Unchecked

Binding Method
Binding Method for Searches: Service Account Bind
DN for non-anonymous search: (a user on my AD) CN=username,OU=A_Department,OU=A_Branch,DC=domain,DC=local
Password: that user's AD password

LDAP User to Drupal User Relationship
Base DNs for LDAP user, groups, and other entries: OU=A_Branch,DC=domain,DC=local (in our AD, everything is grouped under a single branch first.)
AuthName attribute: samaccountname
Email attribute: mail
(everything else blank)

LDAP Group Configuration
Name of Group Object Class: group
Nested groups are used in my LDAP: unchecked
A user LDAP attribute such as memberof exists...: checked
Attribute in User Entry Containing Groups: memberof
LDAP Group Entry Attribute Holding User's DN, CN, etc.: distinguishedname
User attribute held in "LDAP Group Entry Attribute Holding...": dn
Groups are derived from user's LDAP entry DN: unchecked
(everything else blank)

On the Authorization tab I used the following to set up my three groups and map them to the three roles under Mapping of LDAP to drupe role
CN=Department Admins,CN=Users,DC=domain,DC=local|Department Administrator
CN=IT Admins,CN=Users,DC=domain,DC=local|IT Administrator
CN=HR Admins,CN=Users,DC=domain,DC=local|HR Administrator

Hope this helps someone! I felt like dancing when it finally worked for me.

@Saoirse1916 #25
I wonder what version of the ldap module you are using, as I have tried replicating your results with the latest 7.x-2.beta-8 version, but cannot succeed, and I can see the groups by listing the memberof attribute in the ldap query test page.
did you use the dev version?
Thanks.

No patch required, the suggestion from #19 worked for me. Even though the attribute "memberOf" does exist on the User object, this did not work properly until I unchecked that selection in the server groups settings.

@grahamtk sorry I didn't see your reply -- I'm using the dev version at the moment.

Since there wasn't any additional input here for two years I'm closing this issue as outdated.

If you are still running into this with 2.3 or a current dev version, please open another issue.