I am not sure what I may be doing wrong. LDAP Integration is up and running without a problem but I have tried all the combinations of entries in the admin/settings/ldapgroups/edit/ I can think of. None of our AD groups ever display, and if I try to edit the ldapgroups.conf.php file, I am greeted with a blank white page where the Drupal site use to be (until I revert that file back to its origins). Can anyone who has had success with mapping AD Security Groups to Drupal roles help me out?
Thanks

Comments

kreaper’s picture

What do the Admin Logs say when you get the blank page ?

(you could also try sticking in a few msg_r() statements in the module code to see where it's breaking for you.)

a few of us have groups->roles mapping in place for quite a while.

kpm’s picture

Thanks for the reminder about logs. Nothing in the Drupal logs, but the Apache log file explained that I had screwed up in my editing of the ldapgroups.conf.php file. Fixed that, so no more blank page. But the mappings I have added are still not turning up in the /admin/user/roles list. I am a bit confused about the ldapgroups.conf.php file, it states "Note: Uncommenting this function will limit the groups -> roles conversion to ONLY those groups that are specified in the function." I never uncommented anything in this file, but its default form was uncommented. The only changes I have made, after the mappings did not show up with the settings in admin/settings/ldapgroups/edit/domainLDAP by adding "memberOf" to the "Groups are specified by LDAP attributes" text box, was to add the mapping to the AD security groups. I have included a sample of my entire ldapgroups.conf.php file below:

<?php
// $Id: ldapgroups.conf.php,v 1.7 2007/03/03 03:23:56 scafmac Exp $

//   Interesting constants that admins would want to mess with

//   The module automatically decides names for the Drupal roles
//    based in the names of the LDAP groups. For example:
//   - LDAP group: Admins => Drupal role: Admins
//   - LDAP group: ou=Underlings,dc=myorg,dc=mytld => Drupal role: Underlings
//   However, if this is not enough, this name mapping can be refined
//   by altering this array. Some examples are given.


$GLOBALS['ldap_group_role_mappings'] = array(
  // LDAP group => Drupal role
  
  // make sure the last group->role mapping does NOT have a trailing comma (,)
  'CN=Domain Users,OU=Security Groups,OU=three,DC=two,DC=one' => 'Domain Users',
  'CN=IT,OU=Security Groups,OU=Security Groups,DC=two,DC=one' => 'IT'
  
);

// Note: Uncommenting this function will limit the groups -> roles conversion to ONLY those groups that are 
// specified in the function. 

function ldapgroups_roles_filter($groups) { 
  global $ldap_group_role_mappings; 
  $roles = array(); 
  // this should take the roles array, pass it thru the filters and send a NEW set of roles back the filter 
  foreach ( $groups as $group ) { 
    foreach ($ldap_group_role_mappings as $approved_group => $approved_role) {
       // must strip spaces ?
       $group_stripped = preg_replace('/\s+/', '', $group);
       $approved_group_stripped = preg_replace('/\s+/', '', $approved_group);       
      if (strcasecmp($approved_group_stripped, $group_stripped) == 0) {
        // this role is specified -- grant
	   $roles[] = $approved_role;
      }
    }
  }
  return $roles;
}
?>

Thanks

kpm’s picture

whoops, just noticed I repeated a group on my sample file... this is how it was meant to read

'CN=Domain Users,OU=Security Groups,OU=three,DC=two,DC=one' => 'Domain Users',
'CN=IT,OU=Security Groups,OU=three,DC=two,DC=one' => 'IT'
kpm’s picture

It appears to be working now. I think what was happening is that I was making changes and expecting them to turn up immediately. If the role didn't show up, I would try something else... I think that it actually takes a bit of time for the roles to propagate through the system. They are showing up now.
Thanks for the help!

kpm’s picture

Ok... Sorry to be such a pain... BUT, it actually is NOT working. The two groups, it turns out, were added manually in the roles. So I am still having trouble getting AD Security Groups mapping to Drupal Roles. So, back to begging for help!
Thanks

kpm’s picture

I have also tried to connect using 'Groups are specified by LDAP attributes' set to 'memberOf'. But that didn't get any role mappings either.

kreaper’s picture

kpm

How are your Security Groups defined ? It would be helpful to know that. If your user object has an attribute called "memberOf" and its value is the DN of the group, then you should select the 2nd option " Groups are specified by LDAP attributes".

In some AD designs, you have groups as objects with the members listed using an attribute (e.g. "member"). In that case, select the third option.

After you made the correct choices, to ensure that you are indeed pulling the groups from AD, find the function called "ldapgroups_detect_groups() in ldapgroups.module. It will be like

$groups = _ldapgroups_detect_groups($user);

and put this debug line after that

msg_r($groups);

If you LDAP groups are being retrieved correctly, then you will see the groups printed on the webpage after login.
At least that will send you troubleshooting in the right direction.

kpm’s picture

Title: Can't get LDAP Groups to work... » Can't get LDAP Groups to work... UNTIL NOW!!! THANKS Kreaper!

Thanks a ton! I seem to have it working now. Though I still have a question... But first I'll explain my GIANT id10t error...

I was trying to do this while logged in as the first Drupal user, the top admin, who is not part of the AD! *Sigh*.

Once I gave myself admin rights and then logged in as a myself on our network, and I used your debugging line tip (thanks!), I could then see all the various groups I belonged to. So that told me it was working. However, the AD Security Groups are not showing up in the Drupal Admininster Roles section until I add the DN in the ldapgroups.conf.php file. Then it works like a charm.

This may very well be exactly as it is suppose to work, but my understanding was that the ldapgroups.conf.php file was more of a filter. If it was left untouched, then the AD Security Groups would map automatically to the Roles page. Did I read this wrong, or is there still something I can do that won't require me editing ldapgroups.conf.php (not that that is or would be a problem, just curious if I have everything functioning correctly).

Here is some more descriptive info about our AD set up and what I have done to link Drupal to it:

The following are the Base DNs I am using in the LDAP Integration login settings text box:

OU=Users,OU=sub2,DC=TLD,DC=internal
OU=Security Groups,OU=sub2,DC=TLD,DC=internal
OU=Service Accounts,OU=sub2,DC=TLD,DC=internal

Our AD structure is like so:

-TLD
-- OU=sub1
-- OU=sub2
--- OU=Security Groups
---- CN=IT
---- CN=Users
---- etc
--- OU=Users
--- OU=Service Accounts
-- OU=sub3
-- OU=sub4
-- etc

Currently, we want to give access to only those users in the OU "sub2", so the values I have been trying arise from the following distinguished names:

CN=IT,OU=Security Groups,OU=sub2,DC=TLD,DC=internal
CN=Users,OU=Security Groups,OU=sub2,DC=TLD,DC=internal
CN=Users Name,OU=Users,OU=sub2,DC=TLD,DC=internal

For the users group, the value holding the DN is 'memberOf'
For the security groups, the value is 'member'.

To map our Security Groups and lists I have checked the "Groups are specified by LDAP attributes" and enter the "Attribute Name" as "memberOf".
I also checking "Groups exist as LDAP entries where a multivalued attribute contains the members' CNs" and entering
OU=Security Groups,OU=sub2,DC=TLD,DC=internal and using "member" in the "Attribute holding group members".

Thanks again

scafmac’s picture

Kpm,

Not sure if this is clear or not, but it might help to know that groups are not actually mapped until a user with those groups logs in. So if you've been changing stuff in AD, then logging in as the drupal super user rather than an AD user, you wouldn't see any groups.

In all of my setups, I do not touch the ldapgroups.conf file. I set the groups in AD, assign a test user to them, then login to Drupal with the test user. That creates the corresponding drupal roles and then I assign permissions as needed.

Either way, I'm glad you got it going.

kreaper’s picture

If you do not desire any filtering done, then comment out the entire function (the stock file comes with the function commented out)

/*
$GLOBALS['ldap_group_role_mappings'] = array(
  // LDAP group => Drupal role
 
  // make sure the last group->role mapping does NOT have a trailing comma (,)
  'CN=Domain Users,OU=Security Groups,OU=three,DC=two,DC=one' => 'Domain Users',
  'CN=IT,OU=Security Groups,OU=Security Groups,DC=two,DC=one' => 'IT'
 
);
*/

kreaper’s picture

Sorry - I meant to say "comment out the filtering function" which is

function ldapgroups_roles_filter($groups) { 
kpm’s picture

Can someone check the ldapgroups.conf.php file in the module. I just downloaded the LDAP Integration module from the Drupal web site, extracted it, and checked the stock file and the filter functions are not commented out. When I commented out the whole thing, then everything fell into place. I have been opening the file with the text editor Notepad ++ on a Windows 2003 server, so unless it is somehow removing the comments, the file's functions are uncommented.
Thanks again for the help Kreaper and Scafmac.

kreaper’s picture

Assigned: Unassigned » kreaper
Status: Active » Closed (fixed)

I will make sure of it.

lambic’s picture

Hi, I'm having similar problems getting groups to work, but I've tracked it down to a different problem. It seems like no attributes are getting returned for the user. I added some debugging to try to see what was going on:

$r=ldap_read($_ldapgroups_ldap->connection, $user->ldap_dn, 'objectClass=*');
dsm($r);
$e=ldap_get_entries($_ldapgroups_ldap->connection, $r);
dsm($e);

And I get:

warning: ldap_read() [function.ldap-read]: Search: Operations error in ldap_integration/ldapgroups.inc on line 123.

Any idea what could be causing that?

lambic’s picture

Never mind, it was because we don't use a binddn/pass so I need to allow passwords to be kept for the session.