AD OU Groups Do Not Work

Within the Firewall Rule, a User is only considered to be a member of a single group, visible and editable in the WebAdmin.

However the Web component uses its own independent lookup of AD user/group information.

Within the Web Policy Rule, a User is a member of multiple AD groups.

Off the top of my head, I do not recall the support of OU and nested groups within Web.

Thanks Michael, multiple AD groups for Web Filtering work as you described, though I can't find it documented in any support material (https://community.sophos.com/kb/en-us/123161) and it doesn't seem to reflect this behaviour in the UI (other than following the Group Order in the Authentication section).  Is there any way you can view/confirm what groups a user is a member of within the XG, as it doesn't seem to even appear in the live logs?

Oddly enough importing OU's is referenced in the following KB article: https://community.sophos.com/kb/en-us/123158

If multiple groups are supported for filtering, it's even more of a shame the OU groups do not work, as then you could build a proper hierarchical web filtering rule structure without having to add users to multiple AD security groups (in lieu of nesting).

I've seen multiple requests for nested AD groups on the suggestion board with no reply, so I assume this is not going to be implemented any time soon?

Cheers

Hello James

OU based groups can only feasibly work if the user is a member of the OU at that level. For example "CN=Bob, OU=Test, DC=domain, DC=com" and you import "OU=Test, DC=domain, DC=com" then you should be able to match based on that OU. But you cannot match "CN=Bob, OU=Users, OU=Test, DC=domain, DC=com" the one you've imported because it does not regressively check OU membership.

Frankly, I haven't used OU group importation since v16.0.0 and I consider it a dead feature.

On the matter of groups in the UI, the XG will only reference the "Primary Group" membership that the user matches based on the priority ordering of the groups they are member of from AD that are imported on the XG. That group membership in the UI is primarily used for the Firewall Authentication. For the Web Filtering it is a dynamic backend AD membership callout and is not referenced in the GUI with the exception of the Policy Tester where it will tell you which group was matched to provide the result.

The reason for this is the relational database could become extremely large, become stale quickly and eventually be confusing when it is already something you can grab from AD by doing a user lookup memberof command.

I do agree with your reasons as to why it could be a good idea and I do not know why the reason the OU membership feature is "broken" but I base all builds off Security Groups as it seems far easier to manage. That and about 80% of installs I do the OU hierarchy is a bombsite!

Hope that answers some questions (but may make more!)

Emile

Thanks Emile, yes this has all come about as we have rehauled our AD and finally have a coherent and well structured environment.  That's why I was disappointed that we couldn't take advantage of our new logical topology or security group structure.

Out of curiosity on the web filter side of things, if a users AD security group membership changes, does the user account need to be removed before these changes are picked up, or is this updated on authentication?  I've noticed on the firewall side that the users reported group does not change, and we have to remove users manually.

Thanks for your assistance.

Hi James,

The AD Backend group relationship operates differently for Web and Firewall and they are below (it's a no and here's why):

• The Web Filtering AD Group membership system is a backend LDAP memberof call that is made on a regular basis while the user is authenticated. I cannot remember the exact refresh time but it is around 5 minutes and this is completely dynamic and is not relational to what you see in the Authentication > Users/Groups section of the GUI. It is a Many-to-Many relationship (just like AD) and is stored in the PGSQL database (usergroup_rel IIRC)
• The Firewall AD Group membership system is a local user -> group relationship that is supported by an AD backend lookup. What happens is each time the user is authenticated, the XG reaches out to the AD with an LDAP memberof and runs the returned groups through the Group ordering section of Authentication > Groups. Whichever group matches as a priority is a winner and the User is assigned to that Group in a Many-to-One relationship. That's why a user only matches one group at a time in the GUI because it is for the Firewall authentication relationship.

So any changes in AD with group memberships will be reflected as per the above descriptors so you do not need to remove users and re-add them with changes made in AD. The only thing you may have to do is force a logout/logon to refresh the auth (and therefore update membership) or just tell the user to log on to the user portal which also activates the membership update.

M8eys method of doing groups is almost exactly how I have been doing my Firewall Rule memberships since v16.0.0 when the auth system changed and has served me very well ever since. For Web Filtering, go wild with all the groups you want based off hierarchy, who is who's boss etc. But for the Firewall, think more along the lines of permissions that user needs to 'access' the internet based on Application Control and Service based restrictions.

I actually set mine up in, order, generally as:

• Administrators - Allowed any Service, separate Application filter cloned from a Default Business App filter I cloned earlier, Default Business Web Policy for all
• Elevated - Allowed extra restricted Services (like HTTP(S), FTP, Ping), Default Business App filter, Default Business Web Policy for all
• Everybody else - Restricted Services (just HTTP(S), Ping), Default Business App filter, Default Business Web Policy for all

I try to keep Firewall membership access rights groups to a bare minimum, like 3-6 as a good rule of thumb. I then have one big Web Filter Policy for everyone for easy diagnostics and visibility and use group memberships (including FW ones) to apply restrictions and de-restrictions where necessary. The only time I make a new Web Filter Policy is if they havea dramatically different need of filtering that would create an extra level of complexity which isn't worth doing. So new Firewall group, stick them in that, re-order everything, attach the custom web filter.

Hope that helps!

Emile

That's brilliant, thanks again Emile!

That's brilliant, thanks again Emile!