With OpenlDAP the recommended way of managing a "memberOf" attribute is through a "layer" (extension) that implement the functionality and can do so in an bidirectional way between the memberOf attribute and the groups the memberOf attribute references.

But that means the "memberOf" attribute is not partof the default layout of an object. It has to be queries explicitely.

I agree that this is a poor implementation since it breaks the assumption that filtering an object without mentioning an attribute list brings all the attributes the object contains.

i.e. attributes managed by a layer are not attribute in the full sense of it.

The consequence is that when syncing groups, Drupal-LDAP does a "default" query on the member object that supposedly brings every attribute the object has and then extract from the resulting array the "memberOf" attribute given in the configuration.

This obviously fail in the case explained above on openLDAP, and maybe other implementations.

It is to be noted that it is considered a bad practice to do such "*" queries in most cases (the obvious exception being if you implement a tool that explores the LDAP server content) since some directories can associate dozens of attribute to an object and thus the query brings back a lot of data.

The sync is done in the method userUserNameToExistingLdapEntry in LdapServer.class.php

We have two solutions to this :

  1. Use an internal call to retrieve all the attribute we manage and add to that the attribute configured to play the "memberOf" role, that's what I did in my internal patch by calling ldap_servers_attributes_needed in all cases, without parameters, and then adding to the resulting array $this->groupUserMembershipsAttr; (a better method would be to check if it is not already present in case some server behave differently regarding the memberOf attribute)

  2. Make two calls, on without specifying attributes to retrieve all the "normal" ones like today, another with the "special ones" i.e. "memberOf ($this->groupUserMembershipsAttr; content)" and merge the resulting arrays.

Solution 1 seems the best and most efficient given that we indeed have a way to retrieve the attribute set we need in a predictable fashion (right now I feel lucky that the call to XXXXXXXXXXXXXXX retrieve the attributes the code need to to the sync but I really need the maintainer to confirm it is the right use case)

Solution 2 is the one that stay close to the current behavior and would keep the changes purely local to the XXXXXXX sync function

And then some tests would be needed to check it does not break commonly used LDAP servers, besides OpenLDAP that I know to work with my patch.

Can I have some input before delivering a patch (i.e. cleaning all my debug code and building the patch)

Thanks a lot for your time

Comments

johnbarclay’s picture

#1 is the desired behavior. #2 is undesirable for performance as well as unpredictability of dealing with binary or otherwise unspecified fields. ldap_servers_attributes_needed was specifically put in to resolve this problem.

Appreciate the patch and asking ahead of time for direction.

Annakan’s picture

Ok I'll get to clean up my code a bit and make a new patch.

And proper review is really welcome, php and drupal are not my usual cup of tea.

Annakan’s picture

StatusFileSize
new15.85 KB

Here is a patch for that issue and also (since It would not work without it) a quick fix for issue #1993092: LDAP *: Why is ldap configuration keyed on user choosen langage ?

This is a **work in progress** patch with lots of "dpm" commented that ought to be removed in the end.

I would appreciate if somebody could test this :

* that it applies cleanly
* that it does not break on non openldap server
* that it allows role membership update from the LDAP server on both openldap and other (AD ?) servers.
* style remarks are ok too , I am not a php guy, as long as they are constructive

If everything is ok I would then clean up the dpms and commented debug code and post a more clean patch.

I would then be able to think about the reverse way : changing a role membership in drupal and updating the ldap group member. It works in OpenLdap to change the "memberof" attribute to update the referenced group member list but I don't know if that truck works in other ldap servers ...

BizzaroMatt’s picture

I just applied this patch to solve the MemberOf issue. It does did immediately correct the issue for me. Unfortunately, I don't have any other directories to test against. I can confirm that is corrects the issue in OpenLDAP 2.4.23.
I did have a couple of patch hunks fail. Hunk 1 in "ldap_servers/LdapServer.class.php" and Hunk 4 in "ldap_user/LdapUserConf.class.php". But, I did apply it to a beta5 installation.

kenorb’s picture

Priority: Major » Normal
Status: Active » Needs review
StatusFileSize
new816 bytes

Cleaner patch with removed dsm()s.
Not including the fix for: #1993092: LDAP *: Why is ldap configuration keyed on user choosen langage ?
I'm not sure how I can test that patch.

kenorb’s picture

johnbarclay’s picture

I just added the default 'all' context to make this work. Passing a null context into ldap_servers_attributes_needed would likely not get good results. I'll push this as soon as I resolve my current git issue.

star-szr’s picture

A patch file got committed here (filename Issue1994850#8), and I'm curious why:

function userUserNameToExistingLdapEntry($drupal_user_name, $ldap_context = NULL) {

   if (!$ldap_context) {
     $ldap_context = 'all';
   }

instead of:

function userUserNameToExistingLdapEntry($drupal_user_name, $ldap_context = 'all') {
vgalindus’s picture

Status: Closed (fixed) » Needs work
StatusFileSize
new1.02 KB

Hi I've encountered the same problem after updating to beta-8 version, it seems that issue is not still addressed in dev branch.

Here is the patch I've used it mainly does the same as the one previously posted but it also checks for groupUserMembershipsAttrExists.

endiku’s picture

StatusFileSize
new601 bytes

Came to the exact same conclusion as #11, except in a different place.

Doesn't this seem more fitting in the ldap_servers_ldap_attributes_needed_alter() function where the rest of the required attributes are all located?

 /**
   * Implements hook_ldap_attributes_needed_alter().
   */
  function ldap_servers_ldap_attributes_needed_alter(&$attributes, $params) {

    $attributes['dn'] = ldap_servers_set_attribute_map(@$attributes['dn'], 'ldap_dn'); // force this data type

    if ($params['sid'] && $params['sid']) { // puid attributes are server specific
      if (is_scalar($params['sid'])) {
        $ldap_server = ldap_servers_get_servers($params['sid'], 'enabled', TRUE);
      }
      else {
        $ldap_server = $params['sid'];
      }
      // mail, unique_persistent_attr, user_attr, mail_template, and user_dn_expression are needed for all functionality
      if (!isset($attributes[$ldap_server->mail_attr])) {
        $attributes[$ldap_server->mail_attr] = ldap_servers_set_attribute_map();
      }
      if (!isset($attributes[$ldap_server->picture_attr])) {
        $attributes[$ldap_server->picture_attr] = ldap_servers_set_attribute_map();
      }
      if ($ldap_server->unique_persistent_attr && !isset($attributes[$ldap_server->unique_persistent_attr])) {
        $attributes[$ldap_server->unique_persistent_attr] = ldap_servers_set_attribute_map();
      }
      if ($ldap_server->user_dn_expression) {
        ldap_servers_token_extract_attributes($attributes, $ldap_server->user_dn_expression, TRUE);
      }
      if ($ldap_server->mail_template) {
        ldap_servers_token_extract_attributes($attributes, $ldap_server->mail_template);
      }
      if (!isset($attributes[$ldap_server->user_attr])) {
        $attributes[$ldap_server->user_attr] = ldap_servers_set_attribute_map();
      }
      if (isset($ldap_server->groupUserMembershipsAttrExists) && !isset($attributes[$ldap_server->groupUserMembershipsAttr])) {
        $attributes[$ldap_server->groupUserMembershipsAttr] = ldap_servers_set_attribute_map();
      }
    }
  }
kenorb’s picture

Status: Needs work » Needs review
generalredneck’s picture

Patch #12 fails with the following because it wasn't made correctly:
http://take.ms/z4QAS

Resubmitting patch using Patch Submission Standards.

vinmassaro’s picture

Status: Needs review » Needs work

Hate to revive this old issue but the patches applied in #9 also broke CAS Attributes. CAS Attributes no longer returns all LDAP tokens. Updating to the latest 7.x-2.x-dev release for some other LDAP fixes broke this for us.

vinmassaro’s picture

StatusFileSize
new2.69 KB

Here's a patch that applies to 7.x-2.x that reverts the two commits in #9 for anyone else running into the issue I described above.

  • larowlan committed 5ff8773 on 7.x-2.x
    Revert "Issue #1994850.  Fix for no context when mapping drupal username...
larowlan’s picture

This has been rolled back as it also caused #2779595: Authorization not properly reading group membership

grahl’s picture

Status: Needs work » Needs review

The last submitted patch, 3: memberof_and_langage_key_fix.patch, failed testing.

The last submitted patch, 3: memberof_and_langage_key_fix.patch, failed testing.

The last submitted patch, 3: memberof_and_langage_key_fix.patch, failed testing.

The last submitted patch, 11: 1994850-Fix-Group-Sync-fail-memberOf.patch, failed testing.

The last submitted patch, 11: 1994850-Fix-Group-Sync-fail-memberOf.patch, failed testing.

The last submitted patch, 11: 1994850-Fix-Group-Sync-fail-memberOf.patch, failed testing.

The last submitted patch, 12: group-sync.patch, failed testing.

The last submitted patch, 12: group-sync.patch, failed testing.

The last submitted patch, 12: group-sync.patch, failed testing.

The last submitted patch, 14: ldap-group_sync_fail_memberof-1917254-14.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 16: revert_1994850.patch, failed testing.

grahl’s picture

Assigned: Annakan » Unassigned
grahl’s picture

Status: Needs work » Closed (outdated)

Closing issue as outdated due to no further development on 7.x, if you feel this issue is still relevant and you are willing to work on a patch and/or debug the problem, please reopen.