Am setting up a new Drupal 7 server with Shibboleth authentication and LDAP SSO. The desired end result is to use LDAP Authorization and populate Drupal roles table with a short, filtered list of roles and the appropriate users_roles entries.

My issue/problem is similar to the venerable "Option II.C" discussion here: https://drupal.org/node/1066608. However, since the 7.2 configuration layout is significatly different, I am opening a new request.

The problem is that when I test LDAP Authorization, all users are returned, but no (LDAP-derived) roles appear. Backing up to the LDAP Server Test, I see that while my DSA user connects successfully and gets the user attributes I expect, in "User Group Memberships Function Tests", all results are zero, including the value for ldap_server->groupUserMembershipsFromEntry, which is the method (entry=memberUid) I have configured.

I can connect from the same host at the command line using the same dedicated DSA credentials and like so:

ldapsearch -x -ZZ -D cn=dsauser,ou=DSA,dc=dept,dc=bigorg,dc=com  -w 'DSApassword' -b
ou=Groups,dc=dept,dc=bigorg,dc=com -LLL "(memberUid=$ID)" cn

So, in LDAP Server config, the entries under "Connection Settings" and "Binding Method" seem fine as the test connects OK and returns user attributes.

Under "LDAP User to Drupal User Relationship" I have both of these as Base DNs

ou=People,dc=dept,dc=bigorg,dc=com
ou=Groups,dc=dept,dc=bigorg,dc=com

and entered "uid" as "Authname Attribute" since that matches group entries for memberUid.

The section LDAP GROUP CONFIGURATION seems the most questionable. I have entered "posixGroup" as group object class and "uid" under "User attribute held in 'LDAP Group Entry Attribute Holding...'"

I have made this configuration work with the 7.1 module version but now am puzzled as to why the group tests under the Server test all return "count=0".

Any inspirations, thoughts on next test steps?

Thanks!

Jim

Comments

geste’s picture

geste commented

Some crude troubleshooting. My base DNs in server config are like so:

ou=People,dc=dept,dc=bigorg,dc=com
ou=Groups,dc=dept,dc=bigorg,dc=com

If I introduce a typo into the "People" base DN, the Server test still connects to LDAP with the DSA, but returns no user info and issues a warning.

However, if I introduce a typo into the "Groups" base DN config, the server test returns user info, but no group info and there is no warning or error. That tells me that the test isn't even trying to use the Groups DN, and maybe just not searching for Group membership at all. The order of the 2 DN entries does not change anything.

For what it is worth, LDAP is 389-DS and works under 7.1 module version as "default LDAP". I can reproduce same failure/s regardless of LDAP type setting (at least OpenLDAP and Novell).

Does this ring any bells for anyone?

Jim

geste’s picture

geste commented

I installed the Devel module to see object and array info and have a little more info:

The LDAP SERVER->LDAP GROUP CONFIG section has a field for "Testing LDAP Group DN". I entered a legit group in the form of:

cn=pcadmin,ou=Groups,dc=depts,dc=bigorg,dc=com

When I run the Server Test and inspect the stuff reported by Devel, it shows an array named "Test Group LDAP Entry" with 16 elements, one of which is "memberuid" and this in turn contains the (alpha) LDAP UIDs of all 9 members of that group.

So the Server Test is obviously able to fetch LDAP info from ou=Groups, but then that isn't reflected in group info for the specific user. Questions/Thoughts:

Am I right to assume that "User Group Membership Functions Test" (for groupUserMembershipsFromEntry[jimh, nested=No]) should show count=8 if the test user "jimh" is in 8 groups and would list the group names under "results"?

Our user DNs don't use cn or dn and are in the form of uid=jimh,ou=People,dc=dept,dc=bigorg,dc=com. Any potential collision in the module between Drupal uid and LDAP uid?

I am not messing with the Authorization configuration until I see the groups I expect to see in the Server Test. Is that a sane approach?

Thanks in advance!

Jim

geste’s picture

geste commented
Category: Support request » Bug report

After stepping back through this, I am changing category to bug. Clearly the memberships should be returned but aren't and the fix will need to be in code. I am trying to assess if our user DNs based on UID (not cn or dn) are connected to this but not seeing anything yet.

Jim

geste’s picture

geste commented

This all appears to work in Beta 8, both server test and authorization test. Yay! Now I will try applying the auth role filters to limit importted rols.

kenorb’s picture

kenorb commented
Version: 7.x-2.0-beta6 » 7.x-2.x-dev

I've similar issue with LDAP groups.
I was testing my LDAP server at /admin/config/people/ldap/servers/test but 'User Group Membership Functions Test' section returned no groups.
Despite I've set Testing Group DN to 'ou=External,ou=Access,ou=Group,dc=example,dc=com', it was still using 'Base DN' specified in the configuration (under: LDAP User to Drupal User Relationship) which doesn't make sense.

So my current working configuration is:

Base DNs for LDAP users, groups, and other entries:
  ou=People,dc=example,dc=com
  ou=External,ou=Access,ou=Group,dc=example,dc=com
