Article ID: 925443
Article Last Modified on 10/11/2007
APPLIES TO
- Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
- Microsoft Windows Server 2003, Datacenter x64 Edition
- Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
- Microsoft Windows Server 2003, Enterprise x64 Edition
- Microsoft Windows Server 2003, Standard x64 Edition
- Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
- Microsoft Windows Server 2003, Enterprise Edition
- Microsoft Windows Server 2003, Standard Edition (32-bit x86)
- Microsoft Windows Server 2003, Web Edition
INTRODUCTION
This article discusses Group Policy processing behavior that may occur when you use the Restricted Groups Member of functionality in Microsoft Windows Server 2003 Group Policy objects. For more information about the "Member of" functionality, click the following article number to view the article in the Microsoft Knowledge Base:
810076 Updates to Restricted Groups ("Member of") behavior of user-defined local groups
For more information about the order in which Group Policy objects are processed, visit the following Microsoft Web site:
MORE INFORMATION
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:
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.
DOMAIN\GlobalAdministrators
- You edit the ApplicationServersGPO Group Policy object to add the following restricted group:
In the Administrators Properties dialog box for this policy, you click Add under Members of this group, and then add the DOMAIN\ServerAdministrators group.
Administrators
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.
Keywords: kbhowto kbinfo KB925443
