Forum Discussion

Michael_Jenkins's avatar
Michael_Jenkins
Icon for Cirrostratus rankCirrostratus
Dec 08, 2015

AD Query not getting all nested group

I'm experiencing an issue that I've seen creep up before, but haven't been able to figure out. In my VPE, I'm doing

AD Auth
and then and standard
AD Query
with the FetchNested Groups option checked. The problem is that for most of my groups everything works perfectly fine. In this one particular case, however, the APM query is not getting back the nested group membership (i.e. The user is a member of the group A, which is a member of group B that gives them permissions to resources). If I put the user directly into group B then it sees the group membership fine. But if they're in group A, it never grabs it (even though it grabs every other group membership).

I have created a new group that is exactly the same as the one having the issue (as best as you can in AD), and it has no problem. But this original group is already used elsewhere so I can't just switch groups completely.

Anybody have any ideas?

3 Replies

  • What kind of security group is it; universal, global, or domain local? Is there a difference between the one that is working and one that isn't? Just throwing it out there if the scope of the group is possibly messing with the AD query nesting.

     

  • What version of BigIP are you running? There was a bug a while back where the memberOf attribute was cut short so if the group happened to be the last one returned then the session variable would not have it set when going to the resource assign logic of the VPE.

    If that is not it then you can check to make sure using ldapsearch that the group is returned by AD (this could be an AD issue not an F5 issue).

    ldapsearch -xLLL -H 'ldaps://x.x.x.x' -b "dc=fr,dc=del,dc=corp" -s sub -D "cn=Administrator,cn=Users,dc=fr,dc=del,dc=corp" -w mypassword' "(member:1.2.840.113556.1.4.1941:=cn=cal,CN=Users,DC=fr,DC=del,DC=corp)"
    

    Modify the command above and I grep for "dn" to make the list easier to read.

    [root@cooper-apm-11-6-0:Active:Standalone] rest  ldapsearch -xLLL -H 'ldaps://x.x.x.x' -b "dc=fr,dc=del,dc=corp" -s sub -D "cn=Administrator,cn=Users,dc=fr,dc=del,dc=corp" -w mypassword' "(member:1.2.840.113556.1.4.1941:=cn=cal,CN=Users,DC=fr,DC=del,DC=corp)" | grep dn
    dn: CN=HwSales,CN=Users,DC=fr,DC=del,DC=corp
    dn: CN=Onsite,CN=Users,DC=fr,DC=del,DC=corp
    dn: CN=Sales,CN=Users,DC=fr,DC=del,DC=corp
    dn: CN=VEND1-QA,OU=VPN,DC=fr,DC=del,DC=corp
    dn: CN=VEND1-PROD,OU=VPN,DC=fr,DC=del,DC=corp
    dn: CN=VEND2-DEV,OU=VPN,DC=fr,DC=del,DC=corp
    dn: CN=Vendor A Prod,OU=VPN,DC=fr,DC=del,DC=corp
    [root@cooper-apm-11-6-0:Active:Standalone] rest 
    

    In this example "Sales" has member "HwSales" and "HwSales" has member of "cal".

    The filter uses the "LDAP_MATCHING_RULE_IN_CHAIN" OID which AD will do the group traversing and return the groups. If this works and you see all groups then we can dig in further into how the APM works. If this doesn't work I would suggest keep looking on the AD side.

    -Seth

  • So I was playing with this a bit last night myself as I saw some similar behavior. What seemed to rectify the issue was I added the memberOf attribute and two other attributes that I need to the "Required attributtes" section of the AD Query and then all my nested memberships showed up as expected. Are you using the required attributes section? I wonder if it doesn't get all the results when the return payload of the AD Query is above a certain size. When using the required attributes section you only get those attributes you want in the response significantly shrinking the AD Query response.