Name of Group Object Class: groupofnames
Nested groups are used in my LDAP: Off
A user LDAP attribute such as memberOf exists: Off
LDAP Group Entry Attribute Holding User's DN, CN, etc.: member
User attribute held in "LDAP Group Entry Attribute Holding...": dn
Groups are derived from user's LDAP entry DN.: Off
Testing LDAP Group DN: ou=External,ou=Access,ou=Group,dc=example,dc=com (which is ignored on test)
kenorb’s picture

kenorb commented
Category: Bug report » Support request
Status: Active » Fixed

Actually I've managed to make it working.
I've missed group dn in basedn and I don't have grp_user_memb_attr defined, so it's querying group dn, instead of user dn.
Here is the example working config (exported via Features, but yours could be a bit different.


/**
 * Implements hook_default_ldap_servers().
 */
function foo_ldap_default_ldap_servers() {
  $export = array();
$ldap_servers_conf = new stdClass();
$ldap_servers_conf->disabled = FALSE; /* Edit this to true to make a default ldap_servers_conf disabled initially */
$ldap_servers_conf->api_version = 1;
$ldap_servers_conf->sid = 'ldap_pv';
$ldap_servers_conf->name = 'LDAP: Local Provisioning';
$ldap_servers_conf->status = TRUE;
$ldap_servers_conf->ldap_type = 'openldap';
$ldap_servers_conf->address = 'example.com';
$ldap_servers_conf->port = 389;
$ldap_servers_conf->tls = TRUE;
$ldap_servers_conf->followrefs = FALSE;
$ldap_servers_conf->bind_method = 1;
$ldap_servers_conf->binddn = 'cn=drupal-test,ou=Services,dc=example,dc=com';
$ldap_servers_conf->bindpw = '';
$ldap_servers_conf->basedn = array(
  0 => 'ou=People,dc=example,dc=com',
  1 => 'ou=External,ou=Access,ou=Group,dc=example,dc=com',
);
$ldap_servers_conf->user_attr = 'uid';
$ldap_servers_conf->account_name_attr = '';
$ldap_servers_conf->password_attr = 'userPassword';
$ldap_servers_conf->password_attr_encoding = 'clear';
$ldap_servers_conf->mail_attr = 'mail';
$ldap_servers_conf->mail_template = '';
$ldap_servers_conf->picture_attr = '';
$ldap_servers_conf->unique_persistent_attr = '';
$ldap_servers_conf->unique_persistent_attr_binary = FALSE;
$ldap_servers_conf->user_dn_expression = '';
$ldap_servers_conf->ldap_to_drupal_user = '';
$ldap_servers_conf->testing_drupal_username = 'admin';
$ldap_servers_conf->testing_drupal_user_dn = '';
$ldap_servers_conf->grp_unused = FALSE;
$ldap_servers_conf->grp_object_cat = 'groupofnames';
$ldap_servers_conf->grp_nested = FALSE;
$ldap_servers_conf->grp_user_memb_attr_exists = FALSE;
$ldap_servers_conf->grp_user_memb_attr = '';
$ldap_servers_conf->grp_memb_attr = 'member';
$ldap_servers_conf->grp_memb_attr_match_user_attr = 'dn';
$ldap_servers_conf->grp_derive_from_dn = FALSE;
$ldap_servers_conf->grp_derive_from_dn_attr = '';
$ldap_servers_conf->grp_test_grp_dn = 'ou=External,ou=Access,ou=Group,dc=example,dc=com';
$ldap_servers_conf->grp_test_grp_dn_writeable = '';
$ldap_servers_conf->search_pagination = FALSE;
$ldap_servers_conf->search_page_size = 1000;
$ldap_servers_conf->weight = 0;
$export['ldap_pv'] = $ldap_servers_conf;
  return $export;
}

/**
 * Implements hook_default_ldap_authorization().
 */
function foo_ldap_default_ldap_authorization() {
  $export = array();

  $consumer_type = new stdClass();
  $consumer_type->disabled = FALSE; /* Edit this to true to make a default consumer_type disabled initially */
  $consumer_type->api_version = 1;
  $consumer_type->sid = 'ldap_pv';
  $consumer_type->consumer_type = 'drupal_role';
  $consumer_type->consumer_module = 'ldap_authorization_drupal_role';
  $consumer_type->status = TRUE;
  $consumer_type->only_ldap_authenticated = TRUE;
  $consumer_type->use_first_attr_as_groupid = FALSE;
  $consumer_type->mappings = 'a:1:{i:0;a:6:{s:12:"user_entered";s:18:"OV4 Pro Repository";s:4:"from";s:70:"cn=example-group-pro,ou=External,ou=Access,ou=Group,dc=example,dc=com";s:10:"normalized";s:18:"OV4 Pro Repository";s:10:"simplified";s:18:"OV4 Pro Repository";s:5:"valid";b:0;s:13:"error_message";s:106:"Role <em class="placeholder">OV4 Pro Repository</em>_name does not exist and role creation is not enabled.";}}';
  $consumer_type->use_filter = TRUE;
  $consumer_type->synch_to_ldap = FALSE;
  $consumer_type->synch_on_logon = TRUE;
  $consumer_type->revoke_ldap_provisioned = TRUE;
  $consumer_type->create_consumers = TRUE;
  $consumer_type->regrant_ldap_provisioned = TRUE;
  $export['drupal_role'] = $consumer_type;

  return $export;
}

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.