Activate/deactivate policies

For a policy to be effective for a computer/user, it has to be activated at group level (policies can only be activated at group levels). It makes no difference if this group is in the same container object or not. All that matters is that the user or computer has been directly or indirectly (through inheritance) assigned to the policy.

If a computer or user is outside an OU or inheritance line and is a member of a group which is inside this OU, this activation does not apply to this user/computer. Because there is no valid assignment for this user or computer (directly or indirectly). The group was, indeed, activated but an activation can only apply to users and machines for which there is also a policy assignment. This means that the activation of policies cannot go beyond container boundaries if there is no direct or indirect policy assignment for that object.

A policy becomes effective when it has been activated for user groups or computer groups. The user groups and then the computer groups are analyzed (authenticated users and authenticated computers are also groups). Both results are OR-linked. If this OR-link gives a positive value for the computer/user relationship, the policy applies.

Note: If more than one policy is active for an object, the individual policies are, while complying with the rules described, merged. This means that the actual settings for an object can be composed of multiple different policies.

A group can have the following activation settings:

If a policy is assigned to a container, the activation setting for a group (activated) determines whether that policy for that container feeds into the calculation of the resulting policy.

Inherited policies cannot be controlled by these activations. Block policy inheritance would have to be set at the more local OU so the more global policy cannot be effective here.