Windows 2000
Group Policy
Introduction
By Sean Daily, Series Editor
Welcome to The Tips and Tricks Guide to Windows 2000 Group Policy!
The book you are about to read represents an entirely new modality of book publishing and a major first in the publishing industry. The founding concept behind Realtimepublishers.com is the idea of providing readers with high-quality books about today’s most critical IT topics—at no cost to the reader. Although this may sound like a somewhat impossible feat to achieve, it is made possible through the vision and generosity of corporate sponsors such as FullArmor, who agree to bear the book’s production expenses and host the book on its Web site for the benefit of its Web site visitors.
It should be pointed out that the free nature of these books does not in any way diminish their quality. Without reservation, I can tell you that this book is the equivalent of any similar printed book you might find at your local bookstore (with the notable exception that it won’t cost you $30 to $80). In addition to the free nature of the books, this publishing model provides other significant benefits. For example, the electronic nature of this eBook makes events such as chapter updates and additions, or the release of a new edition of the book possible to achieve in a far shorter timeframe than is possible with printed books. Because we publish our titles in “real-time”—that is, as chapters are written or revised by the author—you benefit from receiving the information immediately rather than having to wait months or years to receive a complete product.
Finally, I’d like to note that although it is true that the sponsor’s Web site is the exclusive online location of the book, this book is by no means a paid advertisement. Realtimepublishers is an independent publishing company and maintains, by written agreement with the sponsor, 100% editorial control over the content of our titles. However, by hosting this information, FullArmor has set itself apart from its competitors by providing real value to its customers and transforming its site into a true technical resource library—not just a place to learn about its company and products. It is my opinion that this system of content delivery is not only of immeasurable value to readers, but represents the future of book publishing.
As series editor, it is my raison d’être to locate and work only with the industry’s leading authors and editors, and publish books that help IT personnel, IT managers, and users to do their
everyday jobs. To that end, I encourage and welcome your feedback on this or any other book in the Realtimepublishers.com series. If you would like to submit a comment, question, or
suggestion, please do so by sending an email to [email protected], leaving feedback on our Web site at www.realtimepublishers.com, or calling us at (707) 539-5280. Thanks for reading, and enjoy!
Note to Reader: This book presents tips and tricks for eight Windows 2000 and Windows XP
Group Policy topics. For ease of use, the questions and their solutions are divided into chapters based on topic, and each question is numbered based on the chapter, including:
• Chapter 1: GPOs vs. NT 4.0 System Policies • Chapter 2: How GPOs Work
• Chapter 3: Creating and Editing GPOs • Chapter 4: Designing a GPO Infrastructure • Chapter 5: Administering and Delegating GPOs • Chapter 6: Tools for Managing GPOs
• Chapter 7: Advanced GPO Features and Functions • Chapter 8: Troubleshooting GPOs.
Introduction... i
By Sean Daily, Series Editor ... i
Chapter 1: GPOs vs. NT 4.0 System Policies...1
Q 1.1: What are the principal differences between Windows 2000 and Windows XP Group Policy and Windows NT 4.0 System Policy? ...1
Flexibility...1
Ease of Administration ...3
Administrative Tools ...4
Q 1.2: What is registry tattooing, and how do Windows 2000 and Windows XP Group Policy Objects prevent it from happening?...5
Q 1.3: How do .adm files differ between Windows NT 4.0 and Windows 2000 and Windows XP?...9
Q 1.4: If I’m using user groups to control policy application in a Windows NT 4.0 system policy, how does that map to Windows Group Policy?...14
Q 1.5: Can Windows 2000 or Windows XP clients process both Windows NT 4.0 System Policies and Group Policy Objects?...19
Q 1.6: Do Group Policy Objects contain all the same policy settings that I used in Windows NT 4.0 System Policy?...20
Q 1.7: Can I still use poledit.exe to view Group Policy Objects? ...22
Q 1.8: Can I store my Windows NT 4.0 policies in the same place that Group Policy Objects are stored? ...23
Chapter 2: How GPOs Work ...26 Q 2.1: How do I know whether my Windows 2000 or Windows XP workstation is correctly
Is Your Computer Processing GPOs?...26
GPResult ...26
Event Logs ...27
RSoP ...28
Q 2.2: How does Group Policy Object security group filtering work? ...29
Q 2.3: What is the purpose of No Override and Block Inheritance? ...32
Q 2.4: How do site-linked Group Policy Objects (GPOs) work? ...35
Q 2.5: Why are changes to Group Policy Objects always written first to the PDC emulator in Active Directory?...38
Q 2.6: Can I permission a Group Policy Object such that someone can view its settings but not edit them?...40
Q 2.7: Is the Group Policy Object architecture extensible—can I create new types of Group Policy Objects? ...44
Q 2.8: What is happening during background refresh of a Group Policy Object and how do I change background refresh behavior? ...45
Chapter 3: Creating and Editing GPOs...49
Q 3.1: How can I create a Group Policy Object that is not linked to a container object? ...49
Q 3.2: How can I set account policy on a domain? ...51
Q 3.3: How do I use the restricted groups feature in Group Policy Object security policy?...54
Q 3.4: How do I use Administrative Templates policy to lockdown my desktops?...58
Darren’s Desktop Lockdown Rules ...59
Q 3.5: How can I distribute Group Policy Object changes in a non-Active Directory environment?...60
Q 3.6: How do I use Internet Explorer Maintenance policy? ...63
Q 3.7: How can I use Group Policy to ensure that certain scripts are executed each time users log off or shut down their computers? ...66
Q 3.8: Can I use Group Policy Object-based software installation to deploy a Windows service pack? ...71
Chapter 4: Designing a GPO Infrastructure...74
Q 4.1: How can I have version control for my Group Policy Objects? ...74
Embed Version Information in a GPO’s Friendly Name...74
Create Custom .ADM Files...75
GPOs that Don’t Change Aren’t Processed...79
Disable Portions of a GPO that Aren’t in Use ...80
Q 4.3: How do I deal with multiple domain forests and Group Policy Objects? ...82
Q 4.4: How do I deal with change control in my Group Policy Object infrastructure? ...84
Q 4.5: What is the best scheme for allowing my organizational unit administrators to create and edit Group Policy Objects? ...87
Q 4.6: If I have an empty forest root domain, do I need to create or use Group Policy Objects in that domain?...90
Q 4.7: What are the challenges of “sharing” Group Policy Objects between organizational units?91 Q 4.8: Can I use the Group Policy Object-based software installation feature to replace my existing software distribution tools? ...94
Chapter 5: Administering and Delegating GPOs...97
Q 5.1: How do I delegate the ability to edit and link Group Policy Objects in Active Directory?97 Delegate GPO Editing...97
Delegate GPO Linking...99
Q 5.2: How does the Delegation of Control wizard work for Group Policy Objects? ...101
Q 5.3: How can I prevent certain users from administering portions of my Group Policy Objects?104 Q 5.4: Can I delegate administration for just a part of a Group Policy Object?...106
Q 5.5: How can I audit who has made a change to a Group Policy Object? ...108
Q 5.6: What is the difference between deleting a Group Policy Object and deleting a Group Policy Object link?...113
Q 5.7: How can I delegate administration of a Group Policy Object to users who reside in different organizational units? ...115
Q 5.8: How can I view who has the rights to create Group Policy Objects in my domain?...116
Chapter 6: Tools for Managing GPOs ...120
Q 6.1: How can I create customized tools for my administrators who need to manage Group Policy Objects? ...120
Create Locked Down Tools ...120
Limit Tools Even More...122
Q 6.2: Can I script the creation of Group Policy Objects? ...122
Q 6.3: Which tool can I use to force Group Policy Object processing from the command line?124 Q 6.4: Can I create a tool that gives me a consolidated view of all my Group Policy Objects at once? ...126 Q 6.5: Do I have any control over how quickly the SYSVOL (Group Policy Template) portion of
Q 6.7: How can I add or remove particular policy extensions within the Group Policy Object
editor tool? ...133
Q 6.8: What is the difference between the Local Security Policy tool and using gpedit.msc to edit the local Group Policy Object? ...137
Chapter 7: Advanced GPO Features and Functions ...141
Q 7.1: How can I view the internals of a Group Policy Object? ...141
Locate the GUID...141
Navigate to the GPC ...142
Determine the GPT ...143
Q 7.2: What is loopback policy and how does it work? ...145
Q 7.3: How can I change the path to a deployed application’s .msi file once I’ve published or assigned the application? ...146
Q 7.4: How do I use software restriction policy in Windows XP?...150
Q 7.5: Can a client machine disable the processing of a Group Policy Object?...155
Q 7.6: How do I enable Windows XP policies in a Windows 2000 Active Directory domain? .157 Q 7.7: How is Group Policy Object history stored and used on the client? ...158
Q 7.8: I’ve heard that Windows .NET Server will provide the ability to filter Group Policy Objects using a Windows Management Instrumentation filter. What is that? ...161
Chapter 8: Troubleshooting GPOs...164
Q 8.1: What is the best tool to show me whether all of my Group Policy Objects have been replicated correctly to all domain controllers?...164
GPOTool.exe ...164
Replmon.exe ...165
Q 8.2: How can I use event log entries to troubleshoot Group Policy Object problems? ...167
Q 8.3: What is the best way to determine whether security policy is being delivered to a workstation or server?...170
Q 8.4: How can I determine whether Domain Name System problems are affecting my Group Policy Objects’ functionality?...172
Q 8.5: Why am I having trouble enabling security policy such as auditing and event log settings on my domain controllers?...173
Q 8.6: Why can I sometimes view a Group Policy Object in the list of Group Policy Objects linked to a container, but can’t edit that object? ...175 Q 8.7: When I try to edit a Group Policy Object, I get an error message that says the domain
Copyright Statement
© 2002 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtimepublishers.com, Inc. (the “Materials”) and this site and any such Materials are protected by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials,
including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties.
If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at [email protected].
Chapter 1: GPOs vs. NT 4.0 System Policies
Q 1.1: What are the principal differences between Windows 2000 and
Windows XP Group Policy and Windows NT 4.0 System Policy?
A:
Windows NT 4.0 System Policy allows you to set registry values across users, computers, and groups within your NT 4.0 (or Windows 2000—Win2K) domains. Win2K and Windows XP Group Policy include a superset of NT 4.0 System Policy functionality.Flexibility
In addition to the ability to set registry value policy—called Administrative Templates in Win2K and Windows XP Group Policy, Group Policy Objects (GPOs) include the ability to set security configurations, enforce Internet Explorer (IE) browser settings, distribute software applications, and redirect elements of users’ Desktop, My Documents, and Start menu to locations other than their user profiles. Figure 1.1 shows the Group Policy Microsoft Management Console (MMC) snap-in, focused on a Win2K GPO.
Although GPOs provide significantly more policy features than NT 4.0 System Policy provides, GPOs are stored and processed differently than NT 4.0 System Policy is. In NT 4.0, the System Policy file (often called ntconfig.pol) is stored in the Netlogon share on domain controllers within an NT 4.0 domain. When an NT 4.0 user logs onto a workstation in an NT 4.0 domain, the system reads the System Policy file from the Netlogon share, then sets registry values that are specific to a computer, user, or user group according to the policy file. NT 4.0 allows only a single policy file to be processed at a given time. NT 4.0 System Policy could apply to a specific computer (or all computers), a specific user (or all users), or an NT 4.0 domain global group. In contrast, GPOs are composed of two parts: the Group Policy Container (GPC), which is stored within Active Directory (AD), and the Group Policy Template (GPT), which is stored within the replicated SYSVOL folder on all AD domain controllers in a domain. Whereas System Policy is processed only when a user logs onto an NT 4.0 workstation, GPOs are processed at both
machine startup (at which point machine-specific policy is processed) and user logon (at which point user-specific policy is processed). Again, in contrast to System Policies, you can define a virtually unlimited number of GPOs within an AD domain (though practically speaking, large numbers of GPOs will take a long time to process). And, whereas System Policies apply to individual users, individual computers, and NT security groups, GPOs are processed only by AD users and computers. However, AD security groups composed of either machines or users can filter GPOs’ effects. This filtering capability, in conjunction with the ability to have multiple GPOs processed by a given user or computer, can provide much greater policy flexibility than is available in NT 4.0. Figure 1.2 shows an example of how you can use security groups to filter the effects of a GPO.
Ease of Administration
A single NT 4.0 System Policy can be associated to a single NT 4.0 domain at a given time; GPOs can be linked, or associated with an AD domain, an AD site (a collection of IP subnets), or an AD organizational unit (OU). When a GPO is linked to a domain, site, or OU, all users and computers that reside under those container objects in an AD infrastructure will process that GPO. Figure 1.3 shows an example of what this setup would look like in a typical AD infrastructure.
Figure 1.3: Viewing GPOs linked to multiple container objects in an AD infrastructure.
those linked to domains, and finally those linked to OUs. This order of precedence is often referred to as SDOU (as in sites, domains, then OUs).
Note that each Win2K and Windows XP device also has its own local GPO that isn’t associated with an AD infrastructure. This local GPO is actually applied before any AD-linked GPOs.
Administrative Tools
The final significant difference between System Policy and GPOs relates to the tools you use to create and edit each. GPO editing tools are significantly different than the Policy Editor tool (poledit.exe) provided in NT 4.0. GPOs rely on MMC snap-ins for creation and to be edited. The following steps walk you through how to create a new GPO:
1. From the Win2K or Windows XP Administrative Tools program group, choose the
Active Directory Users and Computers snap-in to create domain or OU-linked GPOs, or select the Active Directory Sites and Services snap-in to create site-linked GPOs.
2. Highlight the container object (the domain, site, or OU) for which you want to create the
new linked GPO, and right-click to expose the context menu for that container.
3. Choose the Properties menu item, and in the resulting window, select the Group Policy tab.
4. Click New. In the Group Policy Object Links dialog box, a new GPO is created and
From this point, all you need to do is change the name of the GPO to be descriptive and, with the GPO highlighted, click Edit to start an MMC Group Policy snap-in tool focused on your new GPO. You can then begin making changes to the GPO.
Q 1.2: What is registry tattooing, and how do Windows 2000 and
Windows XP Group Policy Objects prevent it from happening?
A:
Registry tattooing occurs when a Windows NT 4.0 System Policy makes a registry change that is left in place even if the policy no longer applies. Tattooing is a big problem in NT 4.0 System Policy. Its effects cause a variety of problems. For example, suppose you’ve set a number of registry settings in an NT 4.0 System Policy and you want to back them out.Logically, you would think that you could just remove the policy file (for example, ntconfig.pol) from the Netlogon share on your NT 4.0 domain controllers, and users would no longer get that policy. However, such is not the case at all. In fact, the registry settings that System Policy applies are permanent, unless explicitly un-done by a policy that reverses their effect. The effects from these lingering registry settings are called tattooing because the registry is tattooed with those settings.
Tattooing is the process that occurs when an NT 4.0 System Policy applies registry settings that are
not removed when the System Policy no longer applies.
Although NT 4.0 doesn’t include an easy mechanisms to undo the tattooing process, Windows 2000 (Win2K) and Windows XP both allow for registry settings to be removed when a Group Policy Object (GPO) no longer applies to a user or computer. However, this statement is not universally true for any registry setting that is set through the GPO Administrative Template policy. Win2K and Windows XP differentiate between policies and something called
preferences. Policies are those Administrative Template policy settings that are set within a
particular set of registry keys:
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies • HKEY_CURRENT_USER\Software\Policies
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies The first two registry keys are set within computer-specific GPO Administrative Template policy. The last two keys are user-specific. Thus, if you set policy that makes changes to values within one of these four keys, that policy will be removed (that is, not tattooed) if the GPO that sets the policy is no longer processed by the computer or user.
If you define an Administrative Template setting that modifies registry values outside of the four keys, such a setting is considered a preference—preferences do tattoo the registry. Microsoft recommends that all applications that use Group Policy-based Administrative Template policy write their policy settings to one of the previously mentioned four keys. Thus, those settings are
Within the Group Policy Microsoft Management Console (MMC) snap-in tool, you can filter the view of Administrative Templates to view only policies that don’t tattoo the registry (that is, those that make changes only to the keys listed earlier) or both policies and preferences. The mechanism to filter the view is different between Win2K and Windows XP, but the effect is the same. In Windows XP, from the Group Policy MMC snap-in, highlight and right-click either the Administrative Templates node in either Computer or User configuration. From the resulting context menu, select View, then choose Filtering from the sub-menu. The dialog box that Figure 1.5 shows will appear.
Figure 1.5: Viewing the filtering options in the Windows XP-based Group Policy editor tool.
In Figure 1.5, there is an option that says Only show policy settings that can be fully managed.” The term “fully managed” is Windows XP’s way of saying that the policy setting does not tattoo the registry. If you clear this check box, you will see both policy settings as well as preferences. The MMC Group Policy tool differentiates policies and preferences by associating different colors to the icons representing each. In Figure 1.6, I’ve created a custom .adm template file that sets a preference within the registry. You can see that my preference Set current GPO version for
Figure 1.6: Viewing a preference, indicated by a red icon, within the Group Policy MMC tool.
The other policy items in Figure 1.6 have blue icons associated with them indicating that they are non-tattooing policies.
Win2K’s Group Policy MMC tool works the same as in Windows XP. However, the menu item that you use to filter the view of policies and preferences is different. Namely, from the Win2K Group Policy MMC tool, highlight an Administrative Templates node, right-click, select View from the context menu, and clear the Show Policies Only check box to view both policies and preferences.
So now we know the effects of tattooing. To better understand the actual process, let’s look at how it works behind the scenes. The specific registry keys and values that are modified within GPO-based Administrative Template policy is controlled by the .adm template files associated with that GPO. Listing 1.1 shows a snippet from an .adm template file in Windows XP.
CATEGORY !!Logon #if version >= 4 EXPLAIN !!Logon_Help #endif POLICY !!NoWelcomeTips #if version >= 4 SUPPORTED !!SUPPORTED_Win2kOnly #endif KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" EXPLAIN !!NoWelcomeTips_Help VALUENAME "NoWelcomeScreen" END POLICY
Listing 1.1: Viewing a snippet from a Windows XP .adm template file.
In Listing 1.1, the NoWelcomeScreen registry value is being modified under the registry key Software\Microsoft\Windows\CurrentVersion\Policies\Explorer. From Listing 1.1, this key is under the path listed as one that protects from tattooing. Now, as you probably know, an
Administrative Template policy can take three states—not configured, enabled, or disabled (see Figure 1.7).
When a state is set to not configured, the registry value specified within the .adm file has not been set. For example, in Listing 1.1, a not configured setting would mean that the
NoWelcomeScreen registry value does not exist on machines that are processing the GPO on which that policy is defined. If the policy is enabled, the registry value is created and the data within the value is set according to the .adm file. In some cases, it may mean simply setting the value to 1 or 0. In other cases, it may be filling the value with some text string, but in either case, making the policy enabled means that the registry value exists and is set to some value. If the policy is set to disabled, the registry value is set to the opposite value, as specified by the .adm file, from the enabled state. Again, looking at the .adm snippet in Listing 1.1, this policy dictates that the NoWelcomeScreen value is created and set to 1 when the policy item is enabled and 0 when its not.
When a policy item defined in the .adm template file does not explicitly call out what the values should be for the enabled and disabled states, the default is to take a REG_SZ type value of 1 for enabled and a REG_SZ type value of 0 for disabled.
If an Administrative Template policy item such as the one that Listing 1.1 shows makes changes to the “magic” keys in the registry that prevent tattooing, that value will change from enabled or disabled when the GPO is processed by the computer or user to not configured if the GPO no longer applies to the computer or user. However, if the policy item does not make a change to one of the “magic” keys, whatever change it makes to the registry—be it enabled or disabled— will remain even after the GPO has been removed or no longer applies to the computer or user. To get rid of it, you would need to explicitly set that preference to not configured to remove the tattooed registry value. So, as you can see, there is a significant reduction in the policy
maintenance you have to do on a system if you use policies instead of preferences.
Q 1.3: How do .adm files differ between Windows NT 4.0 and Windows
2000 and Windows XP?
A:
Microsoft has added quite a few new features to the Administrative Template .adm “language” between Windows NT 4.0 and Windows XP. Most of the new features are in the form of new keywords that enable new Group Policy features and functions. For example, in Windows 2000 (Win2K), Microsoft added the EXPLAIN tag to allow for the text explanations that you find in the Group Policy Microsoft Management Console (MMC) snap-in (see Figure 1.8).Figure 1.8: Viewing the Explain text associated with an Administrative Template policy.
Listing 1.2 shows an example of how the EXPLAIN tag is called within an .adm file. POLICY !!NoSecurityMenu KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" EXPLAIN !!NoSecurityMenu_Help VALUENAME "NoNTSecurity" END POLICY
Listing 1.2: An example of the EXPLAIN tag used in Win2K and Windows XP .adm files.
In Listing 1.2, the EXPLAIN tag references some text, defined using a label (in this example, !!NoSecurityMenu_Help), which is usually defined at the end of an .adm file within a section called out by the [strings] tag. Within the [strings] section, each label is defined to equal a text string that defines what that label means. It’s this text string that is shown in the Group Policy editor tool to explain a policy item. Win2K and Windows XP EXPLAIN tags improve upon the NT 4.0 System Policies by providing an explanation of what a given policy actually does and how you can use it. If you create custom .adm files, you should strongly consider creating accompanying EXPLAIN tags that explain your custom policy.
In addition to the EXPLAIN tag, Win2K and Windows XP include some additional logic within the .adm file to test the version of policy editor tool that is loading the .adm file. Because the NT 4.0 policy editor won’t understand newer tags supported in Win2K and Windows XP, .adm files created for these newer Windows versions use special logic to test for the version of the policy
#if version <= 2 CLASS USER
CATEGORY !!GPOnly
POLICY !!GPOnlyPolicy
KEYNAME "Software\Policies" PART !!GPOnly_Tip1 TEXT END PART
PART !!GPOnly_Tip2 TEXT END PART
PART !!GPOnly_Tip3 TEXT END PART
PART !!GPOnly_Tip4 TEXT END PART
PART !!GPOnly_Tip5 TEXT END PART END POLICY END CATEGORY CLASS MACHINE CATEGORY !!GPOnly POLICY !!GPOnlyPolicy KEYNAME "Software\Policies" PART !!GPOnly_Tip1 TEXT END PART
PART !!GPOnly_Tip2 TEXT END PART
PART !!GPOnly_Tip3 TEXT END PART
PART !!GPOnly_Tip4 TEXT END PART
PART !!GPOnly_Tip5 TEXT END PART
END POLICY END CATEGORY
Note that in Listing 1.3, the first statement is #if version <= 2. This statement checks to see whether the version of policy editor tool is equal to or less than version 2. Version 2 corresponds to the NT 4.0 policy editor tool (poledit.exe) or earlier policy tools. If the NT 4.0 policy editor tool attempts to load and use an .adm file created for Win2K or Windows XP, the only policy entry you will see is that shown in Figure 1.9.
Figure 1.9: Viewing the effects of loading a Win2K .adm file using the NT 4.0 policy editor tool.
The sections of text that you see in Listing 1.3 after the version check are there to create the screen you see in Figure 1.9. That is, the various labels such as GPOnly_Tip1 thru Tip5 contain the text shown in the Settings for System.adm section of the dialog shown in this figure. Listing 1.3 is saying that if the version is 2 or less (that is, the NT 4.0 system policy editor tool), show the text specified by the various tips, which basically explains that you need a newer version of the policy tool to view the contents of the .adm file.
If the NT 4.0 policy editor tool is version 2, it stands to reason that version 3 is the Win2K MMC-based Group Policy snap-in, and version 4 is the GPO snap-in that comes with Windows XP. In Win2K- and Windows XP-based .adm files, you will see version checks for versions 3 and 4 as well.
Windows XP also includes a new twist. Windows XP lets you view and filter Administrative Template policy items based on which platform is required by a given policy. For example, if you have an .adm policy that works only on Windows XP, you want to know that setting the policy will have no effect on Win2K machines that process the policy. To do so, .adm files in
POLICY !!ShutdownReason #if version >= 4
SUPPORTED !!SUPPORTED_WindowsXP
#endif
EXPLAIN !!ShutdownReason_Help
KEYNAME "Software\Policies\Microsoft\Windows NT\Reliability" PART !!ShutdownReason_Box DROPDOWNLIST REQUIRED VALUENAME "ShutdownReasonUI"
ITEMLIST
NAME !!ShutdownReason_Never VALUE NUMERIC 0 DEFAULT
NAME !!ShutdownReason_Always VALUE NUMERIC 1 END ITEMLIST
END PART END POLICY
Listing 1.4: Viewing the use of the SUPPORTED tag in an XP .adm file.
The SUPPORTED tag is not a hard restriction. That is, unlike the version checks, it doesn’t prevent the Win2K version of the Group Policy editor tool from loading a Windows XP .adm file and setting policies. In fact, a Win2K Group Policy editor will simply ignore the SUPPORTED tag because the tag is always surrounded by the statement #If version >= 4, which indicates to the Group Policy tool reading the file that the section within the #if and #endif clauses be read only by a Windows XP (version 4) version of the Group Policy editor tool.
For Windows XP, the SUPPORTED tag allows two capabilities. The first is that, on the main dialog box of each policy item, the SUPPORTED tag is read to indicate which version of the OS the current policy supports (see Figure 1.10).
In addition, Windows XP uses the SUPPORTED tag to let you filter policy items based on their OS requirement. From the Group Policy MMC snap-in tool, if you highlight the Administrative Templates node (either per computer or per user), and select View, Filtering, you will see the dialog box that Figure 1.11 shows.
Figure 1.11: Using the SUPPORTED tag within the Windows XP Group Policy editor tool to allow filtered views of .adm policy.
From the dialog box that Figure 1.11 shows, you can view Administrative Template policy items that are specific to a particular OS so that you know which policies will affect which clients on your network.
Q 1.4: If I’m using user groups to control policy application in a
Windows NT 4.0 system policy, how does that map to Windows Group
Policy?
A:
Windows 2000 (Win2K) Group Policy Objects (GPOs) don’t have the same concept of creating multiple user–group–specific policies within a single policy file, but you can achieve similar results using a combination of GPO-based features. In Windows NT 4.0, you could create a policy file (usually ntconfig.pol) that contained specific policy for a number of different users, machines, or user groups. For example, I could have default computer and default user policy applying to all users and specific policy applying to a specific user or user group in my NT 4.0 domain. In Figure 1.12, you see an NT 4.0 system policy file that provides policy settings for the Finance Admins and Finance Users domain global groups.Figure 1.12: Viewing an NT 4.0 system policy file that uses global groups to specify policy.
When you’re ready to migrate your NT 4.0 system policies to Win2K GPOs, you may find that the scheme you had used in your system policies doesn’t quite map to how GPOs work.
Specifically, there is no analogous concept in GPOs to that of creating user, machine, or user– group–specific policy settings within a single policy file. If you want to target a set of policy settings to a particular user, machine, or group, you need to use GPO-based security group filtering to achieve the desired results. What that means is that a single ntconfig.pol file in NT 4.0 that contains three user–group–specific policies will require three separate GPOs in Win2K to achieve the equivalent policy control. Let’s take a look at how this might work.
In NT 4.0, you typically created policy groups like those that Figure 1.12 shows within your system policy file to provide different desktop lockdown settings for different sets of user groups. For example, again referring to Figure 1.12, I might have a looser set of desktop
restrictions for the Finance Admins group than I do for the Finance Users Group. Now, that’s all fine until it comes time to start implementing equivalent desktop lockdown in Win2K or
Windows XP Group Policy. By using a tool such as gpolmig.exe from the Win2K Server resource kit, you can take system policy settings and merge them into a GPO.
Make sure you use the version of gpolmig.exe that comes in supplement 1 of the Win2K Server resource kit. The version that ships in the original Win2K Server resource kit doesn’t work! (Thanks to Derek Melber of braincore.net for this tip.)
Gpolmig.exe lets you take specific policy settings in an NT 4.0 system policy file and export them into Administrative Templates policy within a GPO. Let’s take the system policy that Figure 1.12 shows and convert it to equivalent desktop lockdown policy in a Win2K domain. The first step in the conversion process is to create the target GPOs that will house your NT 4.0 policy settings. In my example, I want to take the settings that I’ve created for the Finance Admins and Finance Users groups and migrate them to Group Policy. To do so, I need to create
1. Start the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in tool. Highlight the OU to which the GPOs will be linked (in this case, Finance), and right-click the OU.
2. Choose Properties from the context menu, then select the Group Policy tab.
3. From the Group Policy dialog box, click New, then name the GPO “Finance Admins
Lockdown.”
4. Repeat Step 3, creating a GPO called “Finance Users Lockdown.” Figure 1.13 shows the two GPOs you’ve just created.
Figure 1.13: Viewing the GPOs created to hold converted NT 4.0 system policy settings.
5. After creating the two new GPOs, we need to set up the security filters to control how they’re applied. From the GPO dialog box that Figure 1.13 shows, highlight the “Finance Admins Lockdown” GPO, and click Properties.
6. From the Properties dialog box, choose the Security tab. Because we want this GPO to only apply to the Finance Admins group, you need to prevent other users from processing it. Highlight the Authenticated Users Access Control Entry (ACE) in the security dialog box, and clear the Apply Group Policy permission for this group.
7. Click Add from the top of the dialog box, and choose the Finance Admins group from the domain list.
8. With the Finance Admins group highlighted, select the Apply Group Policy permission to
ensure that only this group processes the GPO (see Figure 1.14).The Read permission should be created by default, but if it isn’t, you must also select it to allow GPO
Figure 1.14: Adding a security filter to a GPO to control which user group processes it.
9. Repeat Steps 6 through 8 for the Finance Users Lockdown GPO, adding the Finance
Users global group to the security permissions rather than Finance Admins.
Now you’re ready to migrate the NT 4.0 system policies into Win2K GPOs. The first step is to confirm that the gpolmig.exe tool actually sees all the policy groups that you’ve created in your NT 4.0 system policy file. From a command line, type the following to list the contents of your system policy file:
Gpolmig c:\policy\ntconfig.pol /list
where c:\policy\ntconfig.pol is the path to your NT 4.0 system policy file. You should see output similar to that which Figure 1.15 shows.
To actually migrate the settings for each policy group, you need to know the globally unique ID (GUID) for the target GPO. There are a couple of ways to identify a GPO’s GUID, but the easiest is to use the gpolmig tool to do the work for you. The first thing to do is open up one of your target GPOs using the Group Policy MMC snap-in. Then, from the command-line, issue the following gpolmig command:
Gpolmig c:\policy\ntconfig.pol /listgpo
The output is similar to that which List 1.5 shows. Using Downlevel policy file: ntconfig.pol Processing GPOs currently being edited... Current Group Policy Objects Open
(open the Properties of GPOs and locate the 'Unique Name' to identify the Globally Unique Identifier, or GUID, that is displayed here) --- {D5D09664-0319-4BEC-97B2-5AC31B75D09B}Machine {D5D09664-0319-4BEC-97B2-5AC31B75D09B}User
Listing 1.5: Viewing the output from a gpolmig listgpo command.
The last two lines of this output are the GUIDs for the GPO that is currently open on your desktop. Note that they are both the same, but are differentiated by the computer- and user-specific portions of every GPO. Because we are migrating user group policies from an NT 4.0 system policy, our target is the user-specific settings within a GPO. To actually perform the conversion, we’re going to take the output from the last two gpolmig commands and use the information to generate the command that will do the actual conversion. In the case of my example, I’m going to migrate the settings in the Finance Admins system policy into my new Finance Admins lockdown GPO using the following command:
gpolmig ntconfig.pol /migrate group "Finance Admins" {D5D09664-0319-4BEC-97B2-5AC31B75D09B}User
This command tells gpolmig to migrate the NT 4.0 “group” type policy called “Finance Admins” to the Administrative Template user portion of the GPO specified by the GUID. After this
command executes, all settings that can be migrated to my new GPO will be.
Gpolmig is not a perfect tool. Some settings that exist in NT 4.0 .adm template files may not exist in Win2K GPO .adm files and thus won’t be migrated. If you have created custom .adm files for your NT 4.0 system policies, you need to be sure to load those into your new GPO prior to attempting a migration.
If you repeat this migration process for the Finance Users, you will effectively have the same policy lockdown features in two Win2K GPOs that you had in a single NT 4.0 system policy file. Of course, GPOs give you added flexibility that you never had in NT 4.0 system policy, but at the very least, you still get the desktop lockdown via Administrative Templates!
Q 1.5: Can Windows 2000 or Windows XP clients process both
Windows NT 4.0 System Policies and Group Policy Objects?
A:
Windows 2000 (Win2K) and Windows XP can process both Group Policy Objects (GPOs) and Windows NT 4.0 System Policies. However, the rules for which gets processed when depends upon where user and machine accounts reside.An NT 4.0 System Policy file (for example, ntconfig.pol) is only applied when the corresponding user or machine accounts still reside within an NT 4.0 domain. For example, many enterprises, in the midst of migrating from NT 4.0 to Win2K AD, migrate user accounts into Active Directory (AD) but leave machine accounts in NT 4.0 resource domains. In such cases, any computer-specific System Policies (policies that make changes in the registry to
HKEY_LOCAL_MACHINE) that you’ve created in your NT 4.0 domains are applied to the Win2K or Windows XP machine when the AD user logs onto the AD domain from that
workstation. However, no user-specific NT 4.0 System Policy settings are processed if the user account resides in an AD domain. To better understand this concept, let’s explore the scenario that Figure 1.16 illustrates.
In the example that Figure 1.16 shows, we have a Win2K client machine whose machine account resides in the NT 4.0 domain called Sales. There is a user named Bob, who has an account defined in the AD domain called myorg.tld. Bob logs onto the Win2K client workstation in Sales. Which policies will Bob receive? Because the machine account of the workstation on which Bob is logging on is in an NT 4.0 domain, as soon as Bob logs onto that machine, any machine-specific NT 4.0 System Policy file that exists in the Netlogon share on the myorg.tld AD domain controllers will be processed.
Even on a Win2K or Windows XP client, a user must log onto the machine before the NT 4.0 System Policy is processed. This requirement contrasts machine-specific GPO policy, which only requires a machine restart to trigger processing. In addition, the ntconfig.pol file must reside on the domain controllers of the authentication domain—in this case, an AD domain called myorg.tld.
In the previous example, only computer-specific System Policy will be processed. If a “Default Computer” or machine-specific policy has been defined in the NT 4.0 System Policy, that policy will be processed. No user-specific System Policy will be read, even if it is defined, because the user account in this example resides in an AD domain, and thus will only process user-specific Group Policy.
It’s also worth noting that if an NT 4.0 user account logs onto a Win2K or Windows XP machine that resides in an NT 4.0 domain, no GPOs (other than the local machine GPO) are processed— only NT 4.0 System Policy is processed. Also remember that if you want NT 4.0 System Policy to be processed in a mixed AD and NT 4.0 domain environment, you need to make sure that your policy file—ntconfig.pol—is found in the Netlogon share of the domain controllers in the
authentication domain (the myorg.tld domain in the previous example). On NT 4.0 domain controllers, this location is typically in %systemroot%\system32\repl\import\scripts. On AD domain controllers, Netlogon is shared only for backward compatibility as part of the replicated SYSVOL structure and can be found under %systemroot%\sysvol\sysvol\<domain
name>\scripts. If you place your ntconfig.pol files in this folder, they will automatically be replicated to other AD domain controllers in the domain. Finally, if you decide that you don’t want NT 4.0 System Policies to be processed for certain machines or users, you can always disable System Policy processing by changing the value of the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update\UpdateMode registry subkey from 1 to 0.
Q 1.6: Do Group Policy Objects contain all the same policy settings
that I used in Windows NT 4.0 System Policy?
A:
The quick answer to this question is no. You will find that some of the policy settings that you might have relied upon in Windows NT 4.0 System Policy are no longer supported in Windows 2000 (Win2K)- and Windows XP Group Policy Object (GPO)-based policy, for good reason. Some of the changes in the Win2K and Windows XP shell environment facilitated the need to drop support for certain NT 4.0 settings. In other cases, settings that were implemented as .adm files in NT 4.0 might have been folded into other mechanisms in Group Policy. For example, in NT 4.0 there was a user-specific policy within the winnt.adm template file that letFigure 1.17: Viewing the shared folder policy in NT 4.0 System Policy.
However, in Win2K and Windows XP, this feature has been usurped and improved upon by the Folder Redirection policy. You won’t find the Custom Folders policy item anywhere in Group Policy. Instead, Folder Redirection lets you redirect certain user profile-based folders, such as Desktop, to alternative locations (usually server shares) for all users subject to that GPO or based on a user’s group membership (see Figure 1.18).
NT 4.0 Policy Setting Equivalent Win2K or Windows XP GPO Setting
Default Computer, Windows NT System, Logon, Do not display last logged on user name
Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, Do not display last user name in logon screen (Windows XP: Interactive Logon: Do not display last user name) Default Computer, Windows NT User Profiles,
Delete cached copies of roaming profiles Computer Configuration, Administrative Templates, System, Logon, Delete cached copies of roaming profiles (Windows XP: Computer Configuration, Administrative Templates, System, User Profiles, Delete cached copies of roaming profiles) Default User, Control Panel, Display, Restrict
Display, Hide Screen Saver Tab User Configuration, Administrative Templates, Control Panel, Display, Hide Screen Saver Tab Default User, Shell, Restrictions, Remove Run
command from Start Menu User Configuration, Administrative Templates, Start Menu & Taskbar, Remove Run menu from Start Menu Default User, Shell, Restrictions, Hide Drives in
My Computer User Configuration, Administrative Templates, Windows Components, Windows Explorer, Hide these specified drives in My Computer
Default User, System, Restrictions, Disable
Registry editing tools User Configuration, Administrative Templates, System, Disable registry editing tools (Windows XP: Prevent access to registry editing tools)
Default User, Windows NT User Profiles, Limit
profile size User Configuration, Administrative Templates, System, Limit Profile Size
Table 1.1: Viewing some NT 4.0 policy settings and their equivalents in Win2K Group Policy.
As you can see from the table, you might have to do some serious hunting to locate the NT 4.0 System Policy setting that you want to implement in Win2K or Windows XP Group Policy. The good news is that there seem to be very few NT 4.0 policy settings that simply aren’t supported in Win2K or Windows XP.
Q 1.7: Can I still use poledit.exe to view Group Policy Objects?
A:
As I’ve mentioned in previous tips, Group Policy Objects (GPOs) contain more policyinformation than the registry-based .adm policies that Windows NT 4.0 supports. Still, a .pol file, called registry.pol, is stored within the machine and/or user folder under a GPO’s Group Policy Template (GPT) folder structure under SYSVOL (see Figure 1.19).
Unfortunately, Microsoft changed the format of the registry.pol file from that which was supported in NT 4.0 .pol files. NT 4.0 pol files were actually registry hive files that could be loaded using poledit or even regedt32.exe. GPO-based registry.pol files do not follow that same pattern; thus, you won’t be able to load a registry.pol file using poledit.exe. In addition, you can’t load some Windows 2000 (Win2K) or Windows XP-specific .adm template files with
poledit.exe, as they will show up as unsupported.
So if you’re used to using poledit.exe to manage policy in NT 4.0, you will have to leave it by the wayside for managing most GPO-based policy. Of course, you can still use the open registry option in the File menu of poledix.exe to view the current registry settings of a local Win2K or Windows XP computer (see Figure 1.20).
Figure 1.20: Viewing poledit.exe opened on the local registry of a Win2K computer.
In local registry mode, you will only see the policy items that are presented by the currently loaded .adm files. Thus, you will have to either load Win2K- or Windows XP-based .adm files that support poledit.exe, or you will need to limit what you can view to registry values supported by NT 4.0-based .adm settings that are still supported in Win2K or XP. All in all, you’re better off sticking with the Microsoft Management Console (MMC)-based GPO tools to view and modify GPOs.
Q 1.8: Can I store my Windows NT 4.0 policies in the same place that
Group Policy Objects are stored?
A:
As you know, Windows NT 4.0 System Policy files were typically stored in the Netlogon share on NT 4.0 domain controllers. However, in Windows 2000 (Win2K), Group Policy filesSYSVOL and NTFRS replication completely replaces the old NT 4.0 directory replication service that supported replication of the Netlogon share. If you view the default shares that are created on a Win2K domain controller, you’ll see that both SYSVOL and Netlogon exist on the server but that they are located in different paths within the NTFRS replication tree (see Figure 1.21).
Figure 1.21: Viewing the Netlogon and SYSVOL shares on a Win2K domain controller.
As you can see in Figure 1.21, both Netlogon and SYSVOL are shared under the
%systemroot%\SYSVOL\sysvol folder on a domain controller. Files that are part of a GPO’s Group Policy Template (GPT) are stored in SYSVOL\<domain name>\policies, whereas files that are shared as Netlogon are stored in SYSVOL\<domain name>\scripts.
Note that the path %systemroot%\SYSVOL\sysvol\<domain name> is actually a symbolic link (or junction point) to the folder %systemroot%\SYSVOL\domain. So both folders point to the same place in the file system.
If you have NT 4.0 machines in your Win2K Active Directory (AD) domains (or Win2K
machines in NT 4.0 domains that are authenticating to AD domains), you might need to maintain some NT 4.0 System Policy processing capability. In that case, you would have to copy your ntconfig.pol files into the Netlogon-shared “scripts” folder on your Win2K domain controllers. NTFRS automatically replicates all content under %systemroot%\SYSVOL\domain to all domain controllers within a domain. Given that, you only need to copy your ntconfig.pol file to the scripts folder on one domain controller to have it replicate everywhere. You can, of course, redirect where an NT 4.0 or Win2K system will look for the ntconfig.pol file. There is a registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update that lets you override the default behavior of looking in the Netlogon share at logon time for the System Policy file. By adding two registry values under the Update key, you can modify this default
• UpdateMode of type REG_DWORD and must have a value of 0x2 in order to specify a path to the ntconfig.pol file other than Netlogon.
• NetworkPath of type REG_SZ and points to the UNC path where the file is located (for example, \\myserver\sysvol\mar-elia.com\policies\ntconfig.pol).
If you specify a path to a single Win2K domain controller, you lose the fault tolerance that NTFRS provides. However, if you have a fault-tolerant DFS tree at your disposal that replicates content across multiple Win2K servers, you could enter the path to that DFS tree in the
NetworkPath registry value. Note that these two registry values must be added on all NT 4.0 and Win2K machines that you expect to process System Policy against your AD domain.
Chapter 2: How GPOs Work
Q 2.1: How do I know whether my Windows 2000 or Windows XP
workstation is correctly processing Group Policy Objects that are
defined in my Active Directory infrastructure?
A:
There a number of ways to tell whether your workstations or servers are processing Group Policy Objects (GPOs). But first, it helps to understand the mechanisms behind GPO processing.GPO Background
The details behind GPO processing are fairly straightforward. A GPO is really composed of two pieces—the Group Policy Template (GPT) and the Group Policy Container (GPC). The GPC is a set of Active Directory (AD) objects and their attributes that define the basic GPO. The GPT is a set of files and folders within the SYSVOL share on each domain controller in an AD domain. The GPT contains most of the settings for the policy items you select within the Group Policy Microsoft Management Console (MMC) snap-in. When a Windows 2000 (Win2K) or Windows XP workstation boots or a user logs onto a machine, a process running on the workstation or server called Winlogon.exe calls a set of DLLs called client side extensions (CSEs).
You can view the list of CSEs registered on a particular Win2K or Windows XP computer by going into the registry and viewing the subkeys listed under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions. Each subkey listed describes a CSE. The values under each subkey describe which policy processing functionality that DLL provides—for example, folder redirection, disk quota, registry settings (administrative templates)—as well as settings related to how that CSE behaves when processing a GPO.
CSEs are the code responsible for reading the GPC and GPT for each GPO that the computer or user must process and for applying the policy settings to that computer or user. This processing can happen in the background while other tasks are going on (asynchronous), or in the
foreground, preventing other tasks from happening until GPO processing is complete (synchronous).
Is Your Computer Processing GPOs?
Now that we have an overview of how GPO processing occurs, let’s look at ways to know whether your computer or user is actually processing the GPO. There are several approaches you can take to check GPO processing.
GPResult
Gpresult.exe is a Win2K resource kit and Windows XP built-in utility that provides a command-line mechanism for viewing which GPOs are being applied to a given machine. The Win2K version is limited in that it can be run only on the machine for which you want to analyze GPO
details about any security policy that has been set on the machine. The Windows XP version does not have this limitation. To access a listing similar to the one that Figure 2.1 shows, type
gpresult
at a command prompt.
Figure 2.1: Viewing the output of the gpresult.exe tool.
GPResult supports a couple of command-line switches, including /v and /s, which output the results in verbose and super-verbose modes, respectively.
Gpresult.exe is best used as a quick and dirty tool for viewing which GPOs are in effect on a given workstation or server. However, for more robust reporting, use one of the Resultant Set of Policy (RSoP)-based approaches described later.
Event Logs
The Win2K event logs can be useful for viewing the effects of GPO processing (as well as for GPO troubleshooting, as you’ll see in Chapter 8). All GPO-related events are reported in the Application event log in Win2K and Windows XP. By default, some events are logged out-of-the-box. However, to get the best results from the event logs, you need to set some registry values to enable more verbose GPO logging. To get more verbose logging, add the following registry subkey (if it doesn’t already exist) to any Win2K or Windows XP machine on which you
processed during each processing cycle. However, this logging won’t tell you which settings were applied to your machines. For that additional functionality, you will need some kind of RSoP tool, like those described below.
RSoP
RSoP provides the ability to view, for a given user logging onto a given computer, the GPOs that have been applied. There are a couple of tools on the market that provide RSoP capability for Win2K and Windows XP, including FullArmor’s FAZAM. This product not only allows you to view effective policy for a given user and computer, but also lets you perform what-if analysis for users and computers that you plan to move around your AD (for example, change
organization units—OUs), view and edit a domain’s GPOs at-a-glance, and perform diagnostics and auditing on GPOs. The planning capability is useful in that it can tell you what the effective policy would be if you moved an existing user or computer. Figure 2.2 shows a view of the FAZAM analysis capability.
Figure 2.2: Viewing the results of an analysis using FAZAM.
Windows XP also includes a rudimentary RSoP MMC snap-in that you can use to analyze policy (but not perform what-if scenarios) on local or remote computers for any user. Follow these steps to bring up the Windows XP RSoP tool:
1. From the Start menu, select Run, and in the resulting text box, launch mmc.exe to bring
up a blank MMC console.
2. From the Console menu in Win2K or the File menu in XP, choose Add/Remove Snap-in, and click Add. From the list of available snap-ins, choose Resultant Set of Policy.
Q 2.2: How does Group Policy Object security group filtering work?
A:
Group Policy Object (GPO) security group filtering is the process by which you can filter the effects of a GPO by restricting which user or computer groups can “view” that GPO. In most cases, the best way to restrict which computers or users will process a GPO is to link that GPO at an appropriate level within Active Directory (AD). If you don’t want a GPO to be processed by all users in an AD domain, don’t link it to the domain level but rather to the site or organizational unit (OU) level.However, there may be cases in which you need to apply a GPO to most of the users in your domain, but you want to exclude a small group of users. Similarly, you may have a GPO linked to an OU, but you want to let only a small group of users within that OU process the GPO. In either case, using security group filtering is the right solution.
Security group filtering of GPOs is very similar to restricting access to certain NT File System (NTFS) files and folders on a server or workstation. In both cases, you are applying access permissions to the resource in question to allow or deny certain groups of users or computers access to that resource. The access control list (ACL) on a resource contains a list of access control entries (ACEs) that specify who can access that resource—regardless of whether the resource is a file folder on a server or a GPO defined in AD. Figure 2.3 shows an example of what an ACL on a GPO looks like.
To navigate to the dialog box that Figure 2.3 shows, you need to load a Group Policy Microsoft Management Console (MMC) snap-in tool, focused on a GPO within your AD domain, or you can view the properties on a GPO from either the Active Directory Users and Computers snap-in or the AD Sites and Services snap-in. If you choose the latter approach, once the tool is loaded, highlight the container object (site, domain, or OU) to which the GPO of interest is linked, right-click the container, and select Properties from the context menu. Next, select the Group Policy tab, highlight the GPO you want to view, click Properties, and select the Security tab.
The ACL that Figure 2.2 shows has two roles. The first role is to set permissions for who can edit the GPO. The second role is to control who will process the GPO. For now, we’re interested in the latter role. There are two permissions that control whether a particular user or computer will process a GPO—the Read permission and the Apply Group Policy permission. The
combination of these two permissions allows a user or computer the ability to process a GPO. In fact, a computer or user must have both permissions defined to process the GPO—having one but not the other will not work.
Before you’re ready to start applying security group filters to your GPOs, you should understand a few key points. First, by default, all GPOs will have the Authenticated Users group with Read and Apply Group Policy permissions set. This setting means that all users and computers (yes, computers) will process the GPO. Computers are considered part of the Authenticated Users group as well as users because each computer account in an AD domain has a user account created for it to allow it to securely connect to the domain.
All domain computers and users are considered part of an AD domain’s Authenticated Users group. The next step for using security group filtering depends upon whether you’re restricting the GPO to a small group of users or computers or allowing all but a small group of users or computers to process a GPO. Let’s look at the first case.
If you want to restrict a GPO so that only a particular group of users or computers can process it, the first thing you’re going to need to do is remove the ACE for the Authenticated Users group. From the ACL editor that Figure 2.3 shows, simply highlight the Authenticated Users group and click Remove to remove the ACE. Next, you need to add the new ACE for the computer or user group that you want to grant access to the GPO. Click Add at the top of the ACL editor dialog box, and choose the computer or user group you want to grant access to.
You can add ACEs granting Read and Apply Group Policy rights to individual users and computers instead of groups. However, doing so is not recommended because it adds complexity and, as the list of permissions on a GPO grows, slows down the processing of this GPO as the computer or user sifts through all the ACEs.
Once you’ve added the group, select the Read and Apply Group Policy permissions under the Allow column in the ACL editor, as Figure 2.4 shows.
Figure 2.4: Adding a new ACE on a GPO.
In Figure 2.4, the Finance Users group has been granted access to process a GPO called Desktop Lockdown Policy that has been linked to the Finance GPO. Notice that the Authenticated Users group is nowhere to be found on this GPO. Thus, only the Finance Users group (and any other group that has Read and Apply Group Policy rights) will process this GPO.
Now, let’s look at the second case, in which we want to exclude a small group of users or
computers from processing a GPO that otherwise would be processed by every user or computer. In this case, we will use a Deny ACE to prevent a group from processing the GPO. Figure 2.5 shows an example of this.
In Figure 2.5, I’ve added an ACE for the Finance Servers group to the Default Domain Policy GPO. The Finance Servers group is a group of servers in the Finance OU that I don’t want to process the computer portion of the Default Domain Policy GPO. As you can see, the
Authenticated Users ACE is still in place on this GPO, guaranteeing that all users and computers subject to this GPO (which is linked at the AD domain level) will process it. However, by adding a Deny ACE for the Finance Servers, which overrides any Allow ACEs automatically, I
effectively prevent this computer group from processing the GPO.
In this example scenario, I could have simply added a Deny ACE for the Read permission because denying Read effectively prevents the group from processing the GPO, regardless of whether the Apply Group Policy permission was allowed. Remember, a group must have both permissions to process a GPO.
You can use these methods of adding Allow and Deny ACEs to selectively filter the effects of a GPO for particular groups of users and computers. However, because long ACLs on a GPO add to the time required to process that GPO, I recommend being judicious about how you use security group filtering. In addition, you can create a confusing situation if you add many ACEs to a GPO—some that allow access to particular groups and some that deny access—especially if users or computers belong to groups that have both been granted and denied access (the Deny ACE will always take precedence over an Allow ACE). In the case of security group filtering, keeping it simple is a good rule to follow.
Q 2.3: What is the purpose of No Override and Block Inheritance?
A:
No Override and Block Inheritance are two Group Policy Object (GPO) features that let you control how Group Policy propagates throughout Active Directory (AD). You can consider them opposing forces to each other.In a nutshell, No Override lets a Group Policy administrator ensure that his or her GPO is always processed by downstream users and computers. For example, if I define a GPO linked to a domain, I can use No Override to guarantee that that GPO is always processed by users and computers in that domain. However, if I’m an administrator of an organizational unit (OU), I might want to block upstream GPOs that have been linked to the domain or site of which my users are members, but which I don’t want my users and computers to receive. Such upstream blocking is accomplished by virtue of the Block Inheritance feature. However, No Override always “trumps” Block Inheritance. That is, if an administrator sets a No Override flag on a GPO higher up in the AD hierarchy (for example, at the site or domain level, or even at a higher-level OU in the case of nested OUs), no Block Inheritance will prevent downstream users and
computers from processing that GPO. Although this behavior might seem unfair, there are certain types of policy (for example, security) that you absolutely positively need to know that every user and computer that should receive the GPO is in fact receiving it. Using No Override achieves this goal.
No Override always “overrides” Block Inheritance. That is, no amount of inheritance blocking will protect you from a GPO that has No Override set.
you would want to block inheritance of upstream GPOs at your OU, rather than on a per-GPO basis. Likewise, a domain or site administrator might only want to selectively force a given GPO to be inherited using No Override.
A good example of when No Override comes in handy is for enforcing security policy. For example, a domain administrator may have some corporate security settings that all users and computers must receive. If the administrator enables No Override on this security GPO, all downstream users and computers will always process that GPO. The following steps walk you through how to enable No Override on a GPO:
1. Open the Active Directory Users and Computers (or AD Sites and Services for
site-linked GPOs) Microsoft Management Console (MMC) snap-in tool.
2. Right-click the container object (for example, site, domain, or OU) linked to the GPO that you want to enable with No Override.
3. From the context menu, choose Properties, then select the Group Policy tab.
4. You will see a dialog box similar to the one that Figure 2.6 shows.
Figure 2.6: Viewing Group Policies linked to a domain.
As I mentioned earlier, Block Inheritance is set at the container level. As you can see in Figure 2.6, there is a Block Policy inheritance check box at the bottom of the dialog box. By selecting this check box, you effectively form a wall (albeit a soft wall) that prevents upstream GPOs from being processed by your users and computers (unless those GPOs use No Override). Block Inheritance does not block GPOs linked to the container which you’re blocking, only upstream ones. For example, Figure 2.7 shows that Block Inheritance has been set on OU2.
Figure 2.7: AD domain showing the use of No Override and Block Inheritance.
Setting block inheritance on OU2 means that users and computers that reside in OU2 and OU5 will only process OU GPO2 and Domain GPO2 because Domain GPO2 has had the No Override
Q 2.4: How do site-linked Group Policy Objects (GPOs) work?
A:
Linking your Active Directory sites to your Group Policy Objects (GPOs) is an often over-looked feature within Group Policy that can provide some interesting benefits. As you know, you can link GPOs to domains, organizational units (OUs), and sites, but in my experience site-linked GPOs seem to be fairly rare. The reason for this rarity likely has to do with the purpose of sites in your AD infrastructure. A site is a collection of IP subnets that are typically connected by high-speed interconnects. For example, a set of subnets on a high-speed campus backbone would typically belong to the same AD site. Sites (and subnets) are managed using the AD Sites and Services Microsoft Management Console (MMC) snap-in (dssite.msc). Figure 2.8 shows the process of creating a subnet and associating it with a site.Figure 2.8: Adding a subnet to the SanFrancisco site using the AD Sites and Services MMC snap-in.
Sites are typically used to control replication between AD domain controllers as well as allow you to group workstations and servers together for the purpose of guaranteeing that services such as distributed file system (Dfs) and authentication are handled locally. But sites can also be the target of GPO linking. So why would you link a GPO to a site? When it is done, it’s done
because you want to provide some policy settings to your users and computers that are specific to their location on the network. The most common reason is to force the use of IP Security (IPSec) network-layer encryption if users are on a specific set of subnets. (For example, if your
executive’s computers are all located within a single site and you want to ensure that their traffic is encrypted.) Another use might be to deliver a particular set of policy lockdown if you have users dialing in and accessing your network via a Virtual Private Network (VPN). Those clients will typically get a range of IP addresses on one or more subnets that you can collect into a site and attach to a GPO.
