How to apply policies to all sub-groups?

Upon creation a group inherits the policies from it's parent. Afterwards This assignment is only changed when you use View/Edit Group Policy Details ... on the specific group (you might call it idiosyncrasy but ...). 

A complicated (you did not use complex) AD group structure has probably not all attributes in the container tree. GPOs (themselves in some structure) might be linked to several containers and thus "overlay" yet another structure. SEC has a simple hierarchical model and you can either have "live" inheritance (whenever a parent's attributes are changed the are applied to the children) or no (or initial) inheritance. SEC has the latter. Since there are no general rules how to arrange the clients in groups children might not use the same policies as the parent. It's "least surprise" - imagine what happens if you inadvertently make changes to a "too super" group.  

You could of course wish for an Apply to all subgroups option - but if you get it you (and everyone else) should use this with caution.

As for SQL - you probably know I'm not faint of heart when it comes to hacking using undocumented interfaces. Have a look at the tables involved and you'll see that it's not easily written in a single statement.

Oh - which type of policies?

Christian

Indeed!

Why CAN'T there be a "replicate down" option?  Or even a "replicate to all policies" within that group?

If I have let's say 10 or 20 policies in Anti-Vrius Policies and make a change in polices that would true for the other policies, I'd have to change / update all policies accordingly. 

Real world example:

If there is a directory I need to exclude in one Anti-Virus Policy, I'd have to add that same exclusion to the rest of my 12 policies manually.

If I have 60+ sub-OUs under an OU root in AD, if I change a policy at the root, I'd have to go through each and every one of those sub-OUs manually to reflect that.

Because of the limitations of Sophos Enterprise Console ver. 3 ( and after testing 4, I would include that to the list as well), most of my report creation/AV version management/unmanaged cleanup/virus alerting/errors alerting/update error cleanup administrative actions are handled in OSQL (a manual, time comsuming, non-enterprise solution) on a daily basis. 

So if OSQL querying is exhausting, complex work why are the customers, like myself, utilizing it and why isn't there a front-end GUI for to implement those OSQL statements instead of us customers having to use or build "undocumented" solutions for existing issues?

I've already discussed policies and propagation/inheritance (with someone at Sophos) some time ago. If a "push down" option were available you might need also an "exclude this group" attribute. 

IMHO the problem is only really a problem if you need to exchange policies.

But what you're talking about is not exchanging the policy for a group but applying the same changes to a number of policies. I can see why you could have that many AV policies - exceptions/exclusions. Now these are bad anyway. Really. But I don't say you shouldn't use them - perhaps you really need them. In this case though you'd need a policy hierarchy and not propagation. Or am I wrong?

And please elaborate on the limitations.

Christian

---

QC wrote:

I've already discussed policies and propagation/inheritance (with someone at Sophos) some time ago. If a "push down" option were available you might need also an "exclude this group" attribute. 

IMHO the problem is only really a problem if you need to exchange policies.

But what you're talking about is not exchanging the policy for a group but applying the same changes to a number of policies. I can see why you could have that many AV policies - exceptions/exclusions. Now these are bad anyway. Really. But I don't say you shouldn't use them - perhaps you really need them. In this case though you'd need a policy hierarchy and not propagation. Or am I wrong?

And please elaborate on the limitations.

Christian

---

QC,

Correct, I'm not exchanging, but replicating a change down that I deem a "global change" that needs to be reflective to all other policies within that policy category.

For example, my company may use an application to implement patch management.  If that application's executable can't run becuase Sophos stops it noting that it's a "Suspicious Behavior" thus patching efforts are halted.  I'd have to go in and exclude: the xyz.exe name, directory it's executing from, or a list of *.exe's depending on the situation.  So, let's say I have to exclude abc.dll, xyz.dll, xyz.exe, and %Program Files%\xyzPatcherProgram\* .  Since they have to patch all machines, I'd have to implement that addition of those 4 instantces across 20 Anti-Virus Policies.  That is a lot of manual work for one application to run.

Your point of "exlude this group" attribute would be a natural and nessessary step, but I'd rather have that opt-out option than to have no option to change a policy down from root to sub-OUs.

I am evaluating Sophos this week and noticed this problem as well.  I expected that when I applied a new policy to the "top" of a group "tree" that the policy would be inherited by all sub-groups as well.  Having to manually change the policy for every sub-group is crazy!

Hello Scissor,

I expected that when I applied a new policy to the "top" of a group "tree" that the policy would be inherited by all sub-groups as well

Understandable. But equally understandable is to expect that a sub-group for which you have created/set a special policy retains this policy. An old argument and while in theory you can have it all (well, almost all) the price is complexity with which you'd have to cope.

If you could export/import a policy (right now this is possible only for firewall) it would cover the cases where you want to change all instances of a policy. Export the policy, make desired changes and save it. If you need to revert to changes import the previously saved settings. Leaves the problem of assigning another policy to a "sub-tree". In most cases a ramified group structure is not really necessary - sub-estates/role-base access and synchronizing with AD being the exceptions.

Keep in mind that while the current behaviour may be a nuisance (ex-)changing policies not something you do on a regular basis. And as long as you don't have dozens or hundreds of groups (and the the question is - what for?) it's not a Herculean task.

Christian

I've logged a feature request based on this thread. Keep the ideas coming!

Cheers,

Lil

---

QC wrote:

Understandable. But equally understandable is to expect that a sub-group for which you have created/set a special policy retains this policy. An old argument and while in theory you can have it all (well, almost all) the price is complexity with which you'd have to cope.

Keep in mind that while the current behaviour may be a nuisance (ex-)changing policies not something you do on a regular basis. And as long as you don't have dozens or hundreds of groups (and the the question is - what for?) it's not a Herculean task.

---

Please don't make assumptions about other people's Active Directory structure.  Different companies set up their Active Directory structure in different ways.  My company decided to set it up similar to this:

Systems

Systems
   ^--> Desktops
          ^--> Office 1
          ^--> Office 2
          ^--> Office ...
          ^--> Office N
   ^--> Laptops
          ^--> Office 1
          ^--> Office 2
          ^--> Office ...
          ^--> Officen
   ^--> Servers
          ^--> Office 1
          ^--> Office 2
          ^--> Office ...
          ^--> Office N

If I want to create a new "Desktops" policy, the current product requires me to change the Policy on every single "Office" group under the Desktop section.  This becomes non-trivial after X numbers of offices.  

My assumption would be that a policy defined at an upper level filters all the way down unless it is specifically overridden at a lower level.  This would still allow you to manually specificy a policy for a particular group.

Please don't make assumptions about other people's Active Directory structure

I didn't - I explicitly stated that additional features are desirable in dealing with existing AD structures.

... filters all the way down unless it is specifically overridden at a lower level

That's the point: you also need a way to "protect" a group from receiving the parent's policy (worse, you might want that for example the updating policy should be inherited while the antivirus should not). And then at one point you decide that all subgroups should receive the new policy and that the do-not-inherit should be ignored. Furthermore if you "override" the policy for a certain group - should this policy then propagate to it's subgroups or not? Do tell me that NTFS security is so much easier to manage than SEC's group policies and I'll shut up. And we've not yet talked about moving a group from one point in the tree to another.

Again stressing least surprise - you might have forgotten that you've made an exemption somewhere "down below" and when you assign a new policy to an upper group ...

I don't say that such a feature should not be added - I just want to point out that it's not as simple as it may seem at the first glance and therefore will take time to get implemented.

Christian

I just read this thread and died a little inside.

I've got the same scenario - AD is synced in with lots of little OUs with rooms of PCs in each. Each OU has four policy items to enable, and I've got about 50 OUs to change...

Anyway, maybe a nice workaround (probably easier to implement) would be the ability to multiple-select the OUs, and change a whole load at once. That would make my life a lot simpler - additionally, the ability to set the default for a new OU (possibly based on location). So if a new one pops up from AD, it'll be pre-set with all the right settings.

Now off to click lots of times. :smileysad: