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 :
-
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 callingldap_servers_attributes_neededin 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 thememberOfattribute) -
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
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | revert_1994850.patch | 2.69 KB | vinmassaro |
| #14 | ldap-group_sync_fail_memberof-1917254-14.patch | 640 bytes | generalredneck |
| #12 | group-sync.patch | 601 bytes | endiku |
| #11 | 1994850-Fix-Group-Sync-fail-memberOf.patch | 1.02 KB | vgalindus |
| #6 | group-sync-fail-in-openldap-and-memberof-1994850.patch | 816 bytes | kenorb |
Comments
Comment #1
johnbarclay commented#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.
Comment #2
Annakan commentedOk 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.
Comment #3
Annakan commentedHere 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 ...
Comment #4
BizzaroMatt commentedI 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.
Comment #5
kenorb commentedComment #6
kenorb commentedCleaner 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.
Comment #7
kenorb commentedComment #8
johnbarclay commentedI 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.
Comment #9
johnbarclay commentedThis is committed. See:
http://drupalcode.org/project/ldap.git/commitdiff/1e56d1fafb86d5202a5c96...
http://drupalcode.org/project/ldap.git/commitdiff/f09b2acaeadcf891fe0559...
Comment #10
star-szrA patch file got committed here (filename Issue1994850#8), and I'm curious why:
instead of:
Comment #11
vgalindus commentedHi 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.
Comment #12
endiku commentedCame 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?
Comment #13
kenorb commentedComment #14
generalredneckPatch #12 fails with the following because it wasn't made correctly:
http://take.ms/z4QAS
Resubmitting patch using Patch Submission Standards.
Comment #15
vinmassaro commentedHate 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.
Comment #16
vinmassaro commentedHere'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.
Comment #18
larowlanThis has been rolled back as it also caused #2779595: Authorization not properly reading group membership
Comment #19
grahlComment #31
grahlComment #32
grahlClosing 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.