Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

AD Authentication, Nested / Staggered Groups not working

Can Sophos confirm please that SFOS 19.0.1 is still not able to detect staggered group membership of a Active Directory? Because that is what I noticed yesterday.

I tried to use a top level group that contains sub-groups for Firewall rules. If the user is member of a sub-group, SFOS does not see it's group membership.

Group A
   +----SubGroup B
   +----SubGroup C
   +----SubGroup D

Subgroup B Members:
User 1
User 2

Subgroup C Members:
User 3
User 4

Subgroup D Members:
User 5
User 6

.

I imported AD Group A into SFOS.

Users 1-6 restarted their Windows computers with Intercept-X and tried to use the Firewall rule but the traffic was blocked.

I checked the users in SFOS and their group membership from firewall perspective.

Both:
Group    and
Other group memberships

do not list Group A.

If I import Subgroup B into SFOS, User 1 and User 2 show Subgroup B in Other group memberships and the users can use the firewall rule.

So unfortunately, it is very likely SFOS is still unable to read staggerd group memberships after all those years.

See posts by  and   here:

 Firewall rules by AD group membership does not work. 

 User Authentication - AD Group in Group 

And the Help:

Group membership behavior with Active Directory

But that does not list limitations about staggering / nesting.



This thread was automatically locked due to age.
[entsperrt von: LuCar Toni um 1:22 PM (GMT -8) am 19 Nov 2024]
Parents
  • SFOS only supports the final group, not the nested groups. Nested group support would mean, the firewall would have to replicate your entire AD, which is not an easy task. Plenty of vendors are not doing this for several reasons, most likely performance and the impossible amount of combinations you can have. 

    Therefore most vendors, like Sophos, only query the "total group". SFOS is doing this by query the user and getting the groups of this user from AD. To get the nested groups, SFOS would have to query all groups as well to get the hierarchy, and store it in a own value. Then to query the groups against the information by the user etc. This is not an easy task to begin with, which comes with certain complications. 

    Another approach could be to rebuild the entire query architecture and query each group with each request. This can work but is a lot of effort and performance decrease to do this. 

    In the end, nested group support is something, which could be eventually better be resolved by an overlook of the architecture of the AD. 

    __________________________________________________________________________________________________________________

  • Thanks for taking your time for a detailed answer. So I made a request to the Documentation team to add something about group nesting being unsupported to the documentation.

    We'll import the Subgroups into XG then.

Reply Children
  • I want to take the time to spend more technical explanation about this old thread. As this post comes up on search engines after looking up SFOS nested groups, let me spend some time explaining, why Nested Groups are not working in SFOS.

    SFOS authentication works based on the query of the user. SFOS never queries the group and its members, instead SFOS turns it around and queries the "memberof" value of a particular user, after sign-in. 

    Memberof attribute will not include nested groups. 
    What that means, SFOS would have to be redesigned to support nested groups and start to query the LDAP Groups instead. 

    Looking into this approach of Query LDAP Groups, UTM and SFOS were not being designed / invested into supporting nested groups. There are certain limitations and caveats by performing queries like this (group queries). 

    So the discussion of changing the entire authentication service from memberof to group query or even change from memberof to tokengroups is a high cost change for supporting nested groups. 

    __________________________________________________________________________________________________________________