Forum Discussion

Mark_22062's avatar
Mark_22062
Icon for Nimbostratus rankNimbostratus
May 20, 2013

APM - AD Nested Groups Limited?

Hi there,

 

I am trying to configure remote access to an application using AD Query. The query is configured to check membership of a group "F5_Application", this group has a number of nested groups which giver users rights within the application "Application_User" and/or "Application_Admin".

 

The query is configured to enumerate nested groups, however if a user belongs to one of the nested groups access does not work, if I add the user into the "F5_Application" group as well then it succeeds.

 

I've checked the logs and it appears that not all groups are being enumerated, is there a limit in the number of groups that can be enumerated? Is there a method to enumerate all the groups?

 

Many thanks

 

Mark

 

7 Replies

  • Two things could be happening.

     

     

    1. The memberOf attribute is not returned if the user is a member of only one group. If you look at the AD query in a Wireshark, you'll see that the AD returns "attributes: 0 items" if you filter strictly on the memberOf value. However, without the filter, the query will return primaryGroupID, which is the SID of that one (primary) group (ex. 513 = Domain Users). I would recommend applying at least two groups to all users (even if one of them is an empty group).

     

     

    2. I don't believe there's any specific limitation to the number and depth of nested groups. If you're adding and removing group memberships for testing and not seeing the differences, it's probably because APM has cached the information. If this is a test unit, you can issue the following to reset the APD cache: bigstart restart apd.

     

  • long time ago you wrote this question and it wasn't really answered. Today I have a real similar issue and I guess it's the same problem than yours.

     

    I have no nested groups but only a long list of groups a user is memberOf (sometimes more than 20), but only about first twelve groups in list works, all others fail. So propably there is a limitation (by character or by group) for the memberOf variable.

     

    I'm using AD Query in VPE for checking group membership.

     

    Thanks, Philipp

     

  • good tip, but I already use 11.5.1 and my log output for following irule gives me all group memberships.

    
    when ACCESS_POLICY_AGENT_EVENT {
      set user [ACCESS::session data get session.logon.last.username]
      if {[ACCESS::policy agent_id] eq "logmemberof"} {
          set memberOfList [split [ACCESS::session data get session.ad.last.attr.memberOf] "|"]
          foreach x $memberOfList {
             log local0. "User $user in group: $x"
          }
      }
    }

  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus

    How about sessiondump -allkeys and look for session.ad.last.attr.memberOf ? Is it truncated?

     

  • Hi,

     

    Sorry I haven't really looked into this any further since the original post. However looking at it now, it appears that the enumeration is now working correctly on my system. I'm running 11.4.0 HF5.

     

    Mark

     

  • with sessiondump I can see, that session.ad.last.attr.memberOf isn't truncated ...

    I now got the result with an irule, datagroup and an irule event in VPE (with branch rule matching session.custom.allowed).

    when ACCESS_POLICY_AGENT_EVENT {
       if {[ACCESS::policy agent_id] eq "member"} {
         set user [ACCESS::session data get session.logon.last.username]
         set memberOfList [split [ACCESS::session data get session.ad.last.attr.memberOf] "|"]
         ACCESS::session data set session.custom.allowed "0"
         foreach x $memberOfList {
           if { [class match -value -- $x contains datagroup_membersOf] equals "1" } {
             ACCESS::session data set session.custom.allowed "1"
             log local5. "Allowed User $user - Group:$x"
           }
         }
      }
    }