Ldap Authorization: Derive from Group-dn does not work

I think this thread might be the same issue:

http://drupal.org/node/1842630

Whatever this is I'm getting exactly the same thing. So either it's a bug, or we're both being dim in the same way. I've been tracking the slapd.log over a test attempt of two and it is performing the search and showing nentries=5 as i would expect (I'm in 5 groups) but then doesn't go on to actually return anything to the test page. Actual mappings from DN to Drupal role are similarly not occurring.

I'll post the slapd.log if anyone wants to see it.

Edit now I'm back at work and have had coffee:

I'm pretty certain this is a bug now, I'm going to alter the status if that's ok with you OP. Set it back if I'm wrong.

from "User Group Membership Functions Test" :

http://i.imgur.com/MzpgB.jpg

(sorry, can't work out how I upload images to this site to make that legit)

from slapd.log:

Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=0 STARTTLS
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=0 RESULT oid= err=0 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 fd=34 TLS established tls_ssf=128 ssf=128
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=1 BIND dn="" method=128
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=1 RESULT tag=97 err=0 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=2 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=3 BIND dn="uid=tipler,ou=people,ou=current,dc=maths,dc=ox,dc=ac,dc=uk" method=128
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=3 BIND dn="uid=tipler,ou=people,ou=current,dc=maths,dc=ox,dc=ac,dc=uk" mech=SIMPLE ssf=0
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=3 RESULT tag=97 err=0 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=4 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=5 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=tipler))"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=5 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=6 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=6 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=7 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=tipler))"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=7 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=8 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=8 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=9 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=tipler))"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=9 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=10 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=10 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=11 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=tipler))"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=11 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=12 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=12 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=13 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=tipler))"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=13 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=14 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=14 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=15 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=tipler))"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=15 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=16 SRCH base="ou=current,dc=maths,dc=ox,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=tipler)"
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=16 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 op=17 UNBIND
Jan  4 12:50:43 ldap0 slapd[12231]: conn=5521 fd=34 closed

So there's 6 connections, one for each test, and unless I've massively misunderstood what the word "Count" means in "User Group Membership Functions Test" it shouldn't be returning 0 when the slapd.log shows nentries 5 each time...

The LDAP server is openLDAP if that's helpful to know.

I would definately try 7.x-2.x-dev. Alot of the ldap authorization was rewritten for it. Its better to post bugs against -dev unless you are following all the patches and issues and know none of them are related to a given issue.

Apologies, I didn't check the version when I posted. This still occurs using the latest dev release. Updating the version in the ticket accordingly.

I don't suppose anyone has gotten anywhere with this? I'm still looking into it on and off but I've not made any progress recently.

Well, I've found the _cause_ of the problem...

The situation arises thus:

LDAP Group Entry Attribute Holding User's DN, CN, etc. = memberuid
User attribute held in "LDAP Group Entry Attribute Holding..." = uid

...and the DN of a typical group looks like this cn=sysman,ou=group,ou=current,dc=maths,dc=ox,dc=ac,dc=uk

now, get to Line 1640 of LdapServer.class.php inside the function groupMembershipsFromEntryResursive

      else {// maybe cn, uid, etc is held
        $member_id = ldap_servers_get_first_rdn_value_from_dn($group_entry['dn'], $this->groupMembershipsAttrMatchingUserAttr);
      }

in my case, uid is held. If you look at the group however, there's no uid attribute in it's dn, the group value we're looking for is a cn, so that always returns false.

I've got a simple patch that overrides this for me by forcing $member_id = $group_entry['dn']; in all cases, but I can't work out why it's doing this check here anyway so it's not one I'm happy to submit.

Hi James,
i have the same issue, do you have more informations about it ?

Julien

The goal of this loop is to generate a query of the form:

(&(objectClass=[$this->groupObjectClass])(|([$this->groupMembershipsAttr]=groupid1)([$this->groupMembershipsAttr]=groupid2))

such as:

(&(objectClass=group)(|(cn=groupid1)(cn=groupid2)) so it can find the groups the "$current_group_entries" are in. At this point in the code its not looking at users, just groups.

In your case you might be looking for something like:

(&(objectClass=group)(|(member=[DN1])(member=[DN2]))
so hard coding Dn makes it work maybe. The code should be like:

  if ($this->groupMembershipsAttrMatchingUserAttr == 'dn') {
          $member_value = $member_group_dn;
        }
        else {
          $member_value = ldap_servers_get_first_rdn_value_from_dn($member_group_dn, $this->groupMembershipsAttrMatchingUserAttr);
          if (!$member_value) {
            // read group and set $member_value to value of $this->groupMembershipsAttrMatchingUserAttr attribute
          }
        }

You can see where this would get quite query intensive. I would suggest not using the nested groups or reworking the code so "$member_group_dns" variable held the appropriate attribute.

This should be merged with #1965160: LDAP Servers: Group-Membership not derived correctly for non nested groups. They are very close.