You can further refine which groups of computers and users a particular GPO influences by using Windows 2000 security groups. To do this, you use the Security property page of a given GPO to set access permissions (discretionary access control lists2, or DACLs) to allow or deny access to the GPO by specified groups.
You can view and modify the security settings from the Security tab on the Properties page of the specific GPO. The Security tab is accessible by right-clicking the root node in the Group Policy snap-in, clicking Properties, and then Security. Or from the Properties page of a given site domain, or OU, select the Group Policy tab, right-click the appropriate Group Policy object in the GPO list, select Properties, and then click Security.
By default, a GPO affects all users and computers that are contained in the linked site, domain, or OU. By changing the Access Control Entries (ACEs) within the DACL, the effect of any GPO can be modified to exclude or include the members of any security group.
Both Read and Allow Group Policy ACEs are required for a GPO to apply to a group. By default, authenticated users have both Apply Group Policy and Read ACE permissions set to Allow. Everyone in the organization is automatically an Authenticated User. Therefore, the default behavior is for every Group Policy object to apply to every Authenticated User. By default, domain administrators, enterprise administrators, and the local system have full control permissions, without the Apply Group Policy ACE. However, administrators are members of Authenticated Users, which means that they will receive the settings in the GPO by default.
To prevent GPO policy from applying to a specified group requires removal of the Apply Group Policy ACE from that group. If you remove the Apply Group Policy ACE (clear the Allow checkbox) for Authenticated Users, you can then explicitly grant this permission to individual security groups that should receive the policy settings. Alternatively, you could set Apply Group Policy to Deny for certain classes of users, such as administrators, that will never need that policy.
Note: Use the Deny ACE with caution. A Deny ACE setting for any group has precedence over any Allow ACE given to a user or computer because of membership in another group.
Best Practice: If you disallow Apply Group Policy for a GPO for some users, consider also disallowing Read access to those users. When the Read ACE is allowed and the Apply Group Policy is not, the GPO is still processed by the user even though it is not applied to the user. Therefore, to improve performance, you should remove the Read Access Control Entry to prevent the user from processing the GPO. In addition, removing Read access increases security. With Read access allowed, it is possible for an inquisitive user with considerable knowledge of the Active Directory to read the contents of that GPO, even if it’s not applied to them. This may not be desirable in some cases, for example, a GPO for the Human Resources (HR) group. It might be advisable to limit Read access on GPOs that affect the HR users to only those users.
Security groups and DACLs are also used to delegate control of Group Policy objects, as explained in Delegating Group Policy.
MMC Snap-in Extension Model
The nodes of the Group Policy MMC snap-in are themselves MMC snap-in extensions. These extensions include Administrative Templates, Scripts, Security Settings, Software Installation, Folder Redirection, Remote Installation Services, and Internet Explorer maintenance. Extension snap-ins may in turn be extended. For example, the Security Settings snap-in includes several extension snap-ins. Developers can also create their own MMC extensions to the Group Policy snap-in to provide additional policies.
For more information on creating MMC extensions, see the Microsoft Management Console section of the Microsoft Platform SDK documentation at: http://msdn.microsoft.com/developer/sdk/platform.htm.
By default, all the available Group Policy snap-in extensions are loaded when you start the Group Policy snap-in. You can modify this default behavior by creating a custom MMC console, or by using policy settings to control the behavior of MMC itself. The MMC options are accessed under the User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node. To find out more, see Specifying Group Policy to Control the Behavior of MMC and Snap-ins, later in this document.
For further information on the Microsoft Management Console, see the "Microsoft Management Console: Overview" white paper at http://www.microsoft.com/windows2000/library/howitworks/management/mmcover.asp and the "Step-by-Step Guide to the Microsoft Management Console" at http://www.microsoft.com/windows2000/library/planning/mamagement/mmcsteps.asp, both of which are available on the Windows 2000 Web site, www.microsoft.com/windows 2000.
Group Policy Snap-in Namespace
The root node of the Group Policy snap-in is displayed as the name of the GPO and the domain to which it belongs, in the following format:
GPO Name [DomainName.com] Policy
For example:
Default Domain Policy [HQ-RES-DC-01.reskit.com] Policy
Computer Configuration and User Configuration
Below the root node, the namespace is divided into two parent nodes: Computer Configuration and User Configuration. These are the parent folders that you use to configure Group Policy settings. Computer-related Group Policy is applied when the operating system boots and during the periodic refresh cycle, explained later in this document. User-related Group Policy is applied when users log on to the computer and during the periodic refresh cycle.
Extensions to the Group Policy Snap-in
Three nodes exist under the Computer Configuration and User Configuration parent nodes: Software Settings, Windows Settings, and Administrative Templates. The Software Settings and Windows Settings nodes contain extension snap-ins that extend either or both of the Computer Configuration or User Configuration nodes. Most of the extension snap-ins extend both of these nodes, but frequently with different options. The Administrative Templates node namespace contains all policy settings pertaining to the registry; it can be extended by using administrative template (.adm) files.
The Group Policy extension snap-ins include:
Administrative Templates. This extension contains all registry-based policy settings, including those for the Windows 2000 operating system and its components, and any registry-based policy settings provided by applications. You use these policies to mandate registry settings that control the behavior and appearance of the desktop, the operating system components, and applications that provide registry-based policy. This node uses administrative template (.adm) files to specify the registry settings that can be modified through the Group Policy snap-in user interface. For more information on .adm files, see Administrative Templates later in this paper.
Security Settings. The Security Settings extension is used to set security options for computers and users within the scope of a Group Policy object. You can define local computer, domain, and network security settings. For more information on security settings, see Security Settings and Appendix E: Security Settings, later in this paper, and the security white papers available on the Windows 2000 Server Web site at http://www.microsoft.com/windows2000/library/technologies/security/default.asp.
Software Installation. You can use the Software Installation snap-in to centrally manage software in your organization. You can assign and publish software to users and assign software to computers. For detailed information on software installation, see Software Installation, later in this document, and the "Software Installation and Maintenance" white paper at http://www.microsoft.com/windows2000/library/operations/management/siamwp.asp.
Scripts. Scripts are used to automate tasks at computer startup and shutdown, and at user logon and logoff. You can use any language supported by Windows Scripting Host. These include the Microsoft Visual Basic® development system, Scripting Edition (VBScript), JavaScript, PERL, and MS‑DOS®-style batch files (.bat and .cmd). See Scripts, later in this document, and the Microsoft Scripting Technologies website at http://msdn.microsoft.com/scripting/default.htm for more information.
Remote Installation Services. Remote Installation Services (RIS) is used to control the behavior of the Remote Operating System Installation feature as displayed to client computers. See Remote Installation Services, later in this document, and the "Remote Operating System Installation" white paper at http://www.microsoft.com/windows2000/library/planning/management/remoteos.asp.
Internet Explorer Maintenance. Internet Explorer Maintenance is used to manage and customize Internet Explorer on Windows 2000-based computers. You can also export settings for Windows 95, Windows 98, and Windows NT 4.0 clients (the settings are exported into an .ins and .cab file format for those platforms). Administrators can set options for Browser UI, connections, URLs, proxy settings, security zones, and Favorites and Channels. See Internet Explorer Maintenance, later in this document, and the MS Internet Explorer 5.0 Resource Kit Tools and Utilities at http://www.microsoft.com/TechNet/IE/reskit/ie5/tools.asp.
Folder Redirection. You can use Folder Redirection to redirect Windows 2000 special folders from their default user profile location to an alternate location on the network. These special folders include My Documents, Application Data, Desktop, and the Start menu. See Folder Redirection, later in this document, and the "User Data and Settings Management" white paper at http://www.microsoft.com/windows2000/library/operations/management/settings.asp.
Information on extending the functionality of the Group Policy snap-in can be found in a white paper called “Implementing Registry-Based Group Policy for Applications,” which is being posted at http://www.microsoft.com/windows2000/library/howitworks/default.asp
Figure 3 below shows the Group Policy snap-in.
F
igure 3. The Group Policy snap-in console
Client-side Extensions to Group Policy
Some of the Group Policy snap-in extensions also include client-side extensions. These extensions are dynamic-link libraries (DLLs) that are responsible for implementing Group Policy at the client computers.
For more information on the client-side extensions, see the Client-side Processing of Group Policy section later in this paper.
Group Policy Storage
A Group Policy object is a virtual object. The policy setting information of a GPO is actually stored in two locations: the Group Policy Container (GPC) and the Group Policy Template (GPT). The GPC is an Active Directory container that stores GPO properties, including information on version, GPO status, and a list of components that have settings in the GPO. The GPT is a folder structure within the file system that stores Administrative Template-based policies, security settings, script files, and information regarding applications that are available for Software Installation. The GPT is located in the system volume folder (Sysvol) in the \Policies sub-folder for its domain.
It is possible to store data related to policy information outside the GPO. However, this requires that at least a link to the data be stored either in the GPC or the GPT. This is not recommended because it could complicate back up and restore procedures. In addition, the information outside the GPO may not be deleted if you delete the GPO, whereas Windows 2000 will automatically delete the information from the GPC and GPT.
Replication of a GPO to other domain controllers happens through two different mechanisms. The GPC is replicated by using Active Directory replication, whereas the GPT is replicated using File Replication Service (FRS). The settings from a GPO are only applied when the GPC and GPT are synchronized. GPOs are identified by their globally unique identifiers (GUIDs) and stored at the domain level.
The following illustration shows the interaction between the Group Policy snap-in, a GPO, and the storage location of the data contained in the GPO.
F
igure 4. Group Policy and storage
For additional information on storage of Group Policy information, see Appendix C: Group Policy Storage, later in this paper.
|
