Hi Everyone,

Without using Role Filtering the LDAP Groups automatic creation of roles from ldap groups and association of the users to the appropriate roles works fine.
However when enabling the LDAP Group to Drupal role filtering nothing happens.

In my "Mapping of LDAP groups to Drupal roles" section I have the following entry:

cn=labitsupport,ou=groups,dc=example,dc=com|IT Support

1) When "Use LDAP group to Drupal roles filtering" is unchecked it automatically creates a "labitsupport" role and associates my user to it. It creates this role whether or not I have the mapping line above set.

2) When "Use LDAP group to Drupal roles filtering" is checked and the "IT Support" role does not exist, no role is created and no mapping happens.

3) When "Use LDAP group to Drupal roles filtering" is checked and the "IT Support" role exists, my user does not get associated to it.

Anyone know what I'm tripping up on?
Thank you,
- Vince

Comments

vincetingey’s picture

6 weeks and no one can help me?

SleeperGTP’s picture

Can you list your full ldap_auth and ldap_groups settings with names protected?

vincetingey’s picture

LDAP AUTH

  • Authentication mode: Mixed mode. The LDAP authentication is performed only if Drupal authentication fails.
  • User conflict resolve procedure: Associate local account with the LDAP entry
  • Do not store users' passwords during sessions
  • Sync LDAP password with the Drupal password
  • LDAP Server Configuration:
    • Name: ldap1.example.com
    • LDAP Server: ldap1.example.com
    • LDAP Port: 389
    • Use Start-TLS
    • Do Not Store passwords in encrypted form
    • Base DNs: ou=People,dc=example,dc=com
    • UserName attribute: uid
    • Email attribute: mail
    • DN for non-anonymous search: uid=search, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot

LDAP GROUPS

ldap1.example.com

  • Group is not specified in user's DN
  • Groups are not specified by LDAP attributes
  • Groups exist as LDAP entries where a multivalued attribute contains the members' CNs
  • LDAP DNs containing groups (one per line): ou=groups,dc=example,dc=com
  • Attribute holding group members: memberuid
  • No LDAP groups allow automatic account creation
  • Mapping of LDAP groups to Drupal roles: cn=labitsupport,ou=groups,dc=example,dc=com|IT Support
  • Use LDAP group to Drupal roles filtering

Boy I wish there was an easier way to extract drupal module configurations so I can avoid the tedious cut/pasting for help postings...

vincetingey’s picture

So I posted my config.... any help?

If I dont get this resolved this month then I will have to scale back our ldap integration and leave it to authentication and data only.

verta’s picture

You posted:
Attribute holding group members: memberuid

This is where our setup, which is synching roles, differs from yours.

Under Groups by Attribute, I have checked:
Groups are specified by LDAP attributes

and under Attribute names (one per line):
we use:

memberOf

Perhaps this will help. Good luck!

StooJ’s picture

I can confirm this works - I've been trying to do the same myself as well.
You need to set Groups Specified by LDAP attributes to True, and set the attribute to something appropriate ('memberOf' for AD).
You also need to set the mappings appropriately (cn=labitsupport,ou=groups,dc=example,dc=com|IT Support)

This has stumped me for ages, verta. Especially since it only works at first login and doesn't map at subsequent ones (which is a real pest).
Many thanks!

verta’s picture

Perhaps we should suggest making this a documentation request, if it works for the OP?

I'm pretty sure I did something similar when I first installed the module.

vincetingey’s picture

Sorry, but using "Groups Specified by LDAP attributes set to True" does not work for our configuration.

It looks like most people use this in conjunction with Active Directory which we are not using. In the 389 Directory Server that we are using, groups are their own entry and contain a list of users id's (uid) that belong to that group. This is ok as there is a setting in the LDAP groups for this called "Groups exist as LDAP entries where a multivalued attribute contains the members' CNs". Our users do not have any group attribute so "memberOf" would not work. This is simply a different way of doing groups instead of using an attribute on each user. Our group attribute for holding group members is the same as the one suggested in the help text even (memberuid).

Here is an example group:
cn=labitsupport,ou=groups,dc=example,dc=com
memberuid=uid1
memberuid=uid2
memberuid=uid3

vincetingey’s picture

Oh and thanks again for the help! This LDAP stuff is pretty obtuse.

cawley’s picture

We have the same setup here. Do you have the exact config info? Basically, we are trying to
add a user from LDAP and put them automatically into the Drupal role.

Thanks

verta’s picture

My thought is to check the case of the spelling of every string in the paths and names of LDAP objects, as we had to match them exactly to get role sync to work.

chyatt’s picture

Also watch out for spaces in strings like: "cn=labitsupport, ou=groups, dc=example, dc=com". We needed them.

vincetingey’s picture

I will be testing this out in the coming weeks. Look for an update by end of April.

Thx for the info.

johnbarclay’s picture

The filtering is working fine for me.

1) means that you have Group by DN, group by attribute, or group by entry at admin/settings/ldap/ldapgroups/edit/N correct. this is the most difficult part for most people.
2) just means ldapgroups isn't pulling IT Support out of thin air or caching. Good to check this sort of thing when things are going sour ;)
3) probably means the filter isn't quite right. Here's how to debug it:

change the code below in ldapgroups.inc to the code below and login. You will see each of the filtered groups being compared to every group the user is mapped to. Something like the following. Just look and see where the comparison is going wrong.

group=Campus Accounts|mappings:
compare CN=ED IT NaG Staff,OU=PeopleGroups,OU=Education,DC=ad,DC=uiuc,DC=edu and Campus Accounts (no match)
compare Campus Accounts and Campus Accounts (match)
--------------------------------------------------------------------------------
group=CN=aces_ap,OU=directoryGroups,OU=ACES,DC=ad,DC=uiuc,DC=edu|mappings:
compare CN=ED IT NaG Staff,OU=PeopleGroups,OU=Education,DC=ad,DC=uiuc,DC=edu and CN=aces_ap,OU=directoryGroups,OU=ACES,DC=ad,DC=uiuc,DC=edu (no match)
compare Campus Accounts and CN=aces_ap,OU=directoryGroups,OU=ACES,DC=ad,DC=uiuc,DC=edu (no match)
.
.
.
function _ldapgroups_filter($account, $groups) {
  if (_ldapgroups_ldap_info($account, 'ldapgroups_mappings_filter') && count(_ldapgroups_ldap_info($account, 'ldapgroups_mappings') > 0)) {
    $groups_new = array();
    foreach ($groups as $group) {
      print "<hr/>group=$group|mappings:";
      foreach (_ldapgroups_ldap_info($account, 'ldapgroups_mappings') as $group_approved => $role) {
        print "<br/>compare $group_approved and $group ";
        if (strcasecmp($group_approved, $group) == 0) {
           print "(match)";
          $groups_new[] = $role;
        } else {
          print "(no match)";
        }
      }
    }
    $groups = $groups_new;
    die;
  }

  if ($code = _ldapgroups_ldap_info($account, 'ldapgroups_filter_php'))
    $groups = drupal_eval($code);

  return $groups;
}
adamkun’s picture

Sorry to be a complete noob here, but when we add print statements such as this to ldapgroups.inc or other files, where can we see the output?

I modified my _ldapgroups_filter as above, and I don't see output anywhere.

Thanks in advance.

johnbarclay’s picture

the print statements should go to the screen. a better approach than print is this:

- install the devel module
- give admin rights to it
- use the dpm() function for debugging. e.g. dpm($x), dpm('fail'), etc. the firebug extension for devel is also handy because this output goes to a window in the browser.

mecvo1984’s picture

subscribe

kapayne’s picture

I'm having the same problem as the original poster and I've read through the thread but I can't figure it out. In our case, when a user registers on the site they are automatically granted the 'authenticated user' role on the drupal side. We want them to be added to the corresponding ldap group (registeredUsers). They get added as individuals to the list of users in ldap no problem, and we have the group module set up to group by entry with the with mapping:
gist_registeredUsers,ou=groups,ou=dev,dc=example,dc=com|authenticated user

I thought that the extended groups module would add the user to the registered user ldap group upon login but it doesn’t. The good news is that I can edit roles after the user is registered and these changes are reflected in the ldap group listing but it appears the initial creation does not automatically add an authenticated user to a group.
Andy ideas?
thanks in advance,

vincetingey’s picture

Sorry, we decided to not implement group to role filtering and thus I did not get a chance to test out those tips.

Wish you all luck in finding a solution that works for you.

kapayne’s picture

I understand thanks for getting back to me - we implemented two case statements (below) yo the extended_ldapgroups module that write/removes the user to the ldap group on login (they are initially assigned to corresponding drupal roles via the rules module) which worked fine until we wired up CAS to the configuration and it stopped working. We will continue to see a solution.

case 'login':
// At login send roles to extended_ladpgroups_add_group_membership since some roles are being added directly in the db
if (array_key_exists('roles', $account)) {
$roles_added = array_keys($account->roles);
if(!empty($roles_added)){
extended_ladpgroups_add_group_membership($account, $roles_added);
}
}
break;

case 'delete':
// If a user is deleted from drupal role then delete user from the associated ldap group
$roles_removed = array_keys($account->roles);
extended_ldapgroups_remove_group_membership($account, $roles_removed);
break;

cgmonroe’s picture

Status: Active » Closed (fixed)

Clearing out old support requests - reopen if problem still exists in newest code (dev)