When you use the Restricted Groups
Member of functionality in certain scenarios, Group Policy objects may not be processed in the order that you expect. You expect the lower level organizational unit Group Policy objects to override the higher level Group Policy objects. For example, consider the following scenario:
- You create an organizational unit that is named ServersOU to which you link a Group Policy object that is named ServersGPO.
- Inside the ServersOU organizational unit, you create an organizational unit that is named ApplicationServerOU to which you link a Group Policy object that is named ApplicationServerGPO.
- You create the following two domain groups:
- DOMAIN\GlobalAdministrators
- DOMAIN\ServerAdministrators
- You edit the ServersGPO Group Policy object to add the following restricted group:
DOMAIN\GlobalAdministrators
In the DOMAIN\GlobalAdministrators Properties dialog box for this policy, you click Add under This group is a member of, and then add the Builtin\Administrators group. - You edit the ApplicationServersGPO Group Policy object to add the following restricted group:
Administrators
In the Administrators Properties dialog box for this policy, you click Add under Members of this group, and then add the DOMAIN\ServerAdministrators group.
When this policy is processed, you expect the lower level organizational unit Group Policy to be processed last and to override the earlier Group Policy processing. In this scenario, you expect only the ServerAdministrators group to be a member of the Administrators group. However, if you run the Resultant Set of Policy (RSoP) tool, both policies may be applied.
This behavior occurs if the following conditions are true:
- Conflicting restricted group settings are defined in the Members functionality and in the Member of functionality.
- Group Policy processing processes the Members functionality and the Member of functionality at the same time.
Consider the following restricted group scenario:
- Group A is configured to have a Members setting of Group C.
This configuration means that the Group Policy processing sets the membership of Group A to match what is set in the restricted Group Policy. In this example, the current membership of Group A is set to contain only Group C. Therefore, Group A should not contain any other objects. - In the same configuration, Account B is configured to have a Member of Group A setting.
This means that Group Policy processing inserts Account B into Group A's membership.
In this scenario, Group A has conflicting membership settings. The
Members setting states that Group A should contain Group C and nothing else. However, the
Member of setting states that Group A should contain Account B.
If all the
Members settings were processed before the
Member of settings, this conflict would not cause a problem. Also, if all the
Member of settings were processed before the
Members settings, this would not cause a problem. However, in this scenario, these settings are processed at the same time.
To perform this processing, Group Policy processing uses the security identifiers (SIDs) of the affected objects. In this sample scenario, Group Policy processing uses the SIDs for Group A and for Account B. Group Policy processing uses these SIDs as the sort key in the security settings database. Because these SIDs are used as the sort key in the database, the outcome of Group Policy processing depends on the ordering of these SIDs.
If Group A is configured first, the results of Group Policy processing may coincide with the results that you expect in this scenario. In this example, Group A's membership will include both Group C and Account B. However, if Account B is configured first, the results of Group Policy processing may differ from the results that you expect. In this situation, the following actions occur:
- Group Policy processing for Account B occurs. This processing adds Account B to the membership of Group A.
- Group Policy processing for Group A occurs. This processing removes Account B from the membership of Group A and adds Group C to the membership of Group A.
Note Generally, you do not experience this problem when you configure Group Policy objects in an organization. This situation is more likely to occur as an unintentional result of the processing of policy settings from two conflicting Group Policy objects.