Windows 2000 Group Policy

realtimepublishers.com

tm

Tips and Tricks Guide To tm

Windows 2000 Group Policy Darren Mar-Elia

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 “realtime”—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! Sean Daily Series Editor

i

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 processing Group Policy Objects that are defined in my Active Directory infrastructure? ..........26 GPO Background ...............................................................................................................26

ii

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 Third-Party Tools...............................................................................................................78 Q 4.2: How many Group Policy Objects can I create in a domain before I start affecting the performance of my workstations?..................................................................................................78 Asynchronous vs. Synchronous Processing.......................................................................78 iii

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 a Group Policy Object is replicated to other domain controllers? ...............................................128 Q 6.6: Can I get information about the Group Policy Objects in my domain via scripts? ..........130 iv

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 controller is not found. DNS isn’t the problem, what else could it be?.......................................177 Q 8.8: I’m having problems with security policy processing. Is it possible to get more in-depth troubleshooting information than that provided by the event logs? ............................................179

v

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, noncommercial 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].

vi

Chapter 1

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.

Figure 1.1: Viewing the standard policy nodes in a Win2K GPO.

1

Chapter 1 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.

Figure 1.2: Viewing the use of AD security groups to filter the effects of a GPO.

2

Chapter 1 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.

Note that in Figure 1.3, multiple GPOs can be linked to each container object (for example, site, domain, or OU). The users and computers in the Sales OU, for example, would process GPOs linked directly to that OU as well as upstream GPOs linked to the domain and any AD sites to which the computers belong. In fact, GPO processing follows an order of precedence that helps control which GPOs are processed first. Namely, GPOs linked to sites are processed first, then 3

Chapter 1 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

highlighted so that you can change its name (as Figure 1.4 shows).

Figure 1.4: Adding a new GPO to your AD.

4

Chapter 1 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 placed into the registry and will be removed when the GPO no longer applies.

5

Chapter 1 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 User has a red icon associated with it.

6

Chapter 1

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.

7

Chapter 1 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).

Figure 1.7: Viewing the three states of an Administrative Template policy.

8

Chapter 1 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).

9

Chapter 1

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 editor tool. At the beginning of most Win2K and Windows XP .adm files, you will see a set of statements, an example of which Listing 1.3 shows.

10

Chapter 1 #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).

Figure 1.10: Viewing the use of the SUPPORTED tag in a Windows XP policy.

13

Chapter 1 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.

14

Chapter 1

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 two separate GPOs, then use security group filtering to control which user groups process them. The following steps describe the creation of the GPOs and how you set up security group filtering. I’m going to make the assumption that the GPOs are linked to an organizational unit (OU) called Finance, which contains the Finance Admins and Finance Users groups. 15

Chapter 1 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 processing.

16

Chapter 1

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.

Figure 1.15: Viewing the output of the list option of the gpolmig.exe utility.

17

Chapter 1 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 userspecific 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" {D5D096640319-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!

18

Chapter 1

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 computerspecific 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.

Figure 1.16: Viewing a mixed NT 4.0 and AD environment.

19

Chapter 1 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\\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 let you redirect certain folders within a user’s profile to a different location (for example, a server share). Figure 1.17 shows an example of this type of policy.

20

Chapter 1

Figure 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).

Figure 1.18: Viewing GPO-based folder-redirection policy.

In fact, if you’ve done a lot of policy setting in your NT 4.0 System Policies, you might find it downright frustrating trying to discover what happened to those policies as you migrate to GPOs. Table 1.1 shows some commonly used settings in NT 4.0 System Policy and the location of their equivalents in Win2K-based Group Policy. 21

Chapter 1 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 policy information 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).

Figure 1.19: Viewing the registry.pol file that is stored in a GPO’s GPT.

22

Chapter 1 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 files are stored in the replicated SYSVOL share on domain controllers within a domain. The Netlogon share is still supported on Win2K domain controllers, but it’s in a different part of SYSVOL from where your Group Policy Objects (GPOs) are stored.

23

Chapter 1 SYSVOL 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\\policies, whereas files that are shared as Netlogon are stored in SYSVOL\\scripts. Note that the path %systemroot%\SYSVOL\sysvol\ 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 behavior. Those values are:

24

Chapter 1 •

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.

25

Chapter 2

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 commandline 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 processing. It has no capability to report on remote machines. The Windows XP version offers this remote capability. And, while the Win2K version of GPResult can report on which registry values have been set through an administrative template policy, the Win2K version cannot report 26

Chapter 2 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-ofthe-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 want logging to occur: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics. Under the Diagnostics subkey, add a REG_DWORD value called RunDiagnosticLoggingGlobal, and give it a value of 0x1. You will need to reboot for the logging to take effect, but once it does, you will see a series of Application event log events each time GPO processing occurs. This logging is handy for telling you which GPOs are being 27

Chapter 2 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. 3. You are then led through a wizard that lets you choose the user and computer you want to

analyze. Once completed, current GPO settings will be displayed in the MMC in a familiar GPO editor-style tree with results showing which policy has been applied to your computer or user and which GPO the policy setting comes from. 28

Chapter 2

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.

Figure 2.3: Viewing the ACL for a GPO.

29

Chapter 2 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, rightclick 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.

30

Chapter 2

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.

Figure 2.5: Using a Deny ACE to prevent a group from processing a GPO.

31

Chapter 2 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.

No Override is set on a per-GPO basis, but Block Inheritance is set per-container object (for example, site, domain, or OU). This difference makes sense because, as an OU administrator, 32

Chapter 2 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.

5. Highlight the GPO that you want to enable for No Override, then click Options. 6. In the resulting dialog box, select the No Override check box, and click OK to confirm. 7. Repeat this process for each GPO you want to set to No Override.

33

Chapter 2 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 flag set, so it cannot be blocked. However, Block Inheritance does effectively block OU GPO1, Site GPO, Domain GPO1, and Domain GPO3.

34

Chapter 2

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 overlooked 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 sitelinked 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. The thing to remember about site-linked GPOs, unlike domain or OU-linked ones, is that the effect of site-linked GPOs crosses domain boundaries. That is, any computer that belongs to a site (and the user who logs onto that computer), regardless of which domain it’s in, will process the GPO. This action makes sense when you think about it because sites can contain users, computers, or domain controllers from multiple AD domains within a single forest. And,

35

Chapter 2 although domains and OUs are stored within the domain-naming context for a particular domain and thus are only replicated to domain controllers within that domain, site information is stored in the configuration naming context (see Figure 2.9), which is replicated to all domain controllers in a forest regardless of domain membership.

Figure 2.9: Using the ADSI Edit MMC tool to view sites within the configuration naming context in AD.

Remember that GPOs are processed using the order local, site, domain and finally, OU. Thus, after the local GPO is processed, any site-linked GPOs are processed first, before those that are domain and OU-linked. Thus, if any GPOs processed after your site-linked ones contradict any site-specific policy settings, those site-specific settings will be cancelled out by the time the computer or user processes all their GPOs. Site-linked GPOs in this case are “low man on the totem pole” and so you need to make sure you design them with that fact in mind. You can use the No Override feature in Group Policy (see Figure 2.10) to ensure that a particular site-linked GPO is always processed and can’t be overridden by “downstream” GPOs, but, because sitelinked GPOs are the first in line, you can’t use the Block Policy Inheritance feature to ensure that upstream GPOs don’t take precedence (because there aren’t any upstream GPOs to those that are site-linked).

36

Chapter 2

Figure 2.10: Viewing the use of No Override on a site-linked GPO.

One final thing to know about site-linked GPOs—I mentioned that sites are actually stored within the configuration naming context and thus replicated to every domain controller in a forest. However, the Group Policy Template (GPT) portion of a GPO is still stored within SYSVOL on domain controllers within a single domain. If you create a site-linked GPO using the AD Sites and Services tool, by default, the GPT for that GPO is created in the forest root domain—the first domain in a forest. However, if you create a domain or OU-linked GPO in another domain other than the forest root, then link that GPO to a site at a later time, the GPT exists in whatever domain it was first created in. The reason that this fact is important is that you need to have a good sense of where all your site-linked GPOs actually reside as compared with your users. You don’t want users or computers having to cross slow WAN links just to find the GPOs that they need to process, so you might find that you need to keep some domain controllers from the domain where your site-linked GPOs are stored at locations close to your users to ensure good performance.

37

Chapter 2

Q 2.5: Why are changes to Group Policy Objects always written first to the PDC emulator in Active Directory? A: Because it is possible for two people, working in different geographic regions, to write changes to a single Group Policy Object (GPO) from two different domain controllers, Microsoft sought to provide a way to minimize collisions. By default, when you open the Microsoft Management Console (MMC) Group Policy snap-in focused on an Active Directory (AD)-based GPO, the copy of the GPO you are actually editing resides on the PDC emulator domain controller in your AD domain. The reason is that the GPO editor tool will always try to edit the copy of a GPO on the PDC emulator for that domain to limit collisions between two people editing the same GPO. For example, if a systems administrator in New York and a systems administrator in San Francisco both try to edit the Default Domain Policy at the same time, they will both be focused on the PDC emulator domain controller to make the change. In that case, the first user to edit the GPO will put a “lock” on that GPO. When the second user attempts to edit that same GPO, the user will get an error message similar to the one that Figure 2.11 shows.

Figure 2.11: Viewing the error received when two people try to edit the same GPO at the same time.

This setup is a good thing because it ensures that two people editing the same GPO can’t overwrite each other’s changes, which is especially important if the changes being edited are security policies. You can actually see which domain controller you are currently focused on while editing a GPO from the MMC Group Policy snap-in tool. The current domain controller will appear in brackets to the right of the GPO name in the left pane of the tool (see Figure 2.12).

38

Chapter 2

Figure 2.12: Viewing the currently focused domain controller (yquem.mar-elia.com) while editing a GPO.

However, there may be circumstances in which you want to override this behavior and edit a GPO while focused on a different AD domain controller. In such a case, you change which domain controller the Group Policy MMC tool focuses on when you edit GPOs by choosing View, Domain Controller Options from the MMC menu. Figure 2.13 shows the list of your options.

Figure 2.13: Viewing the options for focusing editing of GPOs.

As you can see in Figure 2.13, the default choice is to connect to the PDC emulator. However, you can choose the second option, which will connect to whichever domain controller your Active Directory Users and Computers or AD Sites and Services MMC tools are currently focused on. Typically, when you open these tools, they connect to the closest domain controller to you, which is normally a domain controller within the same AD site as your administrative workstation. If you select the third choice, the next time you open the Group Policy MMC snapin, the tool will randomly select a domain controller to connect to within the same site from which you’re connecting.

39

Chapter 2

When you choose any of these three options, you need to stop and restart your Group Policy tool for the changes to take effect. In addition, the changes are in effect only for the Group Policy MMC snapin on the machine on which you make the change. The choice does not follow your user ID to another machine unless you have a Group Policy Administrative Template policy in place to enforce the choice across a group of users or machines.

A good practice is to not mess with this setting unless you have a really good reason. One good reason for focusing a GPO editor on a different domain controller is if the PDC emulator domain controller is currently down or unavailable and you need to make quick changes to a GPO. You can easily determine which domain controller in your AD domain currently holds the PDC emulator role by using the netdom.exe utility that comes with the Windows 2000 (Win2K) Support Tools. To use netdom.exe to determine the current PDC emulator, type: Netdom query fsmo Where fsmo is the acronym for floating single master operation—the original name for the operations masters roles. When you type this command, the utility will return all five role holders within your current domain and forest: Schema owner Domain role owner PDC role

yquem.mar-elia.com yquem.mar-elia.com yquem.mar-elia.com

RID pool manager

yquem.mar-elia.com

Infrastructure owner

yquem.mar-elia.com

The command completed successfully. In this case, all five roles are held by one domain controller, which is generally not a good thing!

Q 2.6: Can I permission a Group Policy Object such that someone can view its settings but not edit them? A: Strangely enough, there is no such thing as a read-only Group Policy Object (GPO). There is no way to give someone view-only permissions on a GPO. This limitation seems counterintuitive because we’ve seen throughout this book that GPOs are highly permissionable. However, you can’t grant an administrator read access to a GPO—the administrator won’t be able to access that GPO. For example, if I want a member of the Finance Admins group to be able to view but not change GPOs that have been linked to the Finance OU, I might try setting the GPO’s permissions as the window in Figure 2.14 shows.

40

Chapter 2

Figure 2.14: Viewing read permissions on a GPO.

However, the permissions as shown in the figure will result in an access denied error when a member of the Finance Admins group tries to load the GPO into a Microsoft Management Console (MMC) snap-in tool. At minimum, a user needs the Read and Write permissions to be able to view a GPO. And, once the Write permission is granted, the user can then edit that GPO. The one ability that the user doesn’t have with only Read and Write permissions is to change the permissions on the GPO. This level of control over a GPO requires the Full Control permission. If you really need to be able to give users read-only views of your GPOs, your best bet is to give them indirect access by creating reports that show the current settings for GPOs. There are quick and dirty ways that you can do so by using tools such as GPResult.exe, which only shows the current settings in text form that apply to a particular user or computer. Or you can let your users use the Resultant Set of Policy (RSoP) tool that comes with Windows XP to generate a report of GPO settings that they’re receiving on their workstations. (Figure 2.15 shows an example of a Windows XP-based RSoP report.) Users that have only read permissions on a GPO can run the RSoP tool to access information about the resulting policies that are being processed.

41

Chapter 2

Figure 2.15: Viewing the output of the Windows XP RSoP tool.

If you really want to give your administrators read-only access to all policy settings on a given set of GPOs, you have another option, albeit not out-of-the-box. Using a tool such as FullArmor’s FAZAM 2000, you can generate HTML reports of the current settings for a given GPO. One of the benefits of FAZAM’s reporting feature is that you can script report creation. Thus, you could very easily automate the generation of reports about your GPOs’ settings and have the reports automatically moved to a Web site that administrators and other users can access remotely. To accomplish this scripting, you need to write a fairly simple Windows Script Host (WSH) script from a Win2K or Windows XP system on which FAZAM 2000 is installed. FAZAM installs some COM automation objects that facilitate the calling of reports from WSH scripts. Listing 2.1 shows an example of a script that reads the settings from one of my GPOs and outputs the results to an HTML file within my IIS Web server directories (the numbers have been added to aid this discussion). 1. Set rptGPO= CreateObject("FAZAM2000.PolicyManager") 2. rptGPO.ReportPolicy "LDAP://CN={22684D8D-44D2-449C-9A60DE345A22BCB1},CN=Policies,CN=System,DC=marelia,DC=com","c:\inetpub\wwwroot\gpo\Finance Users Lockdown GPO.htm",1 3. set rptGPO=nothing Listing 2.1: A FAZAM 2000 script to automate reporting of GPO settings to an HTML file.

42

Chapter 2 In line 1 of the listing, I instantiate an object called rptGPO from the FAZAM COM automation object called FAZAM2000.PolicyManager. In line 2, I call a method called ReportPolicy, which does all the work in this script. ReportPolicy is passed three arguments, including the full Lightweight Directory Access Protocol (LDAP) path (referred to by globally unique ID—GUID) to the GPO I want to report on (in the example, LDAP://CN={22684D8D-44D2-449C-9A60DE345A22BCB1},CN=Policies,CN=System,DC=mar-elia,DC=com), the path to the output file (in the example, c:\inetpub\wwwroot\gpo\Finance Users Lockdown GPO.htm), and the type of report to generate—a numeric 1 indicates an HTML report, 2 indicates output to an MS-Access database, and 3 indicates output to the printer. The output of this example script is an HTML report—part of which is shown in Figure 2.16. Line 3 simply releases the reference to the rptGPO object.

Figure 2.16: Viewing the HTML output of GPO settings using a FAZAM 2000 report script.

This scripting mechanism is a handy way to generate automated, read-only reports about your GPOs for everyone to see, without granting them editing rights on your GPOs.

43

Chapter 2

Q 2.7: Is the Group Policy Object architecture extensible—can I create new types of Group Policy Objects? A: Yes, Microsoft designed Group Policy to be extensible, which means that a developer can add policy functionality to a Group Policy Object (GPO). If you think about the way GPOs work, their extensibility seems natural. GPOs store their settings in Active Directory (AD—the Group Policy Container—GPC) and SYSVOL (the Group Policy Template—GPT). There is nothing special to these settings; they are just AD objects with attributes or files and folders in the file system. They have meaning to a particular GPO policy function (for example, folder redirection, administrative templates) but otherwise these settings are nothing special. The actual work of policy processing is done by so-called client-side extensions. CSEs are simply DLLs that are installed on the Windows 2000 (Win2K) or Windows XP workstation or server. These DLLs do the actual heavy lifting of policy enforcement. It is the CSE that cares about what is stored in the GPT and GPC, and it is the CSE that can be extended to add new policy processing functionality. Microsoft has written several canned CSEs that ship with Win2K and Windows XP. In addition, the APIs for writing custom CSEs that extend GPO functionality are published on Microsoft’s Web site (http://www.microsoft.com). You will have to know C++ to develop new CSEs, but it is highly do-able! The general idea is that you build a new client-side DLL that looks at a particular location within either the GPC (if the settings are AD-based) or the GPT (if the settings are SYSVOL based). For example, let’s suppose you wanted to develop a CSE that controls the behavior of an inhouse application that you have developed for your business. The CSE might read a settings file from SYSVOL, then, based on the contents of that file, decide on certain behavior for your application (for example, whether to show the user certain parts of the application based on policy settings or something similar). That is the underlying flow of how a custom GPO extension would work. You can, of course, do almost anything with policy extensions. However, you must keep in mind that if you decide to develop a custom CSE, you will also need to develop a Microsoft Management Console (MMC) snap-in or other type of user interface that lets administrators set the policy for the CSE that you’ve created. For example, out-of-the box, Microsoft not only provides a CSE for folder redirection policy but also an MMC snap-in extension that lets administrators actually set the policy for a given GPO. MMC snap-ins and extensions are registered on a given Win2K or Windows XP machine under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns. Each snap-in is registered with its unique GUID under that key. As Figure 2.17 shows, the folder redirection editing snap-in is registered under that key and is implemented within the DLL called fde.dll.

44

Chapter 2

Figure 2.17: Viewing the registered MMC snap-in for folder redirection policy.

So, for you to implement your own custom CSE, you will also need to implement a companion editor tool that lets administrators create and edit the settings for your policy.

Q 2.8: What is happening during background refresh of a Group Policy Object and how do I change background refresh behavior? A: Group Policy Objects (GPOs) are refreshed in the background every 5 minutes on Windows 2000 (Win2K) domain controllers and every 90 minutes on Win2K and Windows XP workstations and Win2K servers. This cycle provides ongoing policy enforcement in the event that a GPO’s policy settings change between normal processing cycles (machine restart or user logon) or users manage to undo policies that they have received. But what is actually going on during such a policy processing cycle? In fact, background processing performs the very same operations that go on when a user boots his or her computer or logs onto Active Directory (AD). In the background, when each refresh interval arrives (plus a randomized interval to ensure that all machines don’t process their GPOs at the same time), the client-side extensions (CSEs) for each policy area fire up and query AD to find out which GPOs apply to the current user and computer. Then, as each GPO is processed, the CSEs compare the GPO history information (described in Question 7.7) held in the registry with the current versions of the GPOs to be processed. If the GPO has not changed since the last processing cycle and you haven’t set administrative template policy to force the computer or user to process the policy that the CSE implements regardless of whether it has changed, then the CSE will skip processing of that GPO.

45

Chapter 2 You can modify the default behavior of a CSE during regular and background refresh of policy by setting administrative template policy for the machines whose behavior you want to modify. The settings that control background refresh behavior for all of the default Win2K and Windows XP CSEs are stored in Computer Configuration, Administrative Templates, System, Group Policy. Remember that policy processing is performed by the CSE. That is, one CSE will process all of the GPOs that implement its policy (for example, folder redirection or administrative templates), and then the next CSE does the same, and so on. So during the refresh cycle, some CSEs might process many GPOs and some might not process any. You can change the default background refresh interval for domain controllers, workstations, and servers from the default setting. Keep in mind that the refresh interval on domain controllers is set to 5 minutes to ensure that there is minimal latency in the updating of important policy such as security. It’s important to keep this behavior in mind if you lengthen the background processing interval for the security CSE. To change the background refresh intervals, create a GPO that will apply to all machines that you want to have a different background processing policy. You can do so by drilling into the computer-specific Administrative Template policy, and setting either Group Policy refresh interval for computers or Group Policy refresh interval for domain controllers (see Figure 2.18). These policies are the same policy in both Win2K and Windows XP.

Figure 2.18: Viewing the Administrative Template policy to change the background refresh interval on domain controllers.

46

Chapter 2 As Figure 2.18 shows, you can also set a random time value in addition to the base refresh interval. As I mentioned, the random time guarantees that not all machines within a particular domain end up requesting policy at the same time. If you enter a value in minutes, the actual random time will be any value up to the number of minutes you select. So if you select a 5minute refresh time and a 5-minute randomization, the actual time between policy refreshes could be anywhere from 5 to 10 minutes. Now let’s look at how you can change the background refresh behavior for a given CSE. As I mentioned, normal GPO processing behavior is for CSEs to not process a GPO if it has not changed since the last refresh period. In most cases, you can override this behavior to force a CSE to process regardless of whether the GPO has changed. However, it’s important to remember that not all CSEs support background refresh of policy. Table 2.1 shows which of the most common CSEs support it and which don’t. CSE

Background Processing Support

Administrative Templates (that is, registry policy)

Yes

Folder Redirection

No

Internet Explorer Maintenance

No

EFS Recovery

Yes

Scripts

No

Security

Yes

Software Installation

No

Table 2.1: Viewing which CSEs support background GPO processing.

As you can see from the table, there are only a few CSEs that actually support background processing. You can adjust which CSEs are enabled for background processing by using Administrative Template policy in Computer Configuration, Administrative Templates, System, Group Policy (see Figure 2.19).

47

Chapter 2

Figure 2.19: Viewing the option to disable or enable background processing of a CSE.

It’s important to note, however, that even though some CSEs, such as the Scripts CSE in Figure 2.19, show the option to enable or disable background processing, the CSE itself does not support background processing. Your best bet is to refer to Table 2.1 to ensure that those CSEs that you want to process in the background are actually able to do so.

48

Chapter 3

Chapter 3: Creating and Editing GPOs Q 3.1: How can I create a Group Policy Object that is not linked to a container object? A: Normally, when you create a new Group Policy Object (GPO), you are focused on a particular container object in Active Directory (AD—for example, a site, domain, or organizational unit—OU). Thus, when you create the GPO, it is automatically linked to that container object at creation time. This link might not be desirable, so I’ll show you a way to create in AD a new GPO that isn’t linked to a site, domain, or OU. The normal process for creating a GPO is as follows: 1. Start the Microsoft Management Console (MMC) Active Directory Users and Computers

snap-in or Sites and Services snap-in, and highlight the container object on which you want to create the new GPO. 2. Right-click that container object, select Properties, and in the resulting window, select the

Group Policy tab. 3. Click New, and name your new GPO.

Once you click New, the Group Policy Container (GPC) and Group Policy Template (GPT) that make up the GPO are created. In addition, an attribute on that container object called gpLink is modified to add the globally unique ID (GUID) for that GPO to its list. Once the GPO is linked, it is “live” on your AD infrastructure. When you create a GPO normally, it is automatically linked to a site, domain, or OU and is “live” as soon as you create it. This process can lead to problems with controlling the use of the GPO prior to fully editing it. Consider creating the GPO without linking it to a container first.

That is, any changes you make to your new GPO are instantly available for processing by computers and users on your network. This availability makes staging of new GPOs problematic—you may want to choose the time when your new GPO is active in production. It is useful to be able to create a new GPO, edit it the way you want, then link it to one or more container objects when you’re ready. There are a number of similar approaches you can use to create an unlinked GPO. The following steps show one of those approaches to create a new, unlinked GPO in AD. 1. From the Start menu, select Run, then type mmc.exe in the text box to start a blank

Microsoft Management Console (MMC) console. 2. From the MMC Console menu, select Add/Remove Snap-in, and on the Standalone tab,

click Add. 3. From the list of available standalone snap-ins, navigate to Group Policy, and click Add. 4. On the Select Group Policy Object dialog box, click Browse to browse available GPOs in

your AD domain.

49

Chapter 3 5. Select the All tab to view all current GPOs. Then, with your mouse in a white space

within the All GPO dialog box, right-click, and select New from the properties menu, as Figure 3.1 shows.

Figure 3.1: Creating a new, unlinked GPO in AD.

6. Once you’ve created the new GPO and renamed it, you will now have a GPO that is not

linked to any particular container object. To edit this new, unlinked GPO, you will need to load the Group Policy MMC snap-in as you did in the previous steps, navigate to the All tab, right-click the unlinked GPO, and select Edit from the context menu. Let’s now assume that you’ve edited the new, unlinked GPO, and you want to link it to an OU called HQ in your AD domain. Follow these steps to give the GPO a home: 1. Start the Active Directory Users and Computers MMC snap-in. Right-click the OU (or

another container object) that you want to link to the GPO. 2. Choose Properties from the context menu, then select the Group Policy tab. 3. Click Add to link the new GPO to this OU. From the Add a Group Policy Object Link

dialog box, select the All tab to find your newly created, unlinked GPO. 4. Highlight the GPO, and click OK to complete the linking process, as Figure 3.2

illustrates.

50

Chapter 3

Figure 3.2: Linking a GPO to an AD container object.

Once you’ve completed the linking process, the GPO is now “live” on your AD network and can be processed by users and computers.

Q 3.2: How can I set account policy on a domain? A: In Windows NT 4.0, setting the account policy on a domain had absolutely nothing to do with System Policy. Rather, you used the User Manager for Domains tool to create and edit account policies, such as required password length and account lockout counts. However, in Active Directory (AD) domains, you must use Group Policy to set account policy on a domain. In fact, the domain’s account policy must be set at a Group Policy Object (GPO) linked at the domain level only. It cannot be set on a GPO linked at either site or organizational unit (OU) levels (though you can set account policy for local workstations and servers at the OU or site level). By default, when you install AD, it installs a GPO called the Default Domain Policy, as Figure 3.3 shows.

51

Chapter 3

Figure 3.3: Viewing the Default Domain Policy GPO created when you install AD.

This Default Domain Policy GPO is the ideal place to create your account policy, as it is a special GPO. This GPO is special because it can’t be deleted—even if you accidentally try to delete this GPO, your command is ignored and the GPO remains. Thus, you know that the account policy defined in this GPO is always available and enforced. Of course, you can also create your own domain-linked GPO to define account policy. The important thing to know about account policy in AD is that it can apply to domain controllers as well as member servers and workstations. Thus, if you set a minimum password length policy on a domain-linked GPO that is processed by both AD domain controllers and member servers or workstations, you will be required to use that minimum password length regardless of whether you are logging onto the domain (handled by the domain controller) or logging on to a local workstation or server. This behavior is important because it means that if you want to have two separate account policies—one for domain controllers (that is, for domain authentication) and one for local workstation or server accounts, you would need to define two separate, domain-linked GPOs, then use security group filtering to control which set of machines processes which account policy.

52

Chapter 3 To illustrate how you can create a domain account policy, let’s walk through the process of defining minimum password length and password age on an AD domain. 1. The first step is to open the Active Directory Users and Computers Microsoft

Management Console (MMC) snap-in tool, focused on your AD domain. 2. Right-click the domain name within the left-hand scope pane of the tool, and choose the

Properties context menu. 3. Select the Group Policy tab, and you see a dialog box showing all the GPOs currently

linked at the domain level of your domain. At the very least, you should see the Default Domain Policy GPO described earlier. Let’s use that GPO for our example. 4. Highlight the Default Domain Policy, and click Edit to start the Group Policy editor tool,

focused on the GPO. 5. Next, expand the Computer Configuration node within the left-hand scope pane of the

Group Policy tool, and drill into Windows Settings, Security Settings, Account Policies, Password Policies. 6. After you’ve highlighted the Password Policies node, you should see the dialog box that

Figure 3.4 shows.

Figure 3.4: Viewing Account Policy settings within a GPO.

7. To set the password length, we need to double-click the Minimum Password Length

policy item in the right-hand results pane, and set the value to the minimum number of characters required for a password. 8. To set the password age, we need to double-click the Maximum Password Age policy

item, and set it to the number of days after which the password is considered expired. 53

Chapter 3 Once you’ve set the policy within the GPO, the new account policy will go into effect on the domain the next time an AD domain controller processes the GPO, which is typically every 5 minutes during the background GPO refresh cycle. That’s all there is to setting account policy in an AD domain!

Q 3.3: How do I use the restricted groups feature in Group Policy Object security policy? A: Restricted groups are part of Group Policy Object (GPO) security policy and let you control membership in groups on workstations and servers in your Active Directory (AD) infrastructure. The goal of the restricted groups feature is to give you the ability to control group membership on machines managed by GPO such that, if a user tries to put his or herself into a group in which the user doesn’t belong, at the next policy processing cycle, the restricted Group Policy will automatically remove the user. This feature can be handy, but there are some limitations within the restricted group feature. Before we discuss these limitations, let’s look at how you can set restricted Group Policy. As I mentioned, restricted Group Policy is part of computer-specific security policy. You can find it within a GPO under Computer Configuration, Windows Settings, Security Settings, Restricted Groups, as Figure 3.5 shows.

Figure 3.5: Viewing restricted Group Policy within a GPO.

54

Chapter 3 Let’s create a new restricted Group Policy that controls the membership of an administrative group. If you want to add a new restricted Group Policy, right-click the Restricted Groups node, and select Add Group. The group that you select here is the group that you want to manage via Restricted Groups—the target group. With restricted Group Policy, you can do two things with the group you choose here. You can set which users or groups are allowed to be a member of this group. And you can choose which groups you want this chosen group to be a member. After I select the group in the Add Group dialog box, the new group is added to the right-hand results pane that Figure 3.5 shows. The next step is to define the actual policy. To do so, right-click the selected group, and choose Security. You will then see a dialog box like that shown in Figure 3.6.

Figure 3.6: Viewing the dialog box for setting restricted Group Policy.

This dialog box lets you perform the two operations I mentioned earlier. The Members of this group section says, in effect, the users and groups I choose here are the only users and groups that can be placed in this target group. For example, suppose I have a domain local group called MyAdmins. On a GPO that is processed by the domain controller, I create a restricted Group Policy that says that only the Finance Admins group can be a member of MyAdmins. This policy means that when the domain controllers process this GPO, if there are any users or groups that are currently a member of MyAdmins, they will be removed, and the Finance Admins group will be put in their place! As you can imagine, this policy is powerful and has much potential for damage. For example, suppose you define a restricted Group Policy that was processed by the domain controllers in your domain that says that the domain local Administrators group will only contain the Finance Admins group. When the domain controllers in your domain process that policy, all

55

Chapter 3 of the existing members of the domain local Administrators group—including the domain administrator account, domain admins, and enterprise admins—will be removed and replaced by Finance Admins! As you can imagine, this functionality could cause problems. The second feature within restricted Group Policy is less powerful. The This group is a member of section says that you always want the target group to be a member of a chosen list of groups. For example, if we reverse the earlier scenario, suppose I want the Finance Admins group to always be a member of the MyAdmins group, but I don’t want to affect the current members of MyAdmins. If I choose the Finance Admins group as the target for my restricted Group Policy, then add MyAdmins to the This group is a member of list, the next time the domain controller processes the GPO, Finance Admins will be added to the MyAdmins group, and any other groups or users in MyAdmins will remain intact. Figure 3.7 shows what this policy would look like.

Figure 3.7: Using restricted groups to make sure one group is always a member of another.

Keep in mind that you can use restricted Group Policy to control membership in domain groups as well as groups on workstations and servers. If you’re trying to control domain group membership, you need to define the policy on a GPO that is processed by your AD domain controllers (the easiest thing to do here is to link the GPO to the Domain Controllers OU). If you want to control workstation or member server local group membership, you’ll need to do so on a GPO linked to a container that includes those workstations and member servers. If a machine processes a restricted Group Policy for a group that it does not know about (for example, a domain controller processes a policy for a local group defined on a member server elsewhere in the domain), that policy is simply ignored. Another thing to keep in mind with restricted Group Policy is that it is processed just like other GPO-based security policy. Domain controllers, workstations, and member servers will process 56

Chapter 3 the policy on system startup, and domain controllers process security policy in the background every 5 minutes (workstations and servers do background processing every 90 minutes). However, keep in mind the following scenario: You set up a restricted Group Policy that makes the group Finance Admins a member of the domain local Administrators group. The policy is processed by the domain controllers and Finance Admins is added to the domain local Administrators group. Then, a domain admin comes around, wonders why Finance Admins is in the domain local Administrators group, and removes it. You would expect that, during the GPO processing cycle, the restricted Group Policy would again add the Finance Admins group to the domain local Administrators group. However, by default, such is not the case because, by default, GPOs whose version numbers have not changed since the last processing cycle will not be processed. Thus, only if a change is made to the GPO will that restricted Group Policy be reenforced. There is one way, however, to force security policy to be refreshed during every processing cycle regardless of whether the GPO has changed. You can set an Administrative Template policy to force this processing behavior. That Administrative Template policy is found in Computer Configuration, Administrative Templates, System, Group Policy , Security policy processing under both Windows XP and Windows 2000 (Win2K). Figure 3.8 shows how you set this policy to force background refresh regardless of whether the GPO has changed.

Figure 3.8: Setting Administrative Template policy to force background security policy to refresh.

After you’ve made the change to this Administrative Template policy, any inadvertent changes to restricted Group Policy will be automatically undone each time the GPO is reprocessed regardless of whether it changes. This Administrative Template policy is probably a good one to use for security policy processing in general because you typically want to make sure it’s as upto-date as possible.

57

Chapter 3

Q 3.4: How do I use Administrative Templates policy to lockdown my desktops? A: Just as in Windows NT 4.0 system policy, you can easily use Administrative Template policy within your Group Policy Objects (GPOs) to restrict certain aspects of the user’s desktop. In fact Windows 2000 (Win2K) and Windows XP GPOs provide so many different desktop control policies, that it’s hard to keep them all straight. But before I show you how you can use these policies to support desktop lockdown, I want to explain exactly what desktop lockdown provides. Since Windows 95, desktop lockdown through policy was a way for enterprise administrators to restrict which knobs and dials within Windows a user can futz with. The thought was that the fewer buttons the user could press, so to speak, the less chance there was that the user would do something that would require a call to a Help desk or visit from a support person. Thus, Microsoft provided desktop lockdown policies as a way of hiding various elements of the Windows shell environment. It’s important to note that desktop lockdown, for the most part, is just obfuscation. It is not real system security and cannot substitute for real system security. For example, a common desktop lockdown policy lets you hide the drives that a user can see within the My Computer dialog box. The industrious user can still access those drives using any number of methods outside of My Computer. On the contrary, if you used NTFS security to lockdown which files and directories to which a user has access, you are providing real security rather than simply hiding access to the drive via the most common mechanism. Such is true for most all of the desktop lockdown policies that are available in Administrative Templates. Some of the policies require a little more work to get around, but the bottom line is that you shouldn’t rely on them to keep your users (and especially your power users) from sensitive material. Now that we know desktop lockdown’s limitations, let’s look at how you can use the feature to restrict your users’ desktops. There is no one category that corresponds to desktop lockdown within Administrative Template policy. In general, any policy settings that restrict users from performing some task on their desktops that they would normally be able to do qualify as desktop lockdown. Administrative Template settings are broken down into policies and preferences (see the description of the two in Question 1.2). Desktop lockdown policy may be either policies or preferences, but are generally implemented by Microsoft as policies to prevent them from tattooing the registry if the policy no longer applies. In Windows XP, most of the common user-specific desktop lockdown settings can be found in User Configuration, Administrative Templates, Windows Components, Windows Explorer (see Figure 3.9) and User Configuration, Administrative Templates, Desktop.

58

Chapter 3

Figure 3.9: Viewing the desktop lockdown policies in Windows XP.

The process for enabling desktop lockdown is really quite simple, but the number of “knobs and switches” you can throw can be daunting. As you can see in Figure 3.9, there are a myriad of aspects of the user shell that you can control. Remember that Administrative Template policy settings have three options—Not Configured, Enabled, and Disabled. Not configured means just that—the policy setting is left unset. The meanings of Enabled and Disabled can be confusing because their effects vary depending upon the policy. For example, in Figure 3.9, the policy item called Remove DFS tab lets you remove the Dfs option from wherever they appear in the Windows Explorer. To enable this policy, you simply select the policy item and select the Enabled check box. If you disable this policy, it means that the Dfs tab can’t be removed from the Windows Explorer shell (not that anyone would actually try). However, it gets tricky when you try to apply this rule to policies that are worded “negatively.” For example, what happens when you enable the Do not request alternate credentials policy? Enabling this policy means that the alternative credentials prompt isn’t presented to a user when the user doesn’t have sufficient rights to install software on his or her computer. Clear?! So disabling this policy means that the user is always presented with the alternative credentials prompt when the user doesn’t have sufficient rights to install software. It can get very confusing very quickly. Darren’s Desktop Lockdown Rules As I mentioned, there are a myriad of desktop lockdown options available in Group Policy— almost too many if you ask me. With such in mind and based on experience deploying desktop lockdown in the NT 4.0 and Win2K environments, I’ve created a few rules to help guide your use of desktop lockdown. These are good rules to follow if you’re just starting out with Group Policy–based lockdown or if you are trying to unravel lockdown gone awry. 59

Chapter 3 1. Stick to the minimum amount of desktop lockdown you need to keep your users from

futzing. Less is more in this case. You don’t want to spend as much time troubleshooting and answering user calls as to why they can’t do something that’s been locked down as you would deal with the results of their futzing. If you think you need to lock something down, think again. 2. As a corollary to Rule 1, the best defense against user futzing is to use real security (that

is, file system and registry security) to protect desktop resources. No amount of desktop lockdown policy is going to help you if you make all yours users Administrators on their desktops. 3. Avoid having desktop lockdown policy in multiple GPOs that contradict each other as

they are applied to users. For example, if you have a GPO linked to the domain that removes the Run option from the Start menu and another GPO linked to an OU that puts it back for only certain users, you will have a very difficult time troubleshooting— especially if you’ve configured this setup for 40 or 50 policy items. If you choose to take this path, make sure you have a very good Resultant Set of Policy (RSoP) tool (for example, FullArmor’s FAZAM or the RSoP tools built into Windows XP) at your disposal. 4. As a corollary to Rule 3, if you have contradicting policies linked to different levels of

your infrastructure, try to avoid further complicating things by then using security groups to filter the effects of those GPOs. 5. In the end, what you will likely find is that you’ve overly restricted what your users can

do. However, it may be easier to ease restrictions over time than to increase them. The best solution is to choose a set of lockdowns that gives you the protection you need for your environment, and no more. Then put it in front of your users and get their acceptance on what you’ve done. User acceptance testing of your desktops cannot be underrated!

Q 3.5: How can I distribute Group Policy Object changes in a nonActive Directory environment? A: Ordinarily, changes to Group Policy Objects (GPOs) rely on an Active Directory (AD) infrastructure to propagate to and policy all users and machines in a domain or forest. However, there is some allowance for manually distributing some GPO policy to non-AD domain-based machines. As you know, every Windows 2000 (Win2K) and Windows XP system has a local GPO that contains a subset of the policy settings and capabilities available on AD-based GPOs; however, software installation and folder redirection are not supported in local GPOs. Notwithstanding these missing pieces, local Group Policy has many of the important features you might want or need on non–AD–based machines (for example, security and administrative templates). There might also be compelling reasons why you don’t want to put a particular Win2K or Windows XP machine in an AD domain. For example, many enterprises often opt not to create a domain when they place Win2K servers on DMZ segments exposed to the Internet. In such cases, you can choose not to deploy AD, but you might still want to leverage Group Policy to configure a group of machines. So what can you do? The solution is actually quite simple—you can copy the

60

Chapter 3 contents of a local GPO between machines to ensure that policy changes are deployed consistently across many non–AD–based machines. First, you need to know where the policy files for the local GPO are stored. On both Win2K and Windows XP systems, the local GPO can be found in %systemroot%\system32\GroupPolicy. As you can see in Figure 3.10, the contents of the local GPO look very similar to what you find in the Group Policy Template (GPT) portion of an AD-based GPO. (In Windows Explorer, the %systemroot%\system32\Group Policy folder is hidden by default. Make sure you enable the option to view hidden files and folders to see this folder.).

Figure 3.10: Viewing the contents of a local GPO on a Windows XP workstation.

As Figure 3.10 shows, the local GPO contains three folders and a file. The gpt.ini file holds the current version information for the local GPO. The Adm folder holds the .adm template files in use for this GPO. The Machine and User folders contain the current policy settings for this local GPO for the computer and user configuration portions of the GPO. If you drill into both the Machine and User folders, you will find the registry.pol file that contains the current Administrative Template settings as well as other folders for startup and shutdown or logon and logoff scripts and Internet Explorer (IE) maintenance and remote installation options. What you won’t find is a file corresponding to per-machine security settings such as account policy, local user rights, or password lockout. The reason is that, unlike Administrative Template policy, which is stored in the registry.pol file, changes to local GPO security settings are made against the live Security Account Manager (SAM) database that resides on the machine. Therefore, as we discuss how to copy local GPO settings from one machine to another, you won’t be able to copy security settings across machines using the same mechanism. Indeed, the only way to “copy” security settings across machines in a non-AD environment is to use a mechanism such as the Microsoft Management Console (MMC)-based Security Configuration and Analysis tool, or its companion command-line version—the secedit.exe utility. For our example, let’s suppose you want to copy Administrative Template policy settings to a group of non-AD machines. The process is fairly straightforward. First, you need to ensure that you have the Administrative Template settings that you desire on your “prototype” machine. The easiest and quickest way to edit the local GPO is to type gpedit.msc from the Start menu Run text box. Doing so will bring up an MMC tool focused on the local GPO.

61

Chapter 3 Next, you’ll need to edit the Administrative Template policy as you want it to appear on all machines. Make note as to whether you’re editing computer-specific policy, user-specific policy, or both. After you finish editing the policies, you’re ready to copy your prototype settings to the destination machines. If you edited computer-specific policy only, you will need to copy only the registry.pol file from %systemroot%\system32\GroupPolicy\machine. If you also edited the userspecific policy or only edited the user-specific policy, you’ll need to copy registry.pol from %systemroot%\system32\GroupPolicy\user. In either case, copy the required registry.pol file from the folders on your source machine to the identical folders on all target machines. Any existing Administrative Template policy set locally on the target machines will be overwritten when you copy the new files. If you created any custom .adm template files on your source machine, you’ll need to copy them to the target computer(s) in addition to copying the registry.pol files. This step is important to remember because after you’ve copied the policy files to the target machines, if anyone were to edit those local GPOs, they would not see all the correct policy settings if the adm files that were used to create the source GPO are missing. Copy any custom .adm files from %systemroot%\system32\GroupPolicy\adm to the same folder on the target machine. Then, when an administrator edits the local GPO on the target machines, the administrator will need to ensure that the custom .adm file is loaded. There is one more piece of the puzzle that needs to be completed before your copied policy is functional. Local GPOs keep version information about themselves just as AD-based GPOs do. This information is kept in the gpt.ini file in the root of the local GPO folder. If the version number held in this file (shown as Version in Listing 3.1) is 0, local GPO processing will be skipped during machine startup or user logon. Such is typically the case on new Win2K and Windows XP machines. [General] gPCFunctionalityVersion=2 gPCMachineExtensionNames=[{35378EAC-683F-11D2-A89A00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{53D6AB1D-2488-11D1A28C-00C04FB94F17}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1D2488-11D1-A28C-00C04FB94F17}] Version=196639 gPCUserExtensionNames=[{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE7020-11D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{A2E30F80-D7DE11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}] Listing 3.1: Viewing the contents of a local GPO’s gpt.ini file.

In Listing 3.1, the version number shown is 196639. When you’re copying local registry.pol files to target machines, you also need to edit the gpt.ini file on those machines to ensure that the value is not 0. Although GPOs use a fairly elaborate scheme to calculate versions (the version number is incremented 1 for each computer-specific change and 65536 for each user-specific one), you don’t need to worry about whether you provide the correct version number as long as it is a non-0 value. To be safe, set the version value to 65537 (65536+1) so that both user and computer sides of the GPO have changed. This setting will ensure that the local GPO is processed on the next cycle.

62

Chapter 3

Q 3.6: How do I use Internet Explorer Maintenance policy? A: Internet Explorer (IE) Maintenance policy provides similar functionality to the standalone IE Administration Kit (IEAK), and lets you enforce browser configurations and branding across your Windows 2000 (Win2K) or Windows XP desktops. IE Maintenance policy supports two modes of operation—maintenance and preference. Maintenance mode is meant to provide mandatory, non-changeable settings for various browser configuration options. If the user changes a maintenance-mode policy, that policy will be reset the next time the Group Policy Object (GPO) containing that policy is processed. Preference mode is less strict. It lets me deliver IE Maintenance policy settings one time to a user; after that initial setting, the policy is no longer enforced and the user may change settings as he or she sees fit. You must choose one mode. If preference mode is enabled for a given GPO, maintenance mode is not. Both IE maintenance and preference mode policies are per-user settings and can be found under User Configuration, Windows Settings, Internet Explorer Maintenance (see Figure 3.11— you must right-click the Internet Explorer Maintenance node to select the preference option). Again, you can only choose one mode within a single GPO.

Figure 3.11: Viewing IE Maintenance policy in a Win2K GPO.

You can, of course, have two GPOs that apply to a user, and you can specify a different mode in each of those GPO. IE Maintenance policy is meant to be used with IE-related Administrative Template policies. The IE-related Administrative Template policies can be found at Computer 63

Chapter 3 Configuration, Administrative Templates, Windows Components, Internet Explorer and User Configuration, Administrative Templates, Windows Components, Internet Explorer. The Administrative Template policies are meant to let me lock down which settings a user can fiddle with in IE; then maintenance-mode IE Maintenance policy controls what the various configuration options in IE should be. I can also use Administrative Template policy with preference-mode IE Maintenance policy to control which settings a user can freely modify after the initial policy setting. For example, let’s see how I can use IE Maintenance policy to set a certain proxy configuration on your user’s browser, then use Administrative Template policy to prevent the user from changing his or her proxy settings. The first step is to use IE Maintenance to set the proxy information. Within your GPO, drill to User Configuration, Windows Settings, Internet Explorer Maintenance, Connection, Proxy Settings. From here, I can configure manual proxy information for IE (see Figure 3.12).

Figure 3.12: Setting IE Maintenance proxy policy.

After you’ve configured the proxy information, you can restrict the user from changing his or her proxy settings by using Administrative Template policy. To do so, drill down to User Configuration, Administrative Templates, Windows Components, Internet Explorer, and enable the Disable changing proxy settings policy. In this case, you should also enable the Disable changing automatic configuration settings policy so that the user has no ability to modify proxy settings and auto-proxy settings. After you’ve completed configuring these settings, a user who logs onto his or her Win2K workstation and processes this GPO will have browser proxy settings as Figure 3.13 shows.

64

Chapter 3

Figure 3.13: Viewing locked-down browser proxy settings.

As Figure 3.13 shows, not only is the manual proxy server set to the setting that we specified in Figure 3.12, but the whole dialog box is grayed out and cannot be changed by the user. So far, I’ve talked only about maintenance mode IE Maintenance policies. Let’s look at how we can enable preference-mode policies. To do so, simply right-click the Internet Explorer Maintenance policy node within a GPO, and select Preference mode. If you already have IE Maintenance policy on the GPO, you will need to first select the Reset Browser settings context menu item to clear all current IE Maintenance mode settings. Alternatively, you should create a new GPO to house your preference-mode settings separate from your maintenancemode ones.

With preference-mode enabled, you will now see an additional policy option under the IE Maintenance node, called Advanced. The Advanced policies let you control additional IE settings that are not exposed via maintenance-mode policies (see Figure 3.14).

65

Chapter 3

Figure 3.14: Viewing Advanced IE Maintenance policy settings exposed in preference mode.

Because these advanced options are only implemented in preference mode, the user will be able to change them unless you disable the underlying functionality by using Administrative Template lockdown. Typically, when designing your IE Maintenance policy, you will end up using some combination of maintenance-mode and preference-mode GPOs along with a sprinkling of Administrative Template lockdown to get the perfect IE configuration for your users.

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? A: Group Policy Objects (GPOs) provide for computer-based startup or shutdown and userbased logon or logoff scripts. Using these scripting capabilities, you can “trap” for logoff and shutdown events and perform actions based on them. In Windows NT 4.0, I can’t tell you how many times I wanted a way to perform some action, like killing a process or running an environmental cleanup script, before the user ended their session either by shutting down or logging off. With Active Directory (AD)-based GPO in Windows 2000 (Win2K) and Windows XP, it is easy to do so. GPO-based script policy can support any number of “executable” types, from DOS-style batch files to Perl scripts to Windows Script Host (WSH) scripts, and even compiled executables. This functionality provides for a lot of power in executing tasks based on these types of user-driven events. Creating startup/shutdown or logon/logoff policy is easy. After you start the Group Policy editor tool, navigate to either Computer Configuration, Windows Settings\Scripts, (Startup/Shutdown) or Computer Configuration, Windows Settings\Scripts, (Logon/Logoff).

66

Chapter 3 Deciding whether you need to use a shutdown script or a logoff script is more than just deciding when you want the script to run. Computer-based scripts run with a different security context from user-based ones. Namely, computer-based scripts run under the security context of LocalSystem, and user-based scripts run under the context of the logged on user. Thus, startup and shutdown scripts have privileges to do pretty much anything they want on the local computer, but logon and logoff scripts are limited to what the user can do. However, because shutdown and startup scripts run in the context of LocalSystem, they cannot access other Windows resources located remotely from where they’re running. It’s important to understand that both logoff and shutdown scripts execute at the beginning of the logoff and shutdown processes, respectively. Thus, they should have the entire environment they need to perform their tasks. However, it’s always a good idea to test your scripts first—I have found cases in which certain commands did not work because they made assumptions about the environment that were no longer valid. This scenario is especially a possibility for shutdown scripts. You also need to be aware that shutdown and logoff scripts always run synchronously. That is, when the scripts start running, no other tasks are happening in the background that might affect the scripts proper execution. This behavior makes sense because Windows might start shutting down valuable resources required for a shutdown or logoff script to execute if those scripts were allowed to run asynchronously, as startup and logon scripts can. If you want to enable shutdown scripts on your Win2K domain controllers, be aware of a particular twist in the way GPOs are processed on domain controllers. You will need to implement your shutdown scripts within the built-in Default Domain Controllers Policy GPO. If you try to implement shutdown scripts on domain controllers in another GPO, it will simply be ignored.

If you need to provide some kind of user dialog box within your logoff or shutdown scripts, be aware that depending upon the type of dialog box that you display, your users might not see it. For example, if you’re running a WSH script and you use the Wscript.echo method to output a dialog box for the user to confirm, the dialog box will appear only as a popup box that waits for user response if your default WSH script executable is Wscript.exe rather than Cscript.exe. If you need to show the user a dialog box for confirmation as part of your WSH script, you’re better off using the VBScript msgbox function or its equivalent in JScript. If you expect a user to confirm a script dialog box, especially during a shutdown script, make sure that there is a good chance that a user is actually present when the script executes. If no user is present to confirm a dialog box or answer a question, the script will just sit there until the default 10 minute timeout passes, at which point the script will be killed and Windows will continue the logoff or shutdown sequence.

If, for troubleshooting purposes, you want to see the command window that is running behind the scenes when your scripts execute, you can set a computer- or user-specific administrative template policy to show verbose script execution. This policy can be found in Computer Configuration, Administrative Templates, System, Scripts (run startup scripts visible and run shutdown scripts visible) or User Configuration, Administrative Templates, System, Scripts (run logon scripts visible or run logoff scripts visible). Figure 3.15 shows how you can enable visible script execution for shutdown scripts.

67

Chapter 3

Figure 3.15: Enabling verbose shutdown script execution through administrative template policy.

Enabling visible processing of scripts doesn’t change the behavior of any user dialog boxes that the scripts may generate. Visible processing simply shows the command window that is generated by a batch file or other command shell driven script. It can be valuable for troubleshooting if your script sends status messages to a command window during execution. Now let’s look at the process for enabling shutdown or logoff scripts. The dialog boxes for selecting and finding scripts within Group Policy are less than intuitive. Keep in mind that the script files—whether they are batch files or WSH scripts—are stored within the Group Policy Template (GPT) in SYSVOL for each GPO that references the script. So if you have a script that is implemented in 10 GPOs, the script file will be stored 10 times within the GPTs of those 10 GPOs. Figure 3.16 shows the dialog box for adding a logoff script to a GPO. All of the types of scripts supported in Group Policy follow the same pattern for adding scripts.

68

Chapter 3

Figure 3.16: Viewing the dialog box for adding scripts to a GPO.

As you can see in Figure 3.16, it’s perfectly “legal” to have different types of scripts within a GPO. It’s also perfectly legal to have multiple scripts assigned to a single GPO (and, of course, a user or computer can also process multiple GPOs, leading to many scripts running during a logoff or shutdown sequence). When you have multiple scripts on a given GPO, they process in order from those higher in the list to those lower. So, with the setup that Figure 3.16 shows, shut.vbs runs first and new.bat runs second. If you want to add a new script to the list, there are a few tricks you can use. If you click Show Files, a Windows Explorer windows will open focused on the SYSVOL folder in which the scripts are stored (see Figure 3.17).

69

Chapter 3

Figure 3.17: Viewing the GPT folder within a GPO where logoff scripts are stored.

If you have scripts located in other folders, you can simply copy and paste them into this folder. That is the first step in the process. The next step is to add the new script to the list of scripts being processed by this GPO. This list is the list that you see in the top half of Figure 3.16. To add the new script, click Add, then click Browse. You will be taken to an open file dialog box focused on the GPT folder in which you just pasted your new script. From here, you simply highlight the script, and select Open to add the script to the list of those being processed by the GPO. You can also add to the script any command-line parameters, which are parameters that you might want to pass to the script as its executing (see Figure 3.18).

Figure 3.18: Adding command-line arguments for script execution.

If you haven’t already pasted the script that you want to add to the GPO into the correct folder in the GPT, there is an alternative way to call a new script. If you click Add, as before, then click Browse, you can browse the file system to locate the script that you want to add. In that case, the GPO will run the script from wherever the script is located (see Figure 3.19).

70

Chapter 3

Figure 3.19: Adding a script from an alternative file location.

In the example scenario that Figure 3.19 shows, I’ve added a script called listGPO.vbs from the C:\ folder. The problem with this scenario is that that script needs to be in C:\ on every machine that the GPO processes on—or it won’t be found. An alternative approach is to reference a script located on a server share somewhere on your network and accessible from all machines. However, keep in mind that if you take this approach, the script will not be accessible from a computer-based startup or shutdown script policy, because they are running under the LocalSystem security context and won’t have access to network shares. I suggest that in most cases you simply copy your scripts into the GPT for that GPO so that the scripts can be replicated with the rest of your GPOs. The only case in which it makes a lot of sense to have a script referenced from a network share is when that script changes often and is used by many different GPOs. In such a case, having to keep the script synchronized across many different GPTs would be difficult.

Q 3.8: Can I use Group Policy Object-based software installation to deploy a Windows service pack? A: In fact, you can! This process is fairly straightforward as long as the service pack provides an .MSI file that can be run to perform the update. Most Windows service packs provide a file called update.msi that can be used in a Group Policy Object (GPO)-based software installation policy to deliver service pack updates to workstations or even member servers. 71

Chapter 3 The key is that you need to deploy the service pack using a machine-based assignment rather than any other mode within software installation. Machine assignment means that at the next reboot, the computer will process its GPOs and when it comes across the service pack update that has been defined, will run the update before the user can logon. Typically at the end of the update and before the user can log on, a reboot is triggered to complete the service pack update. I will provide the steps you can follow to update a Windows 2000 (Win2K) or Windows XP workstation to a new service pack using GPO-based software installation. The very first task you need to do is get the network install version of the new service pack. This version usually comes in an executable file format. Once you have this file, copy the service pack file into a directory on the server that will source the service pack update. This directory could be a folder that is replicated or made available via Active Directory (AD)-based Distributed File System (DFS). Extract the files into the folder using the –x option (for example, xpsp1_en_x86.exe –x). After the files are extracted, the file of interest will usually be stored in the i386\update folder within the service pack files and be called update.msi. Locate that file. Open the Group Policy editor tool focused on the GPO that will be used to deploy the service pack update, and drill into Computer Configuration, Software Settings, Software Installation. Right-click the software installation node, and choose New, Package. When you enter the path to update.msi, make sure you refer to it using a relative path, such as a UNC path (for example, \\server\packages\sp3\update.msi, rather than an absolute path, like c:\sp3\update.msi). After you choose the .MSI file, you will see a dialog box that lets you simply assign the package or choose other options using Advanced published or assign. I always choose the latter as it gives me the chance to review all of my options before committing the application. Within the advanced options screen, you can change various behaviors of the deployment (see Figure 3.20). For example, if you only wanted this service pack update to go to a select group of machines, you could select the Security tab and adjust permissions such that only the computer or group of computers that you want to target have read permissions on this package.

72

Chapter 3

Figure 3.20: Viewing the application deployment options within Group Policy software installation.

As you can see in Figure 3.20, I don’t want to select the Uninstall this application when it falls out of the scope of management check box. Doing so would be bad because most service packs shouldn’t be uninstalled just because the workstation or server is no longer processing a GPO. When you’ve got all the options set the way you want them, click OK, and the application will be live and available for deployment to the next workstation or server that is restarted. Remember that software installation policy does not process during normal GPO background refresh, so you will need to restart your computers to have this policy be processed. When your computers restart, you should see a message in the Windows banner that comes up before the logon screen is presented, indicating that the service pack is being installed. If you don’t see such a message, the GPO that is offering the service pack is probably not being processed. You can look in the userenv.log file in the %systemroot%\debug\usermode folder to determine whether the GPO is actually being processed, and if so, which, if any, errors might be preventing the update from installing. If you’re planning to deploy a service pack to a number of machines in your environment using this method, expect the installation to take a while to complete. You might want to time it such that you deploy the service pack at the end of a business day and either force a reboot of all target workstations after your users leave or have the users perform a shutdown/restart as they’re leaving.

73

Chapter 4

Chapter 4: Designing a GPO Infrastructure Q 4.1: How can I have version control for my Group Policy Objects? A: Although Windows 2000 (Win2K) and Windows XP don’t include a built-in version-control system for managing changes to your Group Policy Objects (GPOs), there are several low- and high-tech approaches you can take to ensure a consistent GPO environment. A key factor in the success of designing and deploying a substantial GPO-based infrastructure is the ability to manage and maintain that infrastructure over time. Similar to other aspects of your IT infrastructure, you need to be able to track and document changes to GPOs, and support formal release-management processes that most companies require. Unfortunately, there are no mechanisms within the GPO product to do so; thus, we have to create our own. When I refer to the lack of version control within GPOs, I am not referring to the internal versioning mechanism that GPOs use to ensure their Group Policy Container (GPC) and Group Policy Template (GPT) are in sync as they are replicated to your Active Directory (AD) domain controllers. In most cases, this internal versioning scheme won’t be useful for your company’s version-control needs because it keeps numerical track of only each individual change that you make to a GPO.

Embed Version Information in a GPO’s Friendly Name As I mentioned, you can take several approaches to overcome the lack of version control within GPOs. The first approach I’ll talk about is simple but can meet your needs in many cases. Specifically, you can embed version information within the “friendly name” of your GPOs. Thus, the name of the GPO becomes the place where you keep track of changes you make to your GPOs. Figure 4.1 shows an example of how this scheme might work.

Figure 4.1: Using version information within a GPO’s friendly name.

74

Chapter 4 As Figure 4.1 shows, I have three GPOs linked to my domain that contain version information. Each time I make a set of changes to a GPO, I change the version in the friendly name to reflect that. Of course, the version information isn’t meaningful without some information as to what is behind the number. For that, you can use a spreadsheet to track each change you’ve made to your GPO. You’re probably thinking that creating such a spreadsheet would take forever, given the number of settings that are contained within a default GPO. Fortunately, you can get some help. Microsoft has created a spreadsheet for Windows XP (that works for Win2K as well) that contains all the default Administrative Template settings within a Windows XP-based GPO. You can find the spreadsheet at http://www.microsoft.com/windowsxp/pro/techinfo/productdoc/gpss.asp. This spreadsheet serves as a good starting point for keeping version information, though you will have to add rows for other policy areas such as security and software installation. Figure 4.2 shows an example of how you might use this spreadsheet as a way to track version info for your GPOs.

Figure 4.2: Using the Microsoft GPO settings spreadsheet to track version information for your GPOs.

Create Custom .ADM Files Another approach you can take for storing GPO version information is a slight variation on the previously mentioned approach. Namely, you can create a custom .adm administrative template file that “tattoos” version information into the registry of each computer (and user) that receives a particular GPO. This approach allows you to go to a workstation and see what version of GPO has been processed. I like this approach because not only does it let you know which version of 75

Chapter 4 GPO a computer or user has received, but also provides a good way to tell whether GPOs are being processed correctly—if the version information is not delivered to the registry correctly, you know there is a problem with the GPO. To use this approach, you have to create a custom .adm file. I’ve created just such a file, which Listing 4.1 shows. CLASS MACHINE CATEGORY !!Custom Policy !!MachineGPOVersion KEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy" EXPLAIN !!GPOVersion_Help PART !!Blank EDITTEXT VALUENAME "CURRENTVERSION" END PART END POLICY END CATEGORY ; MY CUSTOM MACHINE POLICIES CLASS USER CATEGORY !!CUSTOM POLICY !!UserGPOVersion KEYNAME "SOFTWARE\MyCompany\GPO\Desktop Lockdown Policy" EXPLAIN !!GPOVersion_Help PART !!Blank EDITTEXT VALUENAME "CURRENTVERSION" END PART END POLICY END CATEGORY ; [strings] Custom="Custom Preference" MachineGPOVersion="Set current GPO version for machine" GPOVersion_Help="Enter the version number for this GPO" Blank=" " UserGPOVersion="Set current GPO version for user" Listing 4.1: A custom .adm file for inserting GPO version information into the registry.

The name of the GPO (for example, “Desktop Lockdown Policy”) is embedded within the .adm file. You will need to customize the .adm file for each GPO for which you embed version information. In case you’re wondering what this customization will look like within the Microsoft Management Console (MMC) Group Policy editor tool, Figure 4.3 shows you.

76

Chapter 4

Figure 4.3: Viewing the custom .adm policy created for storing GPO version information in the registry.

And, finally, Figure 4.4 shows what this customization looks like if I go to the registry on a machine that has processed this GPO.

Figure 4.4: Viewing the effects of a GPO version policy delivered to a computer.

77

Chapter 4 In Figure 4.4, we’re viewing the version information for the computer (HKEY_LOCAL_MACHINE) rather than the user. Although you might want to keep the version number of a GPO the same across both computer and user settings, you can, of course, maintain different numbers, depending upon your needs. You will still want to keep a spreadsheet that describes what each version number corresponds to within the GPO. Third-Party Tools Although the two approaches I’ve just described are easy to implement, they lack several key features that you might need for a fully functional version-control environment within your infrastructure. The high-tech approach is to use a product such as FullArmor’s FAZAM GP Repository. The Repository is an offline store that solves a number of GPO management problems at once. In addition to letting you make changes to GPOs offline before they are live in your AD, the Repository can keep track of version information for your GPOs. More importantly, the product can keep a history of GPO changes that tracks who made the change, when the change was made, and why it was made. This kind of thorough change management is key if your company starts to rely more heavily on GPOs to support your Win2K or Windows XP infrastructure.

Q 4.2: How many Group Policy Objects can I create in a domain before I start affecting the performance of my workstations? A: There are many factors that affect Group Policy Object (GPO) processing performance. There are things you can do to reduce the time it takes to process a GPO, and thus allow more GPOs to run before your users notice a significant impact. There are a number of behaviors within the normal GPO processing cycle that affect how long a computer or user(s) takes to process a GPO. There is no one answer to how many GPOs you can use before you affect the user experience. However, understanding the behaviors that affect performance can go a long way toward helping you gauge how many GPOs your infrastructure can support. Asynchronous vs. Synchronous Processing By default in Win2K computers and users process GPOs synchronously. This means that, when the computer boots up, it processes all computer-specific GPOs it is subject to before presenting the logon dialog box to the user. Similarly, when the user logs on, all user-specific GPOs are processed before the desktop is shown to the user. In Windows XP, just the opposite is true. Windows XP uses asynchronous GPO processing, also known as fast logon optimization. Fast logon optimization in Windows XP is just asynchronous GPO processing, which allows the computer to present the logon dialog box to the user without waiting for all computer-specific GPOs to finish processing.

Asynchronous processing allows the computer to start up and present a logon dialog box to the user even though all computer-specific GPOs have not finished processing. Asynchronous processing also allows a user to log on and get control of the desktop before all user-specific GPOs have finished processing. Asynchronous processing can speed up the overall GPO processing cycle because the computer or user do not have to wait for all GPOs to finish 78

Chapter 4 processing before moving on to the next step. However, the downside is that some policy features within the GPO—such as folder redirection and software installation—can take two user logon cycles to take effect. You can set asynchronous vs. synchronous behavior on a per computer basis through an Administrative Template policy. In Win2K, the policies that control synchronous and asynchronous processing are found in Computer Configuration, Administrative Templates, System, Group Policy. Specifically the policy items are Apply Group Policy for computers asynchronously during startup and Apply Group Policy for users asynchronously during logon. If you enable these policy items, GPOs are processed asynchronously. In Windows XP, because GPOs are set to asynchronous processing by default, you need to set only one policy item to configure synchronous policy processing. Namely, in Computer Configuration, Administrative Templates, System, Logon, the Always wait for the network at computer startup and logon policy item, which Figure 4.5 shows, should be enabled to enable synchronous policy processing.

Figure 4.5: Enabling synchronous GPO processing in Windows XP.

GPOs that Don’t Change Aren’t Processed You will get some GPO processing performance benefits from some default behavior around GPO versioning. Whenever you make a change to a GPO, an internal version number that the GPO keeps is incremented by the number of changes you make. In addition, workstations and servers hold a history of the last version of a particular GPO that was processed in their registry. The default behavior in Win2K and Windows XP is that, if a GPO hasn’t changed since the last 79

Chapter 4 time it was processed (and thus its version number is the same as the history information stored in the registry), the GPO is not processed; it is simply skipped. If you have a large number of GPOs, but they are fairly static, your computers and users will incur a performance penalty the first time they are processed, but after that the processing time will be short because the GPO is not actually processed. You can, of course, override this behavior and force all GPOs to be processed regardless of whether their version numbers change. You set the Administrative Template policy to control this behavior on a per client-side extension (for example, per folder redirection, software installation, security, and so on) basis and can be found in the same location within Win2K and Windows XP—namely Computer Configuration, Administrative Templates, System, Group Policy. Figure 4.6 shows an example of how you can modify the Security Policy Processing item to process security policy even if the GPO hasn’t changed since the last processing cycle.

Figure 4.6: Modifying client-side extension behavior to process a GPO even though it hasn’t changed.

By processing only those policy extensions that are required, regardless of whether the GPO has changed, you can further minimize GPO processing time and thus process more GPOs. Disable Portions of a GPO that Aren’t in Use You can further reduce GPO processing overhead—and thus process more GPOs—if you are not using portions of a GPO (by disabling either computer-specific policy or user-specific policy). For example, let’s say that you’ve defined a GPO that only affects per-computer security 80

Chapter 4 policy—there is no user policy defined. You can disable the user side of the GPO, and a system processing that GPO at user logon will simply not take the time to try and read the GPO. To disable one side or another of a GPO, open the Group Policy Microsoft Management Console (MMC) snap-in tool focused on the GPO, and right-click the GPO’s name in the left-hand scope pane. Choose Properties from the context menu. You will see the dialog box that Figure 4.7 shows.

Figure 4.7: Disabling the computer or user portions of a GPO to speed GPO processing.

As Figure 4.7 shows, you can select either the Disable Computer Configuration settings or Disable User Configuration settings check boxes to disable the unused portion of the GPO and thus improve overall GPO processing throughput. These are the principal behaviors that exist within an AD domain that reduce the time it takes to process GPOs. There are some things you can do in your GPO design that will further improve the processing speed of a GPO, and thus increase the number of GPOs that a given user or computer can process before their experience is significantly degraded. Some of these design points include: •

Ensuring that domain controllers and servers are always close to your client computers, from a network perspective. For example, if you are using software installation policy to deploy a large application such as Microsoft Office to your computers, make sure that the server on which the Office installation bits are stored are not across a slow WAN link from the clients processing the GPO.

81

Chapter 4 •

Ensure that any startup, shutdown, logon, or logoff scripts that you write are tested thoroughly to ensure that they don’t hang during processing. If a script delivered by a GPO hangs, the client will wait until the script times out (10 minutes by default) before proceeding to process the rest of the GPOs. This behavior can cause interminable delays in the overall GPO processing time.

•

Minimize GPOs linked across domain boundaries. In AD, you can define a GPO in one domain within your forest, and link it to a container in another domain. However, this cross-domain linking can cause increased processing time as the client computer must authenticate across domain trust boundaries to access the remote GPO. A better solution is to copy the GPO from the source domain to the target domain using tools such as those found in FullArmor’s FAZAM utility.

Q 4.3: How do I deal with multiple domain forests and Group Policy Objects? A: If your Active Directory (AD) forest consists of multiple domains or maybe even multiple domain trees, you might need to take a step back in your Group Policy Object (GPO) design and figure out how your GPOs can be used and managed across multiple domains. The challenges of designing a GPO implementation for a multi-domain forest are more complicated than those you need to consider in a single domain environment. First and foremost, you need to understand how each of the domains will be administered. Remember that GPOs are created and exist within a single domain but can be linked to across domain boundaries. However, linking to GPOs across domain boundaries imposes a certain performance penalty on the users and computers who process those cross-domain GPOs. So when you’re designing a GPO infrastructure that will span domains, what is the best approach to take? The first thing you have to do is decide who is going to control the GPOs within each domain. Will they all be centrally managed? Will each domain control their own GPOs? Or will the GPO infrastructure be a hybrid of some centrally managed GPOs and some managed within each domain? Each approach will call for a different design. The key challenge you will face in a multi-domain environment is ensuring consistency. Because each domain will end up creating its own GPOs, even if they are all centrally managed, they will be physically distinct. Over time, unless you have very good change-management processes in place, you may find that GPOs diverge and conflict in their configuration. The problem is compounded because there are no native tools in Windows 2000 (Win2K) or Windows XP that let you copy a GPO from one domain to the next. Third-party tools such as FullArmor’s FAZAM let you back up a GPO from one domain and restore it to another, but that is the closest you can currently get to being able to duplicate your GPOs across domain boundaries. And, because there is no synchronization mechanism for these cross-domain GPOs, you will need to take some extra pains to ensure consistency. You can do so by clearly documenting your GPOs and making that documentation available to all domain administrators in your forest. Additionally, you should develop up-front some good for when you want to let GPOs be linked across domain boundaries. Linking across domain boundaries imposes performance penalties on users and computer that process them. You might be tempted to just define all your GPOs in a single domain—for example the forest root domain. This approach is certainly a possibility but it will be the poorest 82

Chapter 4 performing approach, and it leaves you open to GPO problems if there are problems with interdomain trust relationships. I recommend that for those GPOs that you absolutely need to have highly available, you create the GPOs in each domain in which they’re needed. Then you can make other less-critical GPOs available to other domains via cross-linking as they’re needed. Figure 4.8 shows an example of how you might implement a multi-domain GPO infrastructure.

Figure 4.8: Viewing a multi-domain implementation of GPOs.

In Figure 4.8, you see that there are three domains in this forest called tld.org. Each domain has its own Security GPO, linked at the domain level. In addition, there are a number of OU-linked GPOs in each domain. Europe.tld.org has decided that it wants to use the public key security policy that is defined in tld.org and linked to OU22, so it has created a cross-domain link to that GPO from OU4. Likewise, the organizational unit (OU) administrator of OU2 in tld.org wants to use the Internet Explorer (IE) maintenance policy defined in Us.tld.org and currently linked to OU32. So, she has created a link from that GPO to OU2.

83

Chapter 4 Cross-domain linking of GPOs is pretty straightforward. However, the one thing you do need to remember to do is grant access to the appropriate groups to read and process your GPOs. To do so, you need to apply the Read (but not write) and Apply Group Policy permissions to your GPOs for the “remote” administrator to link to and process the GPO. For example, if I’m an administrator of OU4 in Europe.tld.org, I need to have permissions to be able to read and apply Group Policy on the public key security GPO to link to it and have my users process it. By default, if the Authenticated Users group has read and apply Group Policy permissions on a GPO, anyone in the forest should be able to link to it and process it. However, if the administrator of the GPO has removed the Authenticated Users access control entry (ACE), the administrator will need to explicitly add an ACE that grants permission to the administrator of OU4 in Europe.tld.org and to the appropriate user groups that will be processing that GPO. Indeed, using groups to control who can access and process a GPO is an ideal way to restrict who can link to your GPO either within or across domain boundaries. I always recommend that if you have a GPO that you don’t want just any administrator in your forest to link to, you should ensure that you have modified its default permissions to remove the Authenticated Users ACE and grant only the required permissions to the groups that need them.

Q 4.4: How do I deal with change control in my Group Policy Object infrastructure? A: There is no built-in capability in Windows 2000 (Win2K) or Windows XP to support Group Policy Object (GPO) change control. In other words, there are no tools out of the box for managing the process of implementing and rolling back GPO changes. In Question 4.1, I discussed ways of doing version control of your GPOs in the absence of those capabilities in Win2K and Windows XP. In this section, I’ll talk about how you might handle the change control process that is required in most enterprise environments. If your environment is managed like most organizations, any changes that are made to production systems require strict change control processes to track the change event. How strict your processes are usually depends upon how large your organization is and how great of an impact the change will have. In the case of your GPO infrastructure, there simply are no tools out of the box that can provide good change management. As such, you either have to craft your own solution or look to thirdparty tools such as FullArmor’s Group Policy Repository. Let’s look at some of the challenges of implementing a change management system for GPOs. The first thing that most change processes require is a way of documenting what is changing. As you know, it can be very difficult to document all of the various policy settings within a single GPO, let alone several spread across your Active Directory (AD) infrastructure. In these cases, there are simply no good ways to do so out of the box without assistance from a spreadsheet or other manual mechanism. You can use command-line tools such as gpresult.exe to document how a GPO effects your users, but you can’t use that tool to actually document the contents of a GPO, irrespective of what users or computers it’s targeted at. Another challenge is in the automation of the application of a GPO change. Unlike other types of changes in your Win2K or Windows XP infrastructure, you can’t script a GPO change because there are no scripting interfaces into the GPO infrastructure. To document a change for an administrator to implement, you need to actually spell out the step-by-step instructions that describe the check boxes in the Administrative Template or security policies you’ve 84

Chapter 4 implemented. This task can be tedious and error prone and requires that the implementer of GPO changes have some familiarity with GPO technology. The ability to back out of changes is another big problem with the current technology. There is simply no clean way to back out of a GPO change. Depending upon the type of policy you need to back out, this process can get downright nasty. For example, let’s assume that you’ve applied a GPO change to an existing policy; this change creates a few more desktop restrictions on some user’s desktops. Now let’s assume that, as a result of the change, an application has stopped working and you need to roll back the change. You may need to go into the GPO and edit the policy items that you changed, disabling the policy function that you previously enabled (or viceversa depending upon the policy). This process isn’t really a back out in the sense that you’ve returned the environment to its pre-change state, but rather an undo of what the policy previously did. Generally speaking, if the policy is a true policy as defined in Question 1.2, you should be able to return the policy setting to Not Configured and that is enough to remove the policy. However, if it’s a preference that you’re dealing with, to back it out, you will need to actually set the policy to its opposite state. What about backing out Folder Redirection or Software Installation policy? Both of these policies have options that you can select that revert state back to its original form if the policy no longer applies to the user or computer. In Figure 4.9, there is an option in Folder Redirection to point the user’s redirected folder back to the user’s local user profile if the policy no longer applies.

Figure 4.9: Viewing the option to remove Folder Redirection policy when it no longer applies.

85

Chapter 4 The back out routine for this policy requires that the user no longer processes this policy, which could cause other problems if the GPO has other settings that you are implementing. As you can see, there are no easy answers when it comes to backing out. The easiest answer is test your GPO changes thoroughly up front so that you rarely need to back out. A final issue that you’ll have to deal with in the realm of change management is staging of GPO changes. That is, how do you make a change ahead of the time that you actually want to implement it? There are a couple of tactics for doing so. The first and easiest is to take advantage of the fact that new GPOs can be created without linking them to a container object (see Question 3.1 for more information about how to do so), or they can be created without linking them to the target container object on which they will ultimately be implemented. For example, you could create a test OU to which you initially link the GPO for testing, then when you’re ready to move it into production, simply add the link to the ultimate container object. This approach works great if you’re implementing a new GPO, but what about staging changes to existing GPOs? Again, this process is very difficult out-of-the-box unless you have a third-party tool that provides for offline editing of GPOs. The best you can do is to test your changes on a different GPO that has the same settings as the production GPO, then, after you’ve verified the changes, you can implement them in production. Before editing a GPO, disable it from the Options dialog box (which Figure 4.10 shows) in AD so that users and computers aren’t processing it while you’re in mid-edit.

Figure 4.10: Viewing the option to disable a GPO prior to making changes to it.

The challenge with using disable while you’re making GPO changes is that any users or computers that logon or startup while the GPO is disabled won’t process the GPO. This behavior is usually not a big problem, as subsequent logon and startup events will succeed, but if you’re relying on the GPO for key desktop functionality (for example, for folder redirection or software installation), you should try to make GPO changes of this kind after hours when users aren’t likely to logon.

86

Chapter 4

Q 4.5: What is the best scheme for allowing my organizational unit administrators to create and edit Group Policy Objects? A: Delegation of Group Policy Object (GPO) administration is a delicate balancing act. On the one hand, you want to allow organizational unit (OU) administrators the ability to manage Group Policy within their environment. On the other hand, Group Policies that are meant for a single GPO can impact an entire Active Directory (AD) domain. Thus, it’s important to balance what an OU administrator can do with what is best for the AD. Remember that delegation of GPO administration falls into roughly three pieces: •

Delegation of the initial creation of a new GPO

•

Delegation of editing and deletion of existing GPOs

•

Delegation of the ability to link and unlink GPOs from container objects such as sites, domains, and OUs

To delegate the ability to create a new GPO, you must place the user or group who needs that capability in the Group Policy Creator Owners group. After the GPO has been created, the user or group needs the Read, Write, and Create All Child Objects permissions to be able to edit the GPO. Read, Write, and Delete All Child Objects permissions are required to be able to delete the GPO (see Figure 4.11).

Figure 4.11: Viewing a GPO’s permissions that grant edit and delete capabilities.

87

Chapter 4 In Figure 4.11, you see that the Finance Admins group has the ability to both edit and delete the existing GPO called Finance Admins Lockdown. The ability to link or unlink a GPO to a container object is controlled by permissions on the AD container object itself. Specifically, to link and unlink a GPO to a site, domain, or OU, the user or group needs the Read and Write gPLink and Read and Write gPOptions permissions on the object. Typically these are obtained by granting the user or group Read and Write permissions on the container object. You can also grant the gPLink and gPOptions permissions individually through the AD Access Control List (ACL) editor within the Microsoft Management Console (MMC) Active Directory Users and Computers or AD Sites and Services snap-ins. Right-click the container object in question, and choose Properties from the context menu. Then choose the Security tab to bring up the ACL editor. The easiest way to grant the Read and Write permissions I mentioned earlier is to immediately click Advanced to choose the advanced ACL editor. Then add the user or group to which you want to grant permissions, select the Properties tab, and select the appropriate permissions, as Figure 4.12 shows.

Figure 4.12: Granting GPO linking and unlinking permissions on a container object.

After you have worked out how to delegate the various tasks around GPO creation, maintenance, and use, the next question is, What is the best approach to use in granting these rights? The answer depends on your environment, but there are a couple of approaches that you can take. The first approach is to delegate the linking and unlinking process to only your OU administrators. In this scenario, some central group is responsible for creating and editing GPOs, then you leave it up to the OU administrator to decide which of those GPOs they want to link to 88

Chapter 4 their OU. For GPOs that need to be linked to the domain and site level, the central group is again responsible for handling those tasks. In this scenario, you need only delegate the linking and unlinking permissions to the OU(s) involved, and grant all creation and editing permissions to your central group. The advantage of this approach is that you have total control over the creation and editing of GPOs within your AD domain. Although GPOs can be linked to containers within a domain, they are available to the entire domain. Thus, it might be a good thing to be able to control who can create or edit GPOs—especially if you consider the worst-case scenario. Suppose you grant an OU administrator the ability to create GPOs in your AD domain. Then, either knowingly or not, that administrator decides to see how many GPOs he or she can create in your domain. Perhaps the administrator creates hundreds or even thousands! The result is that every domain controller in your AD domain will need to replicate the Group Policy Container (GPC) and Group Policy Template (GPT) for each of those GPOs. Although this situation might not be a huge problem in most cases, you might have parts of your network that can’t afford the extra replication overhead of such activity. To take it one step further, suppose a malicious OU administrator were to create a GPO that contains a logon script that is 5GB in size! This logon script must be replicated to all instances of the GPT on all domain controllers for that GPO. Again, not only might the network traffic bring some of your links to their knees, but in some cases, replication of this logon script could cause servers to run out of disk space. The point is that an OU administrator that has limited rights over your domain could wreak havoc over that domain if granted the ability to create or edit GPOs at will. If you’re not worried about such a scenario, you could grant a select group of OU administrators the ability to create and/or edit GPOs. Or you could simply grant those administrators the ability to edit certain GPOs while keeping others off limits. (Permissioning GPOs is not an all or nothing operation—you can grant permissions to edit a select group of GPOs and leave others to the purview of your central group.) If you maintain central control over the creation of GPOs and limit the editing of certain GPOs to certain administrators, you can more easily ensure that any one administrator will not run hog wild on your AD infrastructure. There’s one more point to keep in mind as you decide who gets to do what within your GPO environment. A single GPO can be linked to multiple container objects (multiple OUs). Thus, if you have a GPO that is providing policy for multiple OUs, you need to ensure that you aren’t granting editing rights to each of the administrators of those OUs without requiring some kind of coordination between the two. If you don’t require this kind of coordination, you could have OU administrators overwriting each other’s changes or making policy changes that significantly impact each other’s users. The simple way around this scenario: When you have GPOs that will be linked at the OU level, never share those GPOs among multiple OUs. This setup, however, means that you will have to manage more GPOs in your overall infrastructure than if you were sharing.

89

Chapter 4

Q 4.6: If I have an empty forest root domain, do I need to create or use Group Policy Objects in that domain? A: Although this question might seem esoteric, it’s important to consider how you will treat your empty forest root domain. Some administrators are obliged to simply ignore the forest root because it is empty (that is, it does not contain any discretionary user or computer accounts). However, there is probably some value in setting some policy for that domain up front. The forest root domain is a common fixture in larger Active Directory (AD) implementations. Its purpose is as a placeholder to protect this important first domain from day-to-day futzing that is common in child domains. It also holds user groups such as the Enterprise Admins and Schema Admins groups, which have special rights over the entire forest. So, in large organizations, it’s a good idea to keep the empty forest root as pristine and untouched as possible. However, you will still probably find a need to create some Group Policy Objects (GPOs) to manage this domain—for preventative reasons if for no other reason. GPOs can be used in the forest root domain to further protect the resources that reside in that domain. For example, on this domain, you will most assuredly want to set strict account policy that determines which users can access the domain and which users can perform operations on domain objects. Another good use for GPOs in the forest root domain is to control which users can be members of the allpowerful Enterprise Admins and Schema Admins groups. By default, the only user who is a member of these groups is the Administrator account for the domain. You might want to control this membership very strictly because anyone who can become an Enterprise Admins group member can potentially wreak havoc on your forest. In addition, you might want to set Restricted Groups policy to ensure that only certain users or groups can be placed in the Enterprise Admins group (see Figure 4.13).

Figure 4.13: Viewing a Restricted Groups policy for the Enterprise Admins group.

90

Chapter 4 To ensure that this policy is enforced on the entire forest root domain, define it on a GPO linked to the Domain Controllers organizational unit (OU)—most logically the Default Domain Controllers policy. You might also want to set up some Administrative Template policy that warns users who log onto the forest root domain that they are treading on “sacred” ground. For example, you could use descriptive logon banners and warning text (found in Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, Message text for users attempting to logon) to inform users about the sensitive nature of the domain. All of these mechanisms simply help to keep your forest root domain as pristine and undamaged as possible, which is a beneficial state because the forest root domain is irreplaceable and can cause massive havoc in your AD infrastructure if it’s damaged.

Q 4.7: What are the challenges of “sharing” Group Policy Objects between organizational units? A: As you know, it is possible to create a Group Policy Object (GPO) that is shared between multiple organizational units (OUs), domains, or Active Directory (AD) sites. That is, you can link to a GPO from any number of these container objects. However there are some things to keep in mind when you do so, as doing so can cause some confusion. You can re-use GPOs within your AD forest across different sites, domains, and OUs. For example, as long as an OU administrator has the permissions to link a GPO to his or her OU, and as long as the administrator has permissions to read a GPO, he or she can link it and have users or computers in the OU start processing it. Doing so can be challenging because, although a GPO may be linked to from any number of container objects, it only physically exists in one place. Any changes that are made to a GPO impact every container object that has linked to that GPO. It’s important that you approach your GPO design with a firm grasp on who will be allowed to link GPOs to their container objects and who will be allowed to edit those GPOs. I recommend creating a clear distinction between “shared” GPOs and those that are created specifically for the use of a single or small set of container objects. Shared GPOs will need to have a more stringent change-control process and a clear set of rules about who can link to them and when. There are a few things to keep in mind about shared GPOs as well. First, because a GPO only exists in one place, any changes you make to it, as I mentioned earlier, affect all those who have linked to that GPO This includes, most obviously, the permissions that have been set on that GPO. If an administrator creates a GPO with the express intention of using it to provide policy for the Finance Users group within the Finance OU, the administrator might decide to permission that GPO to only allow users in that group to process the policy (see Figure 4.14).

91

Chapter 4

Figure 4.14: Viewing a GPO permissioned to allow only the Finance Users group members to process it.

As Figure 4.14 shows, the only group with the Read and Apply Group Policy permissions on this GPO (called Finance Users Lockdown) is the Finance Users group. Now, suppose the OU administrator for the Sales OU would like to re-use this GPO and its settings on her own OU. She has the permissions to link the Finance Users Lockdown GPO to the Sales OU, and goes ahead and does so. The next time her Sales users log onto their Windows 2000 (Win2K) or Windows XP workstations, they will get policy from the Finance Users Lockdown GPO, right? No, because the permissions on that GPO only allow members of the Finance Users group to process it. Thus, the Sales OU administrator would either have to add her Sales users to the Finance Users group (probably not a great idea for future manageability) or modify the permissions on the Finance Users Lockdown GPO to allow her Sales users group to have Read and Apply Group Policy permissions on that GPO. In either case, the solution is not perfect. In the first case, you start to lose the meaning of your groups if you add Sales users to the Finance Users group simply to allow GPO processing. In the second case, there is no way to grant the Sales users group the ability to just modify permissions on the Finance Users Lockdown GPO to allow the Sales Admins group to also be able to process the GPO. You will need to grant Write permissions on the GPO to allow permission editing, and if you do grant that permission, the Sales Admins group can not only modify permissions but also modify the settings on that GPO (see Figure 4.15). If they don’t understand that the GPO is being shared by other OUs, many problems could arise.

92

Chapter 4

Figure 4.15: Granting the Sales Admins group the rights to modify permissions on the Finance Users Lockdown GPO.

You would think that just by granting the Sales Admins group the Read Permissions and Modify Permissions rights, members would only be able to change permissions on the GPO. Unfortunately, that is not the case. They can’t actually adjust GPO permissions until they are also granted the Write All Properties permission. I consider this a bug in the way GPO control is delegated! Given the ramifications for sharing GPOs, what can you do? Well, the first and easiest thing to do is to avoid sharing GPOs! Doing so might seem like a lot of work up front, but it will prove its worth as you try to share more and more of your GPOs. You can use the capabilities of a tool such as FullArmor’s FAZAM 2000 to copy the contents and settings of one GPO to another if you want to re-use a particular GPO’s policies but don’t want to manual re-enter them again and again. If you decide to share some GPOs, make sure you know who you’re affecting each time you make a change to those GPOs. The easiest way to do so is to use the “links finder” capability within the Microsoft Management Console (MMC) Group Policy snap-in tool. The links finder is available from the Properties dialog box of any GPO. Simply select the Links tab, choose the domain in which you want to search for links to the selected GPO, and click Find Now. All containers that contain a link to the current GPO will be listed (see Figure 4.16).

93

Chapter 4

Figure 4.16: Using the links finder to locate which container objects are linking to the selected GPO.

The bottom line is that sharing GPOs can save a lot of time, but can also create a lot of headaches if you don’t keep a tight rein on who can link to a GPO and who can edit it.

Q 4.8: Can I use the Group Policy Object-based software installation feature to replace my existing software distribution tools? A: When administrators come across the software installation features in Group Policy, the first thing they wonder is whether they can use this feature exclusively and throw out their existing software distribution tool. Unfortunately, the answer I usually give when someone asks me about this opportunity is, “Not quite!”, and here’s why. The software installation feature in Group Policy is a big step up from the days of Windows NT 4.0, with which you had to use Systems Management Server (SMS) or a similar highly complex software distribution tool to deploy software to desktops and servers in your environment. Group Policy Object (GPO)-based software installation brings a fairly simple and straightforward ADbased deployment tool to those shops that have deployed Active Directory (AD) and Windows 2000 (Win2K) or Windows XP. The Group Policy software installation features truly provide some elegant features not found in other distribution tools: •

Supports per-machine and per-user installation of applications. Thus, you can deploy applications to machines or users based on the organizational unit (OU) they are in or the groups of which they are a member.

94

Chapter 4 •

Supports the concept of application advertisement. Advertising an application means that the application’s icons and shortcuts are installed but the full application isn’t actually installed until the user first uses it.

•

Leverages privilege elevation to let a user run an application installation that the user ordinarily wouldn’t have sufficient privileges to do. This functionality is available only to “managed” applications that have been deployed using GPO-based software installation.

•

Leverages the Windows Installer technology to provide robust install, rollback, and repair features. The software installation feature requires that you package your application installations using the .MSI format, but once you have, you get all the benefits that .MSI provides, including auto-repair of advertised application features and transformation of default packages using transforms. The software installation feature does support a format called .ZAP, which lets you publish to your users applications that have not yet been packaged using .MSI. However, the .ZAP format does not support privilege elevation, so you might not be able to use it for many of your users.

•

Supports the concept of upgrade relationships. After you deploy an application using the Group Policy software installation features, you can automatically upgrade the application to the next version. You can also remove applications that no longer apply. The software installation feature has good application lifecycle management capabilities, making it easier to manage the install, upgrade, and retire cycle that most applications go through.

However, the Group Policy software installation feature is missing some key functionality that most enterprise software distribution tools provide: •

No centralized way to report on the success or failure of an application installation across many machines. Because GPO-based software installation deploys software when a GPO is processed by a user or computer, there is no centralized place to go to determine whether a distribution “event” was 90 percent or 70 percent successful. You would have to cull the logs of each target machine to determine this information.

•

Unlike most software distribution tools, there is no at-a-glance way to view which software has been distributed to which users and machines. Resultant Set of Policy (RSoP) tools, such as FullArmor’s FAZAM 2000, are your best bet for seeing which users and computers are receiving which applications.

•

No inventory component within the software installation feature. Most software distribution tools, such as SMS, provide an inventory component that lets you look at which hardware and software is installed on machines under management.

•

No support for software distribution across slow or dial-up links. Some software distribution tools support trickle-down installations of applications. The software installation feature not only does not support this functionality, but the software installation CSE will not, by default, process a GPO if a slow link is detected.

95

Chapter 4 •

No support for server-based software distribution. There are two modes of installation supported in software installation—assignment and publishing. Publishing is userspecific and requires that a user be logged onto a machine to trigger an installation. Assignment is user or machine specific. In the case of machine-based assignment, although a user does not have to be logged on to trigger the installation, the computer needs to be rebooted to do so. This reboot triggering mechanism is usually not acceptable in most server environments.

•

No support for license metering or a way of limiting the number of users or computers that install an application (other than restricting an application by user or computer group).

If these limitations aren’t critical to you—if you’re working in a small to midsized environment in which Sneakernet is your only other software distribution tool option, GPO-based software installation is a great tool for automating the delivery and installation of software to your users. If you are in a large enterprise environment and are already using a tool such as SMS, GPObased software installation can be a great compliment to your existing capabilities. Software installation-based publishing of applications to the Add/Remove Programs applet (see Figure 4.17) can be a great way to provide your users with a low-maintenance, self-service way of installing optional applications that your enterprise supports but doesn’t necessarily want to install on every desktop.

Figure 4.17: Viewing an application that has been published via GPO-based software installation to the Add/Remove Programs applet.

As you can see in Figure 4.17, I have published the Win2K Administration Tools to users that might need them (I could restrict this application to only appear for administrative users by permissioning the application within the GPO for a particular user group). The application isn’t installed until the user clicks Add. This kind of “software distribution” has low overhead because an administrator need only publish it once for it to be available to hundreds or thousands of users. 96

Chapter 5

Chapter 5: Administering and Delegating GPOs Q 5.1: How do I delegate the ability to edit and link Group Policy Objects in Active Directory? A: Delegation of Group Policy Object (GPO) management involves modifying Active Directory (AD) security on either a container object (a site, domain, or organizational unit—OU) or the GPO itself, depending upon the function you are delegating. Delegation of AD rights can often be a challenging process. In the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, Windows 2000 (Win2K) provides the Delegation of Control wizard to help manage AD rights for the purpose of delegating administration of AD objects. But the Delegation of Control wizard is only good for setting the initial permissions on an AD object and can’t delegate administration of GPOs. If you need to modify those rights, the wizard has little value. Delegate GPO Editing Let’s take a look at how you can delegate the editing and linking of GPOs more directly than with the Delegation of Control wizard. First, let’s examine how you can delegate editing of GPOs. The first thing to know about GPO delegation is that it’s all about modifying the access control list (ACL) of the GPO. A GPO is composed of the Group Policy Container (GPC, which is an object in AD) and the Group Policy Template (GPT, which is a set of folders and files in SYSVOL). Thus, you need to be able to modify the permissions of these two pieces of the GPO to grant users and groups the ability to modify the GPO. Fortunately, there is a fairly easy way to modify these permissions that does not require you to directly manipulate the ACLs on each. The following step-by-step instructions walk you through changing the security on a GPO to allow a new user group (for example, GPO Admins) the ability to edit the GPO called My Delegated GPO: 1. Start the Active Directory Users and Computers (or Active Directory Sites and Services)

MMC snap-in. 2. Right-click the container object (site, domain, or OU) to which the GPO you want to

delegate is linked. 3. Select Properties from the context menu, then select the Group Policy tab. 4. Highlight the GPO you want to delegate, then click Properties. You will be given the

choice of three tabs—General, Links, and Security. Choose the Security tab to bring up the ACL editor focused on the GPO, which Figure 5.1 shows.

97

Chapter 5

Figure 5.1:Viewing the ACL editor focused on a GPO for delegation.

5. Click Add at the top of the dialog box to choose the user group to which you’re

delegating editing rights on this GPO. 6. Once you’ve added the group to the ACL editor, make sure that the group name is

highlighted, then check the following permissions for that group to grant GPO editing rights: Read, Write, Create All Child Objects, and Delete All Child Objects, as Figure 5.2 shows.

98

Chapter 5

Figure 5.2: Delegating GPO editing rights to the GPO Admins group.

7. You can also control who processes a GPO from the same dialog box. The combination

of Read and Apply Group Policy rights means that the groups with those two rights will always process the GPO. There’s nothing more to delegating the editing of an existing GPO than what I’ve just described. Delegate GPO Linking Now lets look at how you can delegate the task of linking an existing GPO to a container object. Without the ability to link a GPO to a container object such as a site, domain, or OU, you can’t really do much with your GPOs—they won’t be processed by any computers or users within your AD infrastructure. You can use the Delegation of Control wizard to delegate the linking right, but I’m going to show you how to do delegate the linking right directly because the Delegation of Control wizard doesn’t let you change the delegation once you’ve used the wizard to set it up initially. Once again, the delegation process for the right to link to GPOs is about modifying AD security—in this case, on the container object directly instead of on the GPO. So let’s suppose that you want to delegate the linking right to the same GPO Admins group I used earlier for the HQ OU. Thus, you want any member of the GPO Admins group to be able to link GPOs to HQ. You can follow these steps to set up this delegation. 1. Start the Active Directory Users and Computers MMC snap-in, and highlight the OU on

which you want to set up delegation.

99

Chapter 5 2. Right-click the OU, choose Properties from the context menu, then select the Security

tab. 3. You will now see the familiar ACL editor dialog box focused on the OU. Click Add to

add the GPO Admins group as a new access control entry (ACE), and click OK to confirm the new addition. 4. With the GPO Admins group name highlighted in the top half of the ACL editor dialog

box, click Advanced to bring up the Advanced ACL editor dialog box, which Figure 5.3 shows.

Figure 5.3:Viewing the Advanced ACL editor focused on an OU.

5. Again, with the GPO Admins group highlighted, click View/Edit, then select the

Properties tab. 6. You will see a long list of AD properties for this OU object that you can set permissions

on. In this case, we are interested in two of those—Write gPLink and Write gPOptions. Select these two rights to grant the GPO Admins group the ability to link GPOs to this OU. (Note that the Read gPLink and Read gPOptions properties should already be selected.) Figure 5.4 shows what these selections will look like.

100

Chapter 5

Figure 5.4: Viewing the rights that need to be set to delegate GPO linking.

7. Click OK through three dialog boxes to confirm the change.

Once you’ve granted these two rights, the group or user you’ve designated will have the ability to link GPOs to the container object. Why? What you did in the previous steps was grant the group called GPO Admins the ability to modify the AD properties called gPLink and gPOptions. These two properties, or attributes as they’re often called, contain the list (gPLink) of GPOs linked to the container object and options (gPOptions) that you’ve selected. A group must have the ability to write to both of these attributes to properly link a GPO.

Q 5.2: How does the Delegation of Control wizard work for Group Policy Objects? A: The Delegation of Control wizard comes with the Active Directory Users and Computers (and AD Sites and Services) Microsoft Management Console (MMC) snap-in tools, and allows you to delegate administration of Active Directory (AD) objects such as organizational units (OUs), users, computers, and so on. However, the Delegation of Control wizard is fairly limited for delegating control of Group Policy Object (GPO) administration. What the Delegation of Control wizard provides with respect to GPO administration is the ability to delegate the process of linking and unlinking GPOs to container objects within a domain. This functionality is a useful capability to delegate in your AD infrastructure. For example, you might want to retain 101

Chapter 5 control of the creation and editing of GPOs within a central group, but then allow administrators of individual OUs the ability to link those GPOs that you’ve created to their respective OUs. Thus, you’ll need to delegate the ability to create and remove those links on each container object. In this situation, the Delegation of Control wizard can help. But first, you should be aware of a couple of limitations in the Delegation of Control wizard. What the wizard does is simply automate the process of editing access control lists (ACLs) on AD objects within your domain. For example, if you’re delegating control of an OU to a group of administrators, you’re basically setting permissions on that OU that allow the administrators to perform the proper operations over AD objects within that OU. The Delegation of Control wizard prompts you to select the target to delegate and the group being delegated to, then does the work of modifying the ACLs on the target to provide access to the group. However, the wizard is stateless. That is, once you’ve made a delegation for a particular AD object to a particular group, there is no easy way to go back and change that delegation through the wizard. To do so, you must go into the AD ACL editor for that object and manually modify permissions. So, the wizard is good for first-time delegation of resources, but not as useful for subsequent tweaking of permissions. Now, let’s look at how you can delegate linking and unlinking of GPOs to particular container objects. First, I’ll provide a little background about the linking process. When you link a GPO to a container object such as a site, domain, or OU, what you’re really doing is modifying a couple of attributes on that container object in AD. Those attributes are called gPLink and gPOptions. The gPLink attribute contains a list of globally unique identifiers (GUIDs) that represent each of the GPOs linked to that container object. gPOptions indicates whether the Block Policy Inheritance feature has been selected on the container object. To delegate the ability to link and unlink a GPO from a container object involves granting the permissions to modify these two attributes, which is exactly what the Delegation of Control wizard does. Let’s step through this process by delegating the ability to link and unlink GPOs from a site object. 1. Open the AD Sites and Services MMC snap-in tool. 2. Highlight and right-click the site to which you want to delegate administration. 3. Select Delegate Control from the context menu to start the Delegation of Control wizard.

Click Next to begin the delegation process. 4. From the Selected Users and Groups dialog box, add all users or groups to which you

want to grant the ability to link and unlink GPOs from this site object, and click Next. 5. On the next dialog box, which Figure 5.5 shows, you’ll see that a site object has only one

pre-defined task that you can delegate—Manage Group Policy links; select that option’s check box. Alternatively, you could have selected the Create a custom task to delegate radio button and manually selected which permissions you wanted to grant on which kinds of objects, but using the common tasks reduces the number of steps you need to perform. Click Next, then Finish to finish the wizard and complete the delegation process.

102

Chapter 5

Figure 5.5: Delegating administration of GPO links on a site object.

To confirm that the proper permissions were indeed delegated to the site object by the wizard, you can go into the properties on the site object, and view its security ACL. GPO linking is considered an advanced permission, so once you have the ACL editor up and focused on the site object, you’ll need to click Advanced to view advanced permissions. Figure 5.6 shows that two ACEs were created for the group (SF Site Administrators) to which I chose to delegate the linking permissions.

Figure 5.6: Viewing the permissions we used the Delegation of Control wizard to create.

103

Chapter 5 In Figure 5.6, the SF Site Administrators group has been granted the Read/Write Property permission twice. Why? Well, remember that two AD attributes contribute to the granting of the linking and unlinking permission on a container object—gPLinks and gPOptions. If I were to highlight each of these permissions and click View/Edit, I would see read/write permissions granted to precisely these two attributes. Now, when users in the SF Site Administrators group want to link GPOs to the San Francisco site, they can do so successfully, knowing that the proper rights have been granted to them.

Q 5.3: How can I prevent certain users from administering portions of my Group Policy Objects? A: As you probably know, the usual way to restrict administration of a Group Policy Object (GPO) to a particular user group is to set security permissions on that GPO that control who can edit it. However, if you want to restrict only certain parts of a GPO, the only way to do so is to use Administrative Template policy. There is a set of Administrative Template policies that let you control which Group Policy editor extensions can be loaded into the Microsoft Management Console (MMC). These policies, in effect, restrict which parts of a GPO a user can load into the MMC, and thus control what they can edit. These policies are not real security but simply block a user’s ability to get to the proper tools for editing a particular part of a GPO. This feature can come in handy when you have a GPO that provides a number of functions—for example, folder redirection, Administrative Template policy, and software installation—and you want to delegate administration of only one part (for example, software installation) of that GPO. The Administrative Template policy that controls the list of permitted MMC snap-ins related to GPOs are located in the same place in both Windows 2000 (Win2K) and Windows XP, under User Configuration, Administrative Templates, Windows Components, Microsoft Management Console, Restricted/Permitted snap-ins, Group Policy. Figure 5.7 shows the policy options that are available.

Figure 5.7: Viewing the Administrative Template policy for restricting the use of GPO extension functionality.

104

Chapter 5 As an example, let’s walk through a real-life scenario to show how these policies are used. I have a GPO linked to an organizational unit (OU) called Finance in my Active Directory (AD) domain. That GPO contains some desktop lockdown settings via Administrative Template policy, some security settings for users of that OU, as well as some software installation policy that supports publishing of applications to the Finance OU user desktops. Now let’s suppose that I want to grant a local administrator of the Finance OU—we’ll call him Joe Admin—the ability to edit the software installation policy on my GPO to deploy some departmental applications, but I don’t want Joe Admin to be able to edit any of the Administrative Template or security policy on that GPO. The first thing I need to do is define a GPO restriction policy that limits the snapins that Joe Admin can load. I can do so from within the same GPO that I will be allowing Joe Admin to edit because I won’t be letting him edit the Administrative Templates that I’ve defined. From the windows that Figure 5.7 shows, I need to disable the Administrative Templates (Users) and Security Settings extension policies. Figure 5.8 shows what this modification would look like.

Figure 5.8: Enabling policy to restrict the use of certain GPO extensions for editing.

With these settings, when Joe Admin attempts to load the GPO into the MMC editor tool, he will simply not see the user-specific Administrative Templates and security settings nodes. Figure 5.9 shows the view that Joe will see when he loads the MMC Group Policy tool focused on a GPO.

105

Chapter 5

Figure 5.9: Viewing an MMC Group Policy tool that has been restricted by Administrative Template policy.

In Figure 5.9, the user-specific Administrative Template and computer-specific security settings nodes are missing. The other option that you have using this policy is to actually restrict all GPO-related snap-ins, then only allow access to the specific snap-ins that you want to expose to the user. You can do so by setting the policy called Restrict Users to explicitly permitted list of snap-ins under Computer Configuration, Administrative Templates, Windows Components, Microsoft Management Console. By enabling this policy, all MMC snap-ins are unavailable to users who are subject to the GPO on which the policy is set. If you then go into the Group Policy folder under this node, you can explicitly enable those GPO-specific snap-in extensions that you want to allow.

Q 5.4: Can I delegate administration for just a part of a Group Policy Object? A: In most cases, the answer is no, you cannot delegate one part (for example, folder redirection policy) of a Group Policy Object (GPO). Delegation is done at the whole GPO level by setting global security on that GPO. However, there are a few exceptions to this rule. Out of the box, individual applications within Software Installation policy can be permissioned separately from the whole GPO. This feature is useful for controlling which groups of users and computers will “see,” and thus process, the Software Installation policy for that application. But it’s also useful for controlling who can actually change the permissions on a particular application. To access security permission for an application that has been published or assigned using Software Installation, you simply double-click the application and select the Security tab (see Figure 5.10).

106

Chapter 5

Figure 5.10: Viewing the security permissions on an application deployed via GPO Software Installation.

Typically, when you’re trying to control which users or computers will process the application installation, you assign Read permissions to that target group. When you want to delegate the rights to modify the permissions on an application, you need to grant the Write permission. For example, suppose I want to grant the Finance Admins group the ability to change who can install the WinInstall LE package that Figure 5.10 shows. I would add the Finance Admins group to the access control list (ACL) that the figure shows, and grant them (at the least) Write permissions to the application. When a Finance Admins group member then wants to modify who has Read permissions to an application, the member can do so. Unfortunately, this functionality is really the extent to which you can delegate control of a GPO at a more granular level than the whole GPO. FullArmor’s FAZAM tool provides you with some ability to delegate Administrative Template policy by controlling who can access which .adm template files; but outside of that, you don’t have any other options. The best solution I have found for providing more granular delegation of GPO administration is a two-part solution. First, if you need to have different people or groups manage parts of a GPO, you should probably consider breaking that single GPO into multiple GPOs that are managed by the groups that need to manage them. Although this option will have a performance impact on your users and computers (more GPOs requires more time to process them), it can simplify administration of GPOs. So, for example, if the Finance Admins group needs to administer Software Installation policy in GPO A, and the Accounting Admins group needs to administer Administrative Template and computer security policy in GPO A, you have a problem if you 107

Chapter 5 don’t want the Finance Admins to also be able to modify Administrative Template and security policy. The reason for the problem is that both Finance Admins and Accounting Admins must have modify permissions on the whole GPO to modify their various pieces. And, after they have modify permissions on the whole GPO, there is nothing to keep them from modifying pieces that they shouldn’t. In this case, the best solution is to place the Software Installation policy settings in a new GPO, GPO B, that is only available to the Finance Admins group, and leave the Accounting Admins group to administer the remaining policy in GPO A. Finally, I will say that it is possible to delegate parts of a GPO using “unconventional” and unsupported means. Namely, it is possible to modify permissions on individual parts of the Group Policy Container (GPC) and Group Policy Template (GPT) to individually control who can do what within a single GPO. I mention this option only as an educational exercise because I wouldn’t recommend doing it in production. The reason is that things can get very complex if you try to control permissions on individual files within SYSVOL for the GPT (for example, setting the permissions on the registry.pol file to control who can change Administrative Template policy) or individual containers within Active Directory (AD) for the GPC (for example, modifying the permission of the Class Store container to control who can publish and assign applications). The problem with this approach, although technically feasible, is that it is easy enough to be undone if someone simply decides to re-apply permissions to a GPO at the whole GPO level. These permissions can easily be propagated down to the individual GPC and GPT sub-containers and folders and wipe out any custom changes you’ve made. As I said, it’s a nice academic exercise to know that you can do it, but I wouldn’t recommend doing it in anything but a test environment.

Q 5.5: How can I audit who has made a change to a Group Policy Object? A: Unfortunately, one of the limits of the Group Policy Object (GPO) infrastructure is that there is no really straightforward way to audit who has made which change to a GPO. What is required is that you set up Windows security auditing on the Active Directory (AD) and SYSVOL to be able to track who has made a change to the pieces of the GPO. It would be nice if Microsoft provided a way to audit GPO changes at the level that you think about when working with GPOs. In other words, I’d like to know if Joe Admin made a change to the Desktop Lockdown GPO, and if so, what that change was. Unfortunately, as a result of the structural nature of GPOs—the fact that they are really two “pieces” in the Group Policy Template (GPT) and Group Policy Container (GPC)—it is very difficult to audit GPO operations out-of-the-box because there isn’t any one thing that you can audit. However, I’ll show you how you can use native tools to achieve some level of auditing so that you can narrow who made which change to which GPO. First, you need to ensure that auditing is enabled on your AD domain controllers. Auditing is enabled on domain controllers by editing the special Default Domain Controllers Policy GPO that is installed by default in every AD installation and linked to the Domain Controllers organizational unit (OU). To enable AD auditing, start the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in, right click the Domain Controllers OU, and choose Properties from the context menu. Next, choose the Group Policy tab, highlight the Default Domain Controllers Policy, and click Edit. Within the GPO, drill into Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policies. From here, double click the Audit Directory Service Access item, select the Define 108

Chapter 5 these policy settings check box, then select the Success and Failure check box. (You don’t have to select the Failure option, but doing so will let you know who tried but failed to access a GPO.) Figure 5.11 shows what this configuration will look like.

Figure 5.11: Enabling AD auditing on the Default Domain Controllers Policy.

After you’ve enabled AD auditing and this policy has replicated and been processed on all domain controllers (and especially the PDC emulator), any changes you make to your GPOs will be audited. Enabling AD auditing only effectively catches access to the GPC portion of the GPO—not the GPT. However, this level of auditing is usually effective to track who is accessing a GPO, because the GPC and GPT are automatically accessed each time you open or edit a GPO using the MMC snap-in tools. What this auditing won’t catch is specific changes made to files within the GPT. For that, you need to enable the Audit Object Access item that Figure 5.11 shows, then enable auditing on the actual GPO. After you’ve enabled general auditing through the Default Domain Controllers Policy, you need to customize GPO auditing on a per-GPO basis to determine what kind of auditing is actually performed. By default, all GPOs are set up with the Everyone group enabled for a variety of access logging. Just to review, the process of setting up a System Access Control List (SACL) involves telling Windows for which user or group you want to log access and which operations you’re interested in logging. To access auditing settings within a GPO, you need to bring up the ACL editor on the GPO. If you are already editing the GPO, you can access the ACL editor by right-clicking the GPO’s name within the MMC snap-in tool, and choosing Properties from the context menu. Next, choose the Security tab, then click Advanced. Finally, click the Auditing tab to access the auditing SACLs window (see Figure 5.12). 109

Chapter 5

Figure 5.12: Viewing a GPO’s SACLs (auditing settings).

If I highlight the Everyone group in the window that Figure 5.12 shows, then click View/Edit, I can see which types of AD access are being audited, as Figure 5.13 shows.

Figure 5.13: Viewing detailed AD auditing options within the ACL editor.

110

Chapter 5 And, if I select the Properties tab in this dialog box, the tab will shows me which attributes on the GPC are being audited for access. If I am setting up auditing on a particular GPO that is linked to an OU, I might want to remove the Everyone entry from the auditing list and only audit access by the OU administrators who would regularly be accessing that GPO. Typically, when a change is made to a GPO with AD auditing enabled, there are event log entries written to the Security log on the domain controller on which the changes are being made (typically at the PDC emulator by default). Thus, you can go to that server after a GPO has been edited and view the logs to determine who has been in that GPO. For example, as Figure 5.14 shows, you see that the user administrator made a change to the GPC that has the GUID shown.

Figure 5.14: Viewing a security event log entry showing auditing of a GPO.

If I were to scroll down the description in the window that Figure 5.14 shows, you would see that the event shows that the administrator wrote a new value to the versionNumber attribute on that GPC. Such is the extent of the GPO auditing that is available to you within AD. You are left to determine which GPO is represented by that GUID, and what kind of change was actually made. In the latter case, you can glean a bit more info by enabling auditing on the SYSVOL portion of the file system that holds the GPT portion of a GPO. To enable file system auditing for GPOs, the best thing to do is log on to the PDC emulator in your domain and open Windows Explorer in %systemroot%\sysvol\sysvol\, where is the name of your AD domain. From this point, right-click the Policies folder, and choose Properties from the context menu. Next, choose the Security tab, and click Advanced. Finally, click Auditing to see what auditing has been enabled on this folder. Unlike the GPO itself, no auditing is set up by default on the Policies folder. 111

Chapter 5

You can also setup auditing of the GPT on a particular GPO by drilling into the Policies folder and locating the GUID-named folder of the GPO in question.

For my example, I’m going to enable auditing of the entire Policies folder for the group called Finance Admins. When I add this group to my list, I am taken to the list of available auditing options, from which I can choose which kinds of access to audit. As Figure 5.15 shows, I am most interested in auditing the activities that would cause a change in the files or folders that exist in the GPT for a given GPO, so I’ve selected the four entries shown.

Figure 5.15: Viewing options for enabling SYSVOL auditing of GPT changes.

After I enable this auditing on SYSVOL, any changes that a user makes to a GPO are tracked in the Security event log on all domain controllers in the domain, starting with the PDC emulator. In Figure 5.16, the user jadmin, a member of the Finance Admins group, made a change on a GPO that is recorded in the event log on the PDC emulator.

112

Chapter 5

Figure 5.16: Viewing an audit event generated on SYSVOL by a GPO change.

As you can see from the event, the user accessed and made some kind of change to the registry.pol file under the user subfolder of the GPT. This description tells me that jadmin made a per-user Administrative Template policy change to this GPO, though it does not tell me what the change was.

Q 5.6: What is the difference between deleting a Group Policy Object and deleting a Group Policy Object link? A: There is a significant difference between deleting a Group Policy Object (GPO) and deleting a GPO link—one is permanent and irreversible and the other merely disassociates a GPO from a container object. When you are in the Active Directory Users and Computers or AD Sites and Services Microsoft Management Console (MMC) snap-ins, you can focus on a container object, such as a site, domain, or organizational unit (OU), and see which GPOs have been linked to that object (see Figure 5.17).

113

Chapter 5

Figure 5.17: Viewing GPOs linked to a container object.

As you can see from Figure 5.17, there is a button that you can use to delete the selected GPO. However, if you click Delete, you will receive the prompt that Figure 5.18 shows.

Figure 5.18: Viewing the options to delete a GPO or its link.

The first option you see in this prompt lets you simply unlink the GPO from this container object—in my example here it’s the Finance OU. By unlinking the GPO, you simply disassociate from the container object—the OU. The GPO will no longer be processed by users and computers in this OU, but the GPO still exists in the domain and can be re-linked to another container object by clicking Add in the dialog box that Figure 5.17 shows.

114

Chapter 5 If you select the second option, you are doing two things: First, you are removing the link to the GPO from this container object. Second, and more permanent, you are actually deleting the physical GPO from the domain. That is, when you delete the actual GPO, you are deleting its constituent parts—the Group Policy Container (GPC) and Group Policy Template (GPT) from Active Directory (AD) and SYSVOL, respectively. After the GPO is deleted, you cannot recover it (unless you have recently backed up the System State on your domain controllers). This operation completely removes all vestiges of the GPO from AD. If the GPO that you’re deleting is linked to other container objects in your AD forest, those links will be removed as well. No orphan links will be left. Obviously, it’s important to choose the correct option when deleting a link (or the GPO), as the consequences can be difficult to recover from!

Q 5.7: How can I delegate administration of a Group Policy Object to users who reside in different organizational units? A: Although the answer to this question might seem straightforward, delegating administration of a Group Policy Object (GPO) to users in different organizational units (OUs) requires some thought and planning. Typically, you will want to delegate control of a GPO to a group of users, and so far we’ve only talked about groups of users that reside in the same OU. However, you can easily delegate administration of GPOs to a group of users (or other groups) that reside in multiple OUs and even multiple domains. This question is more about the capabilities of Active Directory (AD) groups than it is about GPO delegation, but it’s an important topic to discuss because it is likely to come up often throughout your AD and GPO administrative chores. As you know, you can delegate the ability to edit GPOs to user groups by adjusting the security access control lists (ACLs) on a GPO. Usually, you do so by granting a user, or more preferably a group, read and write permissions on that GPO. However, oftentimes the boundary that defines who can edit a GPO is not constrained to a single OU or even a single domain. You might have administrators spanning OUs and domains that all need the ability to edit a GPO. In that case, you can use some of the capabilities of AD groups to create “virtual OUs” for the purposes of delegating control of GPOs. For example, let’s assume that you have two administrators each in the Finance and Sales OUs within the Us.mycompany.tld AD domain. You also have two administrators in the corresponding Finance and Sales OUs within Europe.mycompany.tld. All eight of these administrators need to be able to edit the GPO that resides in Us.mycompany.tld called Mycompany Lockdown Policy. Figure 5.19 illustrates the layout of this domain.

115

Chapter 5

Figure 5.19: Viewing delegation of a GPO across domains and OUs.

As Figure 5.19 illustrates, for this example scenario, I’ve created a universal group that contains users (it could just as easily contain groups) from both AD domains. Then, I’ve used the universal group, called MyCompany Lockdown Admins, to permission the Mycompany Lockdown Policy GPO that is defined in Us.mycompany.tld. This setup is a very easy and effective way to create a virtual OU of administrators (using universal groups) who can then be granted permissions to various AD objects, such as GPOs.

Q 5.8: How can I view who has the rights to create Group Policy Objects in my domain? A: The process of granting who can create and edit Group Policy Objects (GPOs) is separate from the ability to link GPOs to container objects. You can easily view who has the rights to edit an existing GPO by viewing the security properties of that GPO in the Active Directory Users and Computers or Sites and Services Microsoft Management Console (MMC) snap-ins. But viewing who has rights to create a new GPO requires a little more work. Because GPOs are created within an Active Directory (AD) domain and contain two parts (the Group Policy Template—GPT—and the Group Policy Container—GPC), a user has to have the appropriate rights in the domain in which the GPO is created on both the GPT and GPC. The GPC is simply a set of objects in AD, and the GPT is a set of files and folders in SYSVOL. Thus, the ability to create a GPO in an AD domain is governed by the rights to create objects within the GPC portion of AD and the rights to create files and folders within the GPT portion of SYSVOL. The easiest way to see who has rights to create a GPO is to fire up the Active Directory Users 116

Chapter 5 and Computers MMC snap-in focused on your domain. From the View menu of the console, make sure you have selected the Advanced Features option to see all available containers in the domain. Navigate to the System container, and expand it to expose the Policies container (see Figure 5.20).

Figure 5.20: Viewing the Policies container within an AD domain.

The Policies container that Figure 5.20 shows is the parent container for all GPCs defined in the domain (the GPCs are the GUID-named folders you see in the right pane). It is the permissions on the Policies container that control who can create new GPC objects, and thus new GPOs, on the domain. So to find out who can create GPOs in your domain, right-click the Policies container, and select Properties from the context menu. Select the Security tab to view the current permissions on the container. Figure 5.21 shows the default permissions that exist on the Policies container in AD.

117

Chapter 5

Figure 5.21: Viewing the default permissions on the Policies container in AD.

If you examine the permissions on this container, you will notice that groups such as Administrators, Domain Admins, and Enterprise Admins all have the ability to create new GPOs, defined by the permission to Create All Child Objects. In addition, the Group Policy Creator Owners built-in group also has this permission (in fact, it’s the only permission this group has). Thus these groups can all create new GPOs, but some have more capabilities than others. For example, the Group Policy Creator Owners group can only create new GPOs, but Domain Admins and Enterprise Admins can create and delete GPOs, while members of the local Administrators group can only create but not delete, GPOs. Finally Authenticated Users have the Read permission only on GPOs. This setting makes sense because users (and computers) need to be able to read the GPC (or GPO) to process the GPO. You can also view the permissions within the GPT in SYSVOL to find out who can create new GPOs in a domain. The Policies folder under SYSVOL corresponds to the Policies folder under System that we just looked at. If you navigate to the Policies folder in Explorer, and view the NTFS permissions on that folder, you should see a slightly different set of users with a similar (albeit different because NTFS permissions are different than AD permissions) set of permissions. Figure 5.22 shows you what these permissions look like by default.

118

Chapter 5

Figure 5.22: Viewing the default NTFS permissions on the Policies folder within SYSVOL.

The Policies folder that Figure 5.22 shows is the parent folder to all of the GPTs defined within the domains. Because the permissions on the GPC parent folder and permissions on the GPT parent folder don’t correspond exactly, I find it best to look at the GPC permissions exclusively to determine who has the rights to create a GPO in an AD domain.

119

Chapter 6

Chapter 6: Tools for Managing GPOs Q 6.1: How can I create customized tools for my administrators who need to manage Group Policy Objects? A: The principal interface for editing Group Policy Objects(GPOs) is the Microsoft Management Console (MMC) Group Policy snap-in. Although the tool does not provide a tremendous amount of flexibility, you can use the customization features within the MMC to create some custom tools for your administrators. Create Locked Down Tools The MMC gives you the ability to create locked down “tools” (.msc files) that you can distribute to your administrators. The advantage of creating these custom tools is that you can expose only those management interfaces that a set of administrators needs to do their job. This feature can be useful for distributing GPO administration tasks as well. For example, instead of giving your administrators access to the Active Directory Users and Computers snap-in and expecting them to navigate to the correct container object in which the GPO they need to manage is linked, you can give them a custom MMC tool that exposes only the GPO or GPOs they need to manage. Let’s suppose you have a group of administrators that needs to administer three GPOs linked to your Active Directory (AD) domain. You want to create a tool that exposes only those three GPOs to them. Following these steps, you can create a custom MMC tool to accomplish this goal. 1. From the Start menu, select Run, and in the Run dialog box, type

mmc.exe

to bring up a blank MMC console. 2. From the MMC Console menu, select Add/Remove snap-in, and click Add. 3. From the list of available standalone snap-ins, navigate to Group Policy, and click Add. 4. From the Select Group Policy Object dialog box, click Browse to browse available GPOs

in your AD domain. 5. Select the GPO you want to add to the MMC console. Repeat steps 3 and 4 for all GPOs

you want to add. 6. Once you’ve added all the desired GPOs, you need to lock down the console tool so that

your administrators can’t change it once you give it to them. To do so, open the Console menu, and select Options. 7. From the Options dialog box, you can give your console a name and choose the mode

that the tool will be opened in. In this case, choose User mode—limited access, single window from the Console mode drop-down list. 8. Check the Do not save changes to this console check box, as Figure 6.1 illustrates, then

click OK to complete the option setting.

120

Chapter 6

Figure 6.1: Viewing the options for locking down an MMC console tool.

9. Finally, save the console file with a unique name (for example, GPOAdmins.msc).

You can then distribute the .msc file to your Group Policy administrators. Note that this .msc file can be run only from a Windows 2000 (Win2K) or Windows XP workstation. It cannot be run from a Windows NT 4.0 workstation.

The resulting tool looks like the one that Figure 6.2 shows.

Figure 6.2: Viewing the locked down MMC GPO tool created for GPO administrators.

121

Chapter 6 As you can see in Figure 6.2, the Console menu is no longer present. The administrator using this tool cannot add any other MMC snap-ins and basically can only administer the three GPOs listed. Limit Tools Even More You can provide an even more limited MMC console. For example, you might have a GPO that uses the software installation feature to deploy applications. To illustrate this point, suppose you have an administrator who is solely responsible for deploying software through that one GPO, and you don’t want to expose any other policy settings within that single GPO to the administrator. You can follow a slight variation of the earlier process to form such tool. First, follow steps 1 through 5 to add the GPO into a new MMC console. Once it’s been added, drill into the appropriate software installation node. With the software installation node highlighted, right-click and select New window from here on the context menu. Ensure that the software installation node window is maximized such that it takes up all the real estate on the MMC console and blocks visual access to any other policy settings within the GPO. Next, set the console options for the tool as Figure 6.1 shows to lock down what the user can do using the settings I showed in step 7. Then save the tool to an .msc file. Figure 6.3 shows what the resulting tool will look like.

Figure 6.3: Viewing a locked down GPO tool focused on a single policy function.

Using the tool that Figure 6.3 shows, users can neither modify additional GPO policy settings nor can they even tell which GPO they are setting software installation policy for. This setup can be useful when you need to delegate GPO administration tasks to a user who has little technical skill and just needs to follow simple directions to deploy software.

Q 6.2: Can I script the creation of Group Policy Objects? A: The short answer to this question is no. Neither Windows 2000 (Win2K) nor Windows XP allow you to script the creation or editing of a Group Policy Object (GPO). However, there are some scripting capabilities available related to GPOs.

122

Chapter 6 You can script the process of linking a GPO to a container object. This capability is available through the Windows Script Host (WSH) and the Active Directory Service Interfaces (ADSI) COM objects available in Win2K and Windows XP. The Microsoft article “Scripting the Addition of Group Policy Links” at http://support.microsoft.com/default.aspx?scid=kb;ENUS;q248392 provides a sample VBScript WSH script called gpollink.vbs, that lets you add (but not remove) GPO links to container objects. You have to modify the script to replace generic domain names (for example, mydomain.com) and server names (that is, all instances of servername) with your own domain name and the server name of the Primary Domain Controller (PDC) emulator for your Active Directory (AD) domain. You could choose any domain controller to make the change to the GPO link. But choosing the PDC emulator is preferable because GPO changes, by default, are always made against the PDC emulator role-holder. That script also leverages a Component Object Model (COM) object called IADSTools.DLL that is part of the Win2K Support Tools. IADTools.DLL is a library of functions that let you perform administrative scripting activities on AD and related objects. For example, the line in the script (modified to include my domain name and server name) Result=DLL.GetGPOs("mar-elia.com","DC1")

uses the IADSTools method called GetGPOs() to return a list of all GPOs defined in the domain called mar-elia.com. DC1 is the name of the PDC emulator for the domain that the function queries. The script then uses another IADSTools method called gponame() if lcase(DLL.gponame(i))=lcase(askGUID) then

to determine, of the GPOs found earlier, which GPO the user has chosen to link to the container. The script then uses ADSI to modify the gPLinks attribute on the container object defined by the variable called SDOU to add the new GPO link. By default the script is set up to link GPOs to the domain level, by virtue of the following statement: Set SDOU=GetObject("LDAP://DC1/dc=mar-elia,dc=com")

However, you can also use the script to add links to organizational units (OUs) or sites by simply modifying this statement. For example, if I want to add a GPO link to an OU called Finance, I would modify the statement to look like the following example: Set SDOU=GetObject("LDAP://DC1/OU=Finance,dc=mar-elia,dc=com")

With the text OU=Finance, the new part of this statement. If I want to link to a site, the process gets a bit trickier because sites are found in a different Lightweight Directory Access Protocol (LDAP) path from domains and OUs. Suppose I have a site called SanFrancisco to which I want to link a GPO. The syntax for the statement would look like the following example: Set SDOU=GetObject("LDAP://DC1/ CN=SanFrancisco,CN=Sites,CN=Configuration,dc=mar-elia,dc=com")

The SanFrancisco site is located within the Configuration naming context of the domain marelia.com. Thus, the LDAP path to the site looks a bit different from the domain and OU examples. Now let’s run the script to see how it works. From the command line, simply type cscript gpollink.vbs

to invoke the script. The first thing the script does is return a list of GPOs it has found in the domain, as Listing 6.1 shows.

123

Chapter 6 C:\> cscript gpollink.vbs Microsoft (R) Windows Script Host Version 5.1 for Windows Copyright (C) Microsoft Corporation 1996-1999. All rights reserved. Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9} Default Domain Controllers Policy {6AC1786C-016F-11D2-945F-00C04fB984F9} Desktop Lockdown Policy {FE43AA62-AF7D-40CD-A27C-01384938FB53} The SDOU you will be modifying is: LDAP://DC1/CN=SanFrancisco,CN=Sites,CN=Configuration,dc=marelia,dc=com Successfully added a link to this SDOU for the GPO (Desktop Lockdown Policy) Listing 6.1: Viewing the output from the gpollink.vbs script.

The script also returns the path to the container object to which you’re linking. Next, you’re prompted by a pop-up input box to enter the friendly name of the GPO that you want to link to. The friendly name is the name that you see when you’re editing the GPO (for example, Desktop Lockdown Policy) rather than the globally unique identifier (GUID) name of the GPO. Assuming that the script finds the name of your GPO, it creates the link on the container object and returns a success message. This script only adds GPO links to a container object—it does not remove them. However, with some clever string manipulation, you could modify the same script to do the removal process as well. The link that builds the gPLink attribute currentGPLIST=currentGPLIST & "[LDAP://CN=" & DLL.gpoguid(i) & ",CN=Policies,CN=System," & DLL.getdefaultnamingcontext("Yquem") & ";0]"

could be manipulated using the regular expression function within WSH to remove the GUID for the chosen GPO. Expect later releases of Windows as well as third-party products to provide the ability to script the creation and editing of GPOs. This ability will most likely come in the form of Windows Management Instrumentation (WMI) objects that allow script-based manipulation of GPOs.

Q 6.3: Which tool can I use to force Group Policy Object processing from the command line? A: Windows 2000 (Win2K) offers only limited capability to force Group Policy Object (GPO) processing from the command line. Win2K comes with a command-line tool called secedit.exe. Ostensibly, secedit.exe is part of the security configuration toolset, but when you run secedit on a Win2K device, it can force a reprocessing of GPO settings. For example, using the command

124

Chapter 6 Secedit /refreshpolicy machine_policy

forces the computer to reprocess all machine-specific GPOs that affect that computer. (If you use user_policy instead of machine_policy, user-specific GPOs are processed.) Of course, by default, GPOs that have not changed since the last processing cycle will not be reprocessed by the computer, but nevertheless, secedit can trigger reprocessing. GPO policy items such as folder redirection and software installation are not actually triggered to run using secedit. These extensions cannot run via a background refresh, and thus aren’t triggered just by using secedit. Windows XP includes a new command called gpupdate.exe that allows more complete support for refreshing GPO-based policy. With gpupdate.exe, we get a more full-featured command-line mechanism for triggering GPO processing. Gpupdate lets you target a refresh of user or machine policy just as secedit does. In addition, gpupdate provides options that let you force a refresh of all policy settings, regardless of whether the GPO has changed since the last processing cycle. You can also use gpupdate to handle those policy settings—such as software installation and folder redirection—that require a system restart or user logoff/logon in order for those policies to be applied. Listing 6.2 shows the command-line options available to gpupdate.exe. Syntax:

GPUpdate [/Target:{Computer | User}] [/Force] [/Wait:]

[/Logoff] [/Boot] [/Sync] Listing 6.2:Viewing the syntax for the gpupdate tool.

The force option, as I mentioned, lets you force GPO processing to occur for all applicable policy settings even if the GPO(s) did not change since the last time it (or they) was processed. The Wait option simply lets you tell gpupdate how long, in seconds, to hold control of the command shell before releasing it back to the user. This option does not control how long GPO processing actually takes, but rather tells gpupdate to not relinquish command until either the time you specify has expired or all GPO processing has completed. The Logoff option instructs gpupdate to process all applicable GPOs and, if there are any policies that require a logon event to actually become visible, this option forces a user to logoff. Similarly, the Boot option does the same thing for policies that require a system restart (such as machine-based software installation). After all applicable GPOs are processed, if a reboot is required, the system will reboot. Finally, the Sync option is a very useful one in that it lets you override asynchronous GPO processing (also known as fast logon optimization in Windows XP) for the next processing cycle only. By calling the Sync option, the next time a computer starts or a user logs on to a machine, all applicable GPOs process synchronously (one after the other) rather than in parallel. This feature is useful if you suspect that asynchronous processing is causing problems and you need to test that fact. Finally, it’s important to note that even though secedit and gpupdate provide command-line mechanisms for refreshing policy, such refreshes are still logged in the Application event log as they would be during normal GPO processing.

125

Chapter 6

Q 6.4: Can I create a tool that gives me a consolidated view of all my Group Policy Objects at once? A: Yes, using the features of the Microsoft Management Console (MMC), you can easily create a tool that gives you access to all of your Group Policy Objects (GPOs) within a single view. I find it very useful to be able to have a single view of all the GPOs that I need to manage, regardless of where they’re linked within my Active Directory (AD) infrastructure. As you know, using the Active Directory Users and Computers or AD Sites and Services MMC snap-in tools, you usually have to hunt around to get to each GPO in which you’re interested. By creating a custom MMC console that shows all the relevant GPOs in a single view, you can save time and ensure that you are always working on the right GPOs. The following step-by-step instructions describe how you can create such a tool: 1. To begin, open a blank MMC console by typing

mmc

from the Start menu Run dialog box in either Windows 2000 (Win2K) or Windows XP. 2. From the Console menu in Win2K (File menu in Windows XP), choose Add/Remove

Snap-in, then click Add. 3. Scroll down the list of available snap-ins to the Group Policy snap-in, and click Add. 4. When you get to the Select Group Policy dialog box, click Browse to search for a GPO in

your AD. If you don’t know where the GPO(s) of interest are linked, choose the All tab to show all GPOs defined in AD (see Figure 6.4).

Figure 6.4: Viewing all GPOs defined in an AD domain.

5. Select a GPO to add from the list, and click OK, then click Finish. 6. Before returning to the console, add another Group Policy add-in, and repeat Steps 4 and

5 for the rest of the GPOs you want to manage. 7. When you’ve added all instances of GPOs to manage, click OK from the Add/Remove

snap-in dialog box.

126

Chapter 6 8. The final step is to save your tool. From the Console menu (or File menu in Windows

XP), choose Save, then give the tool a name. The resulting file will have an .msc extension. Figure 6.5 shows a consolidated GPO management tool (called MYGPOs.msc) that I created.

Figure 6.5: Viewing a consolidated GPO management tool using the MMC.

As you can see in Figure 6.5, I have five GPOs loaded in my tool. Each of these GPOs may be, and indeed are, linked at different levels of the AD hierarchy but are visible and available to me within this single MMC window. I can expand and edit each GPO as I would normally, and have all the GPOs of interest available next to the others if I need to compare one or the other. I can also use the MMC’s Favorites feature to store frequently used views of each of the GPOs. For example, let’s suppose that I frequently need to go in and modify the user-specific Windows Explorer policies within the Administrative Templates policy in the Desktop Lockdown GPO. I can create a favorite that takes me quickly to this policy item by first expanding into the required node (in this case User Configuration, Administrative Templates, Windows Components, Windows Explorer). Then, from the Favorites menu on the MMC toolbar, I can choose Add Favorites to add this policy item to the Favorites list (see Figure 6.6).

Figure 6.6: Adding a favorite policy to the MMC Favorites list.

127

Chapter 6 I can use this favorites feature for any type of policy within my console tool. After I’ve created my favorites, I can use the Favorites tab to navigate quickly and easily right to the policy item I need to edit. For example, in Figure 6.7, I’ve created three favorites, which I’ve named first by identifying the GPO, then by the policy item.

Figure 6.7: Using MMC favorites to navigate quickly to policy items of interest.

As you can see in Figure 6.7, the actual policy items appear in the right-hand results pane when I highlight each favorite. This feature is super handy for frequently edited GPO settings, and I highly recommend pre-creating these custom MMC tools for GPO administrators. It will make your lives much easier over time!

Q 6.5: Do I have any control over how quickly the SYSVOL (Group Policy Template) portion of a Group Policy Object is replicated to other domain controllers? A: The short answer to this question is that you have limited control over SYSVOL replication, as compared with Active Directory (AD) replication. The File Replication Services (FRS) is used to replicate SYSVOL to domain controllers in an AD domain. FRS relies on inter- and intra-site AD connection objects that are built by the Knowledge Consistency Checker (KCC) to replicate content between domain controllers. However, FRS content will not necessarily replicate on the same schedule as AD objects. Often, between domain controllers within sites, file replication happens very quickly, as soon as a file has changed and the domain controller has notified its replication partners. Between sites, replication is typically scheduled based on the Site Link configuration found in the Microsoft Management Console (MMC) AD Sites and Services snapin tool. Depending upon how many files have changed and the schedule you’ve created for AD site links, you might experience delays before FRS data is in sync everywhere. Unfortunately, you don’t have much control over the actual replication topology or the schedule that is used to replicate changes. Unlike AD replication, for which you can use the AD Sites and Services snap-in to force a replication trigger between domain controllers, FRS doesn’t provide that kind of interface. You are pretty much at the mercy of FRS to replicate SYSVOL content when files change and based on your AD site topology. Also be aware that prior to Windows

128

Chapter 6 2000 (Win2K) Service Pack 2 (SP2), FRS does not compress file changes when replicating between sites, as AD does. What little you can tweak in FRS is the schedule as to when FRS replication can and cannot occur. To change this schedule, open the Active Directory Users and Computers MMC snap-in, make sure that the Advanced view is enabled, and within your AD domain, drill into System\File Replication\Domain System Volume (SYSVOL Share). If you right-click this node and select Properties from the context menu, the system will present you with the SYSVOL properties dialog box. In this window, click Change Schedule to bring up the SYSVOL schedule, as Figure 6.8 shows.

Figure 6.8: Viewing the FRS replication schedule for SYSVOL.

If you select a square or range of squares in the window that Figure 6.8 shows, you can toggle replication on or off during certain times of the day. This feature gives you some flexibility if you’re replicating large numbers of SYSVOL changes and have slow links that you want to remain available during business hours. You could schedule SYSVOL replication to happen after hours in that case. Of course, that means that any changes you make to your GPOs would not be synchronized across all domain controllers until SYSVOL replication is allowed to happen. There is also a utility that you can use to check the status of FRS replication. It is called ntfrsutl.exe and is included in the Win2K resource kit. This tool lets you view the “metadata” on a particular domain controller to see its state and the state of replication on that server. Ntfrsutl.exe was updated in Win2K SP2 with some improvements for getting information from FRS. To get this version, you need to extract the full SP2 installation using the /x command, then copy the new version of the utility over the old one.

129

Chapter 6

Q 6.6: Can I get information about the Group Policy Objects in my domain via scripts? A: In a previous chapter, I mentioned that currently there is no way to script the edit or creation of Group Policy Objects (GPOs). However, there is a useful scripting tool that lets you easily access information about your GPOs. The name of the tool is IADSTools.DLL, and it comes as part of the Windows 2000 (Win2K) Support Tools. IADSTools.DLL is a COM object that can be called from Windows Script Host (WSH) scripts. To use IADSTools, you first need to register the DLL on any machine on which you plan to run scripts. Registering the DLL is easy; to do so, simply type regsvr32 iadstools.dll

and the DLL is registered in HKEY_CLASSES_ROOT for use by your scripts. After the DLL is registered, it exposes several methods for performing all kinds of Active Directory (AD) and GPO-related tasks. For our purposes, we’ll just focus on the GPO-related methods. Table 6.1 shows the GPO-related methods and their purpose. IADSTools Method Name

Purpose

GetGPOVersion()

Returns the version number of a GPO as held in the Group Policy Container (GPC—within AD).

GetGPOSysVolVersion()

Returns the version number of a GPO as held in the Group Policy Template (GPT—within SYSVOL).

GetGPOs()

Returns a list of GPOs found on a given domain controller. The list can be enumerated using the following two functions (GPOName() and GPOGuid()).

GPOName()

Returns the friendly name of a GPO as retrieved using GetGPOs().

GPOGuid()

Returns the globally unique ID (GUID) of a GPO as retrieved using GetGPOs()

GPOVersion()

Returns the GPC version number of a GPO as retrieved using GetGPOs(). Note that this function is different than GetGPOVersion() as it requires GetGPOs() to be run to enumerate a collection of GPOs prior to being called.

GPOSysVolVersion()

Returns the GPT version number of a GPO as retrieved using GetGPOs(). Note that this function is different than GetGPOSysVolVersion() as it requires GetGPOs() to be run to enumerate a collection of GPOs prior to being called.

Table 6.1: Viewing the methods available in IADSTools.DLL to query GPO information.

130

Chapter 6 Now let’s look at how you might use IADSTools methods to query information in GPOs. The following script compares the GPC and GPT versions of a GPO and reports back if they are out of sync. Listing 6.3 shows a script that uses the GetGPOVersion and GetGPOSysVolVersion methods to check the versions on a GPO (the line numbers have been added to the strict to aid in this discussion). 1. Set objIADS=CreateObject("IADsTools.DCFunctions") 2. objIADS.EnableDebugLogging(3) 3. strdomain="mar-elia.com" 4. strDC="yquem" 5. strGUID="{D5D09664-0319-4BEC-97B2-5AC31B75D09B}" 6. GPCVer=objIADS.GetGPOVersion(cstr(strdomain),cstr(strDC), cstr(strGUID),0) 7. GPTVer=objIADS.GetGPOSysVolVersion(cstr(strdomain),cstr(strDC), cstr(strGUID),0) 8. Wscript.echo "GPC Version is: " & GPCVer 9. Wscript.echo "GPT Version is: " & GPTVer 10. if GPCVer GPTVer then 11. Wscript.Echo vbCRLF & "Versions are out of sync" 12. else 13. Wscript.Echo vbCRLF & "Versions are in sync" 14. End if Listing 6.3: Viewing a WSH script that compares GPC and GPT versions for a GPO.

In Listing 6.3, I start off in line 1 by instantiating the IADSTools object, which is required in every IADSTools script. In line 2, I’ve called the EnableDebugLogging method, which sends all activity related to the script to the Application event log on the system on which the script runs. I’ve simplified things by hard coding the domain name, domain controller, and GPO GUID that I want to query in lines 3, 4, and 5. You can just as easily pass these into the script using command-line arguments. Lines 6 and 7 do the hard work, which is to call the two version methods and retrieve version info. Lines 8 and 9 report out the version numbers found and, if they are different, the following code in lines 11,12, and 13 reports that they are different. Figure 6.9 shows a sample output of the script running twice—once with GPO versions in sync and once when they’re not.

131

Chapter 6

Figure 6.9: Viewing the output of the GPO version checking script.

Now let’s look at a script that enumerates the GPOs on a particular domain controller and tells us some information about the GPOs. Listing 6.4 shows such a script (again, the line numbers have been added for this discussion). 1. Set objIADS=CreateObject("IADsTools.DCFunctions") 2. objIADS.EnableDebugLogging(3) 3. strdomain="mar-elia.com" 4. strDC="yquem" 5. arrGPOs=objIADS.GetGPOs(cstr(strdomain),cstr(strDC)) 6. For x = 1 to arrGPOs 7. Wscript.Echo "GPO NAME: " & objIADS.GPOName(x) 8. Wscript.Echo "GPO GUID: " & objIADS.GPOGUID(x) 9. Wscript.Echo "GPC Version #: " & objIADS.GPOVersion(x) 10. Wscript.Echo "GPT Version #: " & objIADS.GPOSysvolVersion(x) & vbCRLF 11. Next Listing 6.4: Viewing a script that uses the GetGPOs function to retrieve a list of GPOs on a domain controller.

The script in Listing 6.4 starts off similar to the script in Listing 6.3. I have decided to hard code the domain and domain controller name into the script as before. Line 5 calls the GetGPOs function, which stores the number of GPOs found on the domain controller in the variable called arrGPOs. In line 6 through line 11, I use a For…Next loop to go through each GPO and get information from it, which is then printed to the screen in lines 7, 8, 9, and 10. Figure 6.10 shows the output from this script.

132

Chapter 6

Figure 6.10: Viewing the output of an IADSTools script that enumerates all GPOs on a domain controller.

As you can see, the IADSTools DLL can provide some handy capabilities for scripting version health checks on your GPOs. Using the previous scripts, you could check version information of each GPO on every domain controller in your environment and easily report errors to a log or to email.

Q 6.7: How can I add or remove particular policy extensions within the Group Policy Object editor tool? A: Although the ability is not readily exposed, you can create a Microsoft Management Console (MMC) tool for Group Policy editing that simply does not contain certain policy extensions (for example, folder redirection, IP security policy, and so on). Although this capability really belongs to the MMC, your question highlights a fact about how the Group Policy editing tools are implemented. Each policy capability within the default Windows 2000 (Win2K) and Windows XP installations has two pieces. The first is the client-side extension (CSE), which is a DLL that actually processes Group Policy Object (GPO) settings and applies them to the user or computer. The other piece is the DLL that gives administrators the capability to create policy 133

Chapter 6 settings within a GPO—the editing tools for GPOs. Each policy capability, such as Administrative Templates, Security Settings, Software Installation, and Folder Redirection is implemented in a separate DLL. Likewise, the DLLs for editing those capabilities are implemented as separate DLLs—specifically MMC extension snap-ins. Usually when you load a GPO into an MMC tool, all extensions are included by default, and thus you will see all the available policy capabilities. However, it is possible and very easy to create a custom MMC tool that exposes only certain MMC extensions, and thus only lets the user edit certain portions of a GPO. This approach contrasts with the feature that lets you use Administrative Template policy to physically prevent a user from loading certain MMC GPO extensions within an MMC tool. In the approach that I discuss here, you’re not preventing the use of the extensions if the user knows how to get to them. You are simply taking them out of the user interface (UI) so that they aren’t obviously visible if not needed. Let’s see how this works. The MMC differentiates between standalone snap-ins and snap-in extensions. A standalone snap-in is one that can be loaded into an MMC console on its own and does not require any other supporting snap-ins. Snap-in extensions, however, cannot be loaded on their own and require a standalone snap-in to be loaded first to “host” them.

The first thing you need to do is to open a blank MMC console. Next choose Add/Remove Snapins from the Console menu (or the File menu in Windows XP), and add the Group Policy standalone snap-in. You’ll need to choose a GPO to focus on as you add it to the console. After you’ve completed adding it to the console, you will see a dialog box similar to the one that Figure 6.11 shows (in this case, focused on the local GPO in Windows XP).

Figure 6.11: Viewing an MMC console tool with the Group Policy snap-in loaded.

134

Chapter 6 Usually, you simply click OK in this dialog box, then start editing the GPO. However, in this case, we’re going to select the Extensions tab to view which extensions have been loaded (see Figure 6.12).

Figure 6.12: Viewing the loaded extensions within the Group Policy snap-in.

As you can see, all extensions are typically loaded by default when you load the Group Policy snap-in. However, if you clear the Add all Extensions check box, you can select which extensions you want to expose in this console tool. For example, suppose that I have a GPO tool that I want to create to give to my GPO administrators. It will be a tool focused on the local GPO, but I don’t want to include any Public Key policy options because I don’t use Public Key in my infrastructure. To do so, I am going to select Security Settings from the Snap-ins that can be extended drop-down text box. When I choose this snap-in, the list in the Available extensions section changes to show me which MMC extensions can be run within the parent snap-in. To disable the Public Key security policy extensions, I simply clear the Public Key Policies check box (see Figure 6.13), and the option will not be included when I save this MMC tool.

135

Chapter 6

Figure 6.13: Excluding Public Key policies from an MMC Group Policy tool.

As a result, when an administrator goes to edit the local GPO using my tool, the administrator will no longer see an option for Public Key policies under User Configuration, Windows Settings, Security Settings (see Figure 6.14).

Figure 6.14: Viewing an MMC GPO tool with the Public Key policies extension removed.

You can, of course, use this approach to remove any number of extensions. If you select Group Policy from the Snap-ins that can be extended drop-down list, you can pick or choose any of the policy nodes that are available within a normal GPO editing tool and can even remove major nodes such as Administrative Templates (users or computers or both).

136

Chapter 6

Q 6.8: What is the difference between the Local Security Policy tool and using gpedit.msc to edit the local Group Policy Object? A: Simply put, the Local Security Policy tool that you find in the Administrative Tools Start menu group on Windows 2000 (Win2K) and Windows XP is a narrowed view of the local Group Policy Object (GPO) that can be accessed using the Microsoft Management Console (MMC) tool called gpedit.msc. The Local Security Policy tool (see Figure 6.15) is called as an MMC tool named secpol.msc.

Figure 6.15: Viewing the Local Security Policy MMC tool.

If you’re familiar with GPO-based security policy, you will notice that Figure 6.15 looks identical to the Security Settings node within a Group Policy under Computer Configuration, Windows Settings, Security Settings. What you don’t see in Figure 6.15 is any of the parent nodes within a normal GPO, such as the Windows Settings or Computer Configuration nodes. You also don’t see any mention of which GPO you’re focused on. In fact, the view you see in Figure 6.15 is simply a stripped down, focused view of the local GPO that you can view in its entirety by launching gpedit.msc (see Figure 6.16).

137

Chapter 6

Figure 6.16: Viewing the local GPO from the gpedit.msc MMC tool.

As you can see in Figure 6.16, the nodes under Security Settings are identical to those shown in the Local Security Policy tool. It’s as if the Local Security Policy tool has “re-rooted” the Security Settings node to be the root of a new window. In fact, that is exactly what is happening. Try this experiment. Open a blank MMC console by typing mmc

in the Start menu Run dialog box, select File (or Console for Win2K MMC users), Add/Remove snap-in, and load the Group Policy snap-in focused on the local computer. You’re now viewing the local GPO, just as gpedit.msc shows it to you. Now, navigate to Computer Configuration, Windows Settings, Security Settings, right-click the Security Settings node, and select New Window from Here from the context menu (see Figure 6.17). Look familiar? It’s pretty much the same view that you see in the Local Security Policy tool.

138

Chapter 6

Figure 6.17: Viewing a new window on the local GPO focused on Security Settings.

The main difference between the view in Figure 6.17 and the Local Security Policy tool is that in the figure, there are more menu choices along the top of the tool. Namely, the Favorites and Window menu items are missing from the Local Security Policy tool. What you’re witnessing is a feature of the MMC that lets an MMC tool author “lock-down” a particular console configuration to provide a focused set of administrative tasks for the user. In my tool that Figure 6.17 shows, if I were to select File (or Console for Win2K MMC users), Options from the console menu, and change the mode of the console from Author Mode to User Mode-Limited Access, single window (see Figure 6.18), then save the tool to an .MSC file, the next time I load that tool, it will look identical to the Local Security Policy tool.

139

Chapter 6

Figure 6.18: Changing the options on an MMC tool from author mode to user mode.

Indeed, the Local Security Policy console tool that Microsoft provides is just a Group Policy MMC snap-in focused on the security settings node in the local GPO and saved in user mode to prevent the user from loading other MMC snap-in extensions that show the other parts of the GPO. You can actually easily override a tool saved in user mode and revert it back to author mode by simply launching the .MSC file with the /a option: Secpol.msc /a

After you do so, you’re free to modify the tool, add other MMC Group Policy extensions, and so on. User mode is not hard security on a tool but simply a way of keeping a user from futzing with settings that the user isn’t responsible for managing.

140

Chapter 7

Chapter 7: Advanced GPO Features and Functions Q 7.1: How can I view the internals of a Group Policy Object? A: A Group Policy Object (GPO) is composed of two parts—the Group Policy Container (GPC) and the Group Policy Template (GPT). You can see the contents of these two pieces by using some very simple tools. The ability to view the “guts” of a GPO can give you good insight into how this complicated infrastructure works. The GPC is an object in Active Directory (AD) that contains several settings related to its corresponding GPO. The GPT is a set of folders and files that are stored under the SYSVOL share on an AD domain controller. Every GPO has exactly one GPC and GPT. The key value that identifies a GPO and its constituent GPC and GPT is its globally unique ID (GUID)—a 128-bit value that gets assigned to the GPO when it is created. SYSVOL is replicated to every domain controller in an AD domain. Thus, the GPT and the GPC for a given GPO also get replicated to every domain controller. Locate the GUID Let’s look at how you can examine the GPT and GPC of a GPO. First, we’ll start by examining a GPO to determine its GUID. You can easily do so by following these steps. 1. Start either the Active Directory Users or Computers or Active Directory Sites and

Services Microsoft Management Console (MMC) snap-in. 2. Right-click the container object (the site, domain, or organizational unit—OU) in which

the GPO you want to examine is linked. Choose Properties from the context menu. 3. Select the Group Policy tab, and highlight the GPO you want to examine. 4. Click Properties, and you will see a dialog box similar to the one that Figure 7.1 shows.

Figure 7.1: Viewing the unique name for a GPO from its properties dialog box.

141

Chapter 7

As you can see in Figure 7.1, the highlighted Unique name is the GUID for this GPO. Make a note of the GUID as we move to examine the GPO’s GPC and GPT.

Navigate to the GPC Now that we know the GUID for our GPO, we can look at its constituent parts. The easiest way to examine the GPC is to use a familiar tool—the Active Directory Users and Computers MMC snap-in. Follow these steps to view a GPO’s GPC. 1. Start the Active Directory Users and Computers MMC snap-in. Select the View menu on

the console, and ensure that the Advanced Features option is selected. 2. Expand the domain list within the left pane of the tool, then expand the System container. 3. Within the System container there is a container called Policies. Expanding this container

should reveal a series of containers named with GUIDs. 4. Locate the GUID that you identified in the series of earlier steps for your GPO, and

expand that container, as Figure 7.2 shows. This GUID-named folder is the GPC for the GPO.

Figure 7.2: Viewing the GPC from within the Active Directory Users and Computers tool.

142

Chapter 7 If you were to examine the AD attributes on the GUID-named folder that Figure 7.2 shows, you would see several properties related to the GPO, including its current internal version, the path to its GPT in SYSVOL, and its friendly name—the name you see when you’re browsing for GPOs. In Figure 7.2, you can see two folders underneath the GUID-named folder—machine and user. These two folders correspond to the computer and user nodes that you see when you edit a GPO using the Group Policy MMC snap-in tool. If you expand either of these folders, you may see a subfolder called Class Store and a folder underneath that called Packages. The Class Store and Packages folders are present if you have set any software installation policy within the GPO. The Class Store is an AD object that keeps information related to how the package was published or assigned and where the Windows Installer setup file is located for the application. Determine the GPT Now lets look at the GPT. As I mentioned, the GPT is located within SYSVOL—the replicated folder structure present on every AD domain controller. The easiest way to view the contents of SYSVOL is to log on to the console of a domain controller in your AD domain, select Run from the Start menu, and in the Run dialog box, type \\\sysvol

This action will open an explorer window with a subfolder that will show the name of your current domain. If you open this folder, you should see the three folders that Figure 7.3 shows.

Figure 7.3:Viewing the contents of SYSVOL.

If you select the Policies folder, you will see a list of GUID-named folders similar to that found when we examined the GPC. If you open the same GUID-named folder that we did when we were looking at the GPC, you will likely see the subfolders and files that Figure 7.4 shows. The contents of this GUID-named folder make up the GPT for the GPO.

143

Chapter 7

Figure 7.4: Viewing the GPT for a GPO in SYSVOL.

Just as with the GPC, you see machine and user folders corresponding to machine- and userspecific policy that is set within the GPO. In addition, the ADM folder contains any Administrative Template .adm files associated with this GPO. Each GPO can have its own separate and distinct set of .adm Administrative Template files. This ability is different than Windows NT 4.0 System Policy, which lets you use only a single set of .adm files within a domain policy.

You also see a file called GPT.INI. This file contains the internal version number for this GPT. When a computer or user processes a GPO, this version number is compared to the one contained with the properties of the GPC to determine whether the GPO has been replicated correctly to all domain controllers within a domain. If the version numbers don’t match, the GPO is considered out of sync, and is thus not processed. If you were to drill further into the machine and user files, you would see any number of subfolders and files corresponding to each of the various policy areas within a GPO (for example, Administrative Templates, Security, Folder Redirection). The GPT is the storage mechanism for the actual settings you make within the GPO when you edit it. If you make a change to a GPO setting, that change is stored within the GPT. The one exception to this behavior is that software installation, as I mentioned earlier, uses the GPC’s class store mechanism as well as the GPT to store settings related to the policy.

144

Chapter 7

Q 7.2: What is loopback policy and how does it work? A: Loopback policy is a special mode of Group Policy Object (GPO) processing. It provides for a way of overriding user-specific GPO policy when a user logs on to a particular computer that is subject to loopback. Loopback policy is particularly useful for computers that function as kiosks and for terminal servers. Specifically, loopback gives you a way of overriding a user’s default Group Policies by using a Group Policy defined for the particular computer to which they log on. Active Directory (AD) users will normally log on to their own workstations and receive a set of computer- and user-specific GPOs based on where their computer and user accounts are located in AD. However, sometimes those users might need to log on to specialized computers that exist elsewhere within an AD domain and that have special restrictions that apply only to those computers—such as a kiosk or terminal server. Typically, computers that are subject to loopback are placed in a separate organizational unit (OU). Then a GPO is created and linked to that OU that enables loopback processing. You enable loopback by setting an Administrative Template policy located in both Windows 2000 (Win2K) and Windows XP under Computer Configuration, Administrative Templates, System, Group Policy. The policy item is called User Group Policy loopback processing mode, as Figure 7.5 shows.

Figure 7.5: Viewing the setting that enables loopback processing on a computer.

When you enable loopback processing, you have the option to choose two modes of operation— replace or merge. I will describe what each of these means shortly. When a computer is set to process GPOs using loopback, all users who log on to that computer might no longer receive any 145

Chapter 7 user-specific GPO settings derived from where their user account is located (the exception to this is when you select to merge user policies—as I’ll described later). For example, take a user named jsmith whose account and principal workstation both reside in the Finance OU. A number of GPOs are linked to the Finance OU that deliver user-specific policy settings for jsmith, such as desktop lockdown, folder redirection, and software installation. Now, suppose jsmith logs onto a kiosk computer located in an OU called Kiosk. All computers that reside in Kiosk process GPOs using loopback. What this setting means is that when jsmith logs onto the kiosk computer, he will no longer receive the user-specific policy settings that he would receive if he logged onto his account that resides in the Finance OU. Instead, any userspecific policies set by GPOs linked to the Kiosk OU will now take the place of jsmith’s “home” policies. So, for example, you might decide to set a special desktop lockdown setting through userspecific Administrative Template policy when users log onto a kiosk machine. Likewise, you might not want a user’s desktop folder to be re-directed using Folder Redirection policy when that user logs onto a kiosk. Mechanically what happens is that when the user logs onto a computer using loopback policy, the user’s “home” policies are removed, and the user-specific policies defined in the GPOs linked to the OU where the loopback machines reside are applied instead. When the user returns to his or her normal workstation, the loopback policies are removed and the user’s home policies are restored. Loopback policy processing is also useful in terminal server environments because you might need to lock down a user’s desktop far more restrictively when the user is logging onto a machine that is shared by many other users. In that case, loopback is an ideal solution. The replace and merge functions of loopback that I mentioned earlier control how the userspecific settings provided by the loopback GPOs are applied. In replace mode, all the user’s previous GPO-based settings are removed and the loopback policy settings are applied. In merge mode, both the user’s normal policy settings and the loopback policy settings are combined. If there are conflicts between the user’s normal settings and loopback settings, the loopback settings “win” and are applied. In most cases, I recommend using the replace mode, as it can get extremely confusing to predict the resulting user policy when using merge mode.

Q 7.3: How can I change the path to a deployed application’s .msi file once I’ve published or assigned the application? A: Changing the path is not easy and might not be worth it for you! Ordinarily, when you publish or assign an application using Group Policy Object (GPO)-based software installation, you cannot go back from the GPO editor tool and change the path you assigned to the .msi file that installs the application. Your only choice is to delete and re-add the deployed application. However, you can directly edit the Group Policy Container (GPC) object within Active Directory (AD), then follow a series of steps to change the path to the file. Although this mechanism is not supported by Microsoft, it does work and is useful to know if you need to change a fair number of applications and don’t want to have to delete them and start over. However, you will have to use the redeploy feature within software installation, which results in anyone who has received the application to date having it reinstalled on their next GPO processing cycle.

146

Chapter 7 To use this trick, you need to have installed the Windows 2000 (Win2K) Support Tools, which contains the ADSI Edit Microsoft Management Console (MMC) snap-in tool. Let’s walk through this technique with an example. Figure 7.6 shows that I’ve created a GPO that deploys the Win2K Administration Tools as a published application.

Figure 7.6: Viewing an application deployed via GPO.

When I published this application, I entered the path for the .msi file package that installs it. That path was a share on my server: \\yquem\packages\adminpak.msi. After the application is published (or assigned), the path to the package is not exposed anywhere. However, using ADSI Edit, I can directly edit the AD attribute that controls where that package is found. Here are the steps to follow to edit this application’s path: 1. From the Group Policy editor tool, right-click the name of the GPO, and select Properties

to view the GPO’s globally unique ID (GUID). Make a note of the GUID. 2. Start the ADSI Edit MMC tool (adsiedit.msc) and, if you aren’t already, connect to the

domain naming context for your domain. 3. Under the domain naming context, drill down into the CN=system, CN=policies folder

and locate the folder that corresponds to the GUID of your GPO, as Figure 7.7 shows.

147

Chapter 7

Figure 7.7: Viewing the GUID folder of a corresponding GPO in ADSI Edit.

4. After you’ve located the GUID, you will see a machine and user subfolder. In our case,

because we are editing user-based software installation, I will expand the user folder to reveal a CN=Class Store subfolder. If you expand the Class Store subfolder, you will expose a CN=Packages folder that contains one or more GUID-named objects of class packageRegistration (see Figure 7.8). Each packageRegistration object corresponds to a deployed application within the GPO.

Figure 7.8: Viewing packageRegistration objects within a GPO.

148

Chapter 7 5. Double-click the desired packageRegistration object. (If there is more than one, you will

need to determine which one is the application you need to modify. To do so, doubleclick the object, and, from the drop-down list of properties for the object, choose displayName to see which application you’re editing). 6. After you’ve located the correct application, choose the msiFileList property to see the

list of current file paths for your application. You will notice that this list can have multiple values. The reason is that if the original path was a distributed file system (Dfs) share, the GPO will cache all the available replicas under the share where the package can be found. 7. To edit a path value, select the value to edit, and click Remove to move the path into the

edit attribute dialog box (see Figure 7.9).

Figure 7.9: Editing the path to an .msi file in the deployed application.

8. You can now edit the path, being careful to leave the numeric reference (in Figure 7.9,

the reference is 0:) in place. After you’ve edited the reference to point to a new path, click Add to commit it to the property. 9. The next step is to temporarily relocate the Application Advertisement Script (.aas file)

that was created when you first deployed the application. This .aas file contains hardcoded references to the old .msi file path. For my example, the .aas file is located in SYSVOL under policies\\user\applications (see Figure 7.10). Move this .aas file out of the SYSVOL folder on the server acting as the PDC emulator within your domain.

149

Chapter 7

Figure 7.10: Viewing the .aas file that is created when a GPO-based application is deployed.

10. Next, go back to your deployed application within the GPO editor tool. Right-click the

application name, choose Tasks from the context menu, then choose Re-deploy Application. You will receive a failure message—acknowledge it. 11. If you go back to the SYSVOL folder from Step 10, you’ll see a new .aas file, called

temp.aas, has been created. Delete this file, and move the old .aas file back into this folder. 12. Again, return to the GPO editor tool and redeploy the application one more time. You

should not receive any errors, and the application will now be installed from the new location! You may very well be thinking that this process is too much work to go through just to change an application’s deployment path. That may be true, but there may be reasons why you can’t simply delete and re-add an application. In that case, this technique works.

Q 7.4: How do I use software restriction policy in Windows XP? A: Software restriction policy is new to Windows XP and gives you unprecedented control over which applications a user can run on a Windows XP desktop. Software restriction policy does not exist in Windows 2000 (Win2K) clients or earlier versions of the Windows desktop OS. It can be found in Windows XP under User Configuration, Windows Settings, Security Settings, Software Restriction Policies. To access software restriction policy on a local machine, select Administrative Tools from the Start menu, then select the Local Security Policy Microsoft Management Console (MMC) tool. Software restriction policy provides a very powerful and proactive tool to help you combat common Windows-specific viruses as well as prevent your users from executing certain types of files. Figure 7.11 shows this tool as it appears in an Active Directory (AD)-based Group Policy Object (GPO).

150

Chapter 7

Figure 7.11: Viewing software restriction policy in a Windows XP or Windows .Net GPO.

If you right-click the software restriction policies node, and select Create New Policies from the context menu, two new folders, called Security Levels and Additional Rules, are created under the node. In addition, three new policy items are listed off the root node. These new policy items are called Enforcement, Designated File Types, and Trusted Publishers. Let’s look at each of the features within the software restriction policies and what they do: •

Security Levels—Under the Security Levels node are two policies, Disallowed and Unrestricted (this setting is an either/or setting). By default, Unrestricted is set as the default state, but if you double-click the Disallowed item, and choose Set as Default then this “arms” the software restriction policy. After Disallowed is set, no software will run for any end user who is subject to that policy (unless you make exceptions, as we’ll see later).

•

Additional Rules—The Additional Rules folder lets you set up four kinds of rules to control which types of files your users can execute. Rules override any default security behavior set up in the Security Levels node. To access the rules, right-click the Additional Rules folder, and choose a rule from the context menu (see Figure 7.12).

151

Chapter 7

Figure 7.12: Viewing the available software restriction rules.

Let’s look at what each of these rules does: •

Certificate Rules—This option lets you choose a public key certificate, then lets you set whether software signed by that certificate is allowed or disallowed. For example, if you deploy a set of .vbs scripts in your environment, you could sign those scripts with a public key certificate, then only grant your certificate as allowed. If a user then gets a script file that’s not signed by you, the certificate rules will prevent the script from running.

•

Hash Rules—Similar to Certificate Rules, Hash Rules lets you specify that certain files with unique hash values can either run or are disallowed from running. Hash values are unique values that are derived by taking information about a file’s size, date and timestamp, and other information to create a fingerprint of that file. Figure 7.13 shows an example of a hash rule for which I simply chose to disallow a particular .gif file of a specific hash value. You can manually enter a hash value rather than letting the rule dialog box create one from a known file. This feature is useful if you’ve found a virus file that has a well known hash value that you want to restrict.

152

Chapter 7

Figure 7.13: Using a hash rule to prevent a file from being executed (or opened).

•

Internet Zone Rules—Internet Zone Rules are used to set blanket policies from which Internet zones (for example, Intranet, Internet, Trusted Sites, Restricted Sites) your users may run Windows Installer packages. Internet Zone Rules are specific to Windows Installer (.msi files) packages only.

•

Path Rules—Path Rules let you specify disallowed or unrestricted execution policy for certain folders or files on your users’ hard drives. For example, as Figure 7.14 shows, you might specify a directory (in which mail attachments are typically stored) as disallowed as a way of preventing rogue mail attachments from executing. For example, Outlook XP will store attachments in a user’s profile under %userprofile%\Local Settings\Temporary Internet Files prior to executing the attachment. You could create a path rule to that subdirectory, then any files located within or under it will not execute. (Path Rules support the use of environment variables such as %userprofile%.)

153

Chapter 7

Figure 7.14: Viewing a software restriction path rule.

The final three global options within software restriction policies are Enforcement, Designated Files Types, and Trusted Publishers. The Enforcement option lets you decide whether you want to include DLLs within the possible types of files that are restricted by the rules you set. By default, DLLs aren’t included, and if you do include them, you will need to spend a lot of time figuring out which DLLs needed by approved software should be excluded from the restrictions. Within the Enforcement screen, you can also specify whether members of the local workstation (or server) Administrators group are subject to software restriction policies (see Figure 7.15).

Figure 7.15: Viewing the Enforcement options in a software restriction policy.

154

Chapter 7 The Designated File Types policy lists all file types that are subject to the Certificate Rules and Path Rules previously described. So if you allow applications signed by a particular certificate, it will cover all file types (file extensions) listed in this section. You’ll notice that the default file types listed are common types of “executable” code such as .exes, batch files, and Windows Script Host (WSH) scripts, as well as common viral vectors such as .shs and .scr files. The designated file types are global settings and apply to all software restriction policies that don’t otherwise specify a particular file type. Finally, the Trusted Publishers policy lets you control who can specify a trusted publisher and lets you specify that you want to check with a certificate authority to see whether the publisher has been revoked before allowing an application to run. As you can see, software restriction policy is an extremely powerful new feature in Windows XP that allows you to have very fine-grained control over what your users can and cannot do. This ability can really come in handy as a second line of defense against viruses, especially when your antivirus vendor has not yet have come up with a patch for a new virus.

Q 7.5: Can a client machine disable the processing of a Group Policy Object? A: There is no switch or registry entry that you can throw to easily disable Group Policy Object (GPO) processing for a machine in an Active Directory (AD) domain that is destined to receive GPOs. However, there are some drastic steps that you can take to disable some or all GPO processing. To understand how you can disable GPO processing, we will explore how GPOs are actually processed. The real workhorse of GPO processing actually resides on the client side. That is, although AD domain controllers house the Group Policy Container (GPC) and Group Policy Template (GPT) that contain the actual policy settings for a given GPO, the code on the client— Windows 2000 (Win2K) or Windows XP—actually reads those settings and does something with them. That code is called a Client Side Extension (CSE), and is found by default on every Win2K and Windows XP workstation. CSEs are implemented as dynamic-link libraries (DLLs) and are typically found in %systemroot%\system32 on a machine. Win2K and Windows XP also keep a list of registered CSEs for a given machine within the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. Each CSE is registered as a key under the GPExtensions key, as Figure 7.16 shows.

155

Chapter 7

Figure 7.16: Viewing registered CSEs on a Win2K machine.

As you might also notice from Figure 7/16, each CSE also keeps a set of default behaviors that control how it processes GPOs. For example, the NoGPOListChanges value controls whether that CSE will process a GPO even if its version number has not changed since the last processing cycle. Win2K and Windows XP use this list of CSEs in the registry to determine which policy features to process. Thus, in Figure 7.16, if I were to delete the key shown, which, as you can see from the right pane of the registry editor, controls the Folder Redirection feature, that workstation would no longer be able to process Folder Redirection policy. The same holds true for other policy processing. If I delete the key that begins with “{8273D19E…”, I will be disabling security policy processing on that workstation, and thus preventing any security policy from being passed down to the workstation. You must be an administrator on the local machine to actually delete these keys. Thus, as long as you’re not granting users administrative access to your workstations, they won’t be able to use this mechanism to foil your security and other GPO-based controls.

There are better ways to prevent a workstation from processing a GPO. As an administrator, you can permission the GPO such that the user or machine does not ever get to process the policy. However, there may be circumstances in which, from the client side, you might need to disable some or all GPO features. By manipulating which CSEs are registered on a workstation or server, you can control which policy features are processed.

156

Chapter 7

Q 7.6: How do I enable Windows XP policies in a Windows 2000 Active Directory domain? A: Windows XP introduces quite a few new Group Policy Object (GPO)-based Administrative Template settings as well as some new policy functionality—such as software-restriction policies. If you’re deploying Windows XP clients in a Windows 2000 (Win2K)-based Active Directory (AD) domain, you can “upgrade” your AD-based GPOs to support the new policies. Remember that the actual processing “smarts” behind a GPO are stored in so-called Client Side Extensions (CSEs) on the workstation or server that is processing the GPO. As such, it makes complete sense that Windows XP comes with newer or more capable policies than those found in Win2K. So if you want to deploy Windows XP in your existing Win2K AD domain, how do you take advantage of those new policies without breaking policy on your Win2K machines? It’s quite simple really. The first thing you need to do is to be able to open GPOs using the standard Microsoft Management Console (MMC) snap-ins that you are used to in Win2K. Unfortunately, the server management tools, such as Active Directory Users and Computers and AD Sites and Services that are part of the Win2K Administration Tools Pack, no longer work in Windows XP. As of this writing, the only way you can manage AD-based GPOs on a Windows XP machine is to download and install the .NET Server Beta 3 Administration Tools Pack .MSI file from Microsoft’s Web site. The .NET Server Beta 3 administration tools for Windows XP can be found at http://www.microsoft.com/downloads/release.asp?ReleaseID=34032&area=search&ordinal=9.

After you’ve installed the Beta 3 administration tools, you’re ready to convert your existing ADbased GPOs into Windows XP–capable policies. The process is very straightforward. All you need to do to upgrade your GPOs, is to open each GPO in your AD domain using the Group Policy MMC snap-in tool running on a Windows XP workstation. The act of opening the GPO upgrades it to be able to support Windows XP–based policies; at the same time, your Win2K policies are still intact. You need to perform this GPO open process on every GPO within your AD domain that you want to support XP clients. What’s happening behind the scenes during this process is pretty straightforward. Remember that the Group Policy Template (GPT) portion of a GPO holds the actual files and settings that represent the current policy that has been set. When you open a GPO using Windows XP, Windows XP uploads the newer .adm Administrative Template files into the Adm folder within the GPT for that GPO (see Figure 7.17).

157

Chapter 7

Figure 7.17: Viewing the Adm folder within a GPO’s GPT.

This process of opening the GPO automatically enables Administrative Template policy that is Windows XP–specific to be set within that GPO. Windows XP introduces the SUPPORTED tag into Administrative Template .adm files. This tag lets the client determine whether the policy is meant for its version of the OS or a newer one. If you try to set an Administrative Template policy that is only meant for Windows XP but that is processed by Win2K workstations, the individual policy item (not the entire GPO) will simply be ignored. Another thing to keep in mind is that after you’ve upgraded your GPOs to be Windows XP– capable, you aren’t limited to editing them on Windows XP clients. You can continue to edit them using either Win2K or Windows XP administration tools.

Q 7.7: How is Group Policy Object history stored and used on the client? A: The default behavior of Group Policy Object (GPO) processing is that a client will not process a GPO if the GPO has not changed since the last processing time. But how does the client know whether the GPO has changed? The answer is that the client knows by using GPO History.

158

Chapter 7 GPO History is nothing more than a set of keys and values in the registry on Windows 2000 (Win2K) and Windows XP systems in which a history of GPO processing is kept. This history is stored both a per-user and per-computer basis, corresponding to the fact that GPOs have both computer- and user-specific parts. The per-computer history can be found in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History subkey. And the per-user history is in the corresponding key in HKEY_CURRENT_USER: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. Under the History keys, you fill find a number of GUID-named keys. These keys correspond to the various client-side extensions (CSEs) that implement policy on a given machine. You can cross-reference these CSE GUIDs to the actual policy function they provide by looking in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions subkey. Under each GUID-named key is the numerically named subkeys that correspond to each GPO that the computer or user has processed for a given CSE (see Figure 7.18).

Figure 7.18: Viewing the contents of GPO History stored in the registry on a Win2K computer.

In Figure 7.18, the keys named 0 and 1 under each CSE key correspond to the GPOs that have been processed by this computer. If I select one of these numbered folders, I can see more detail about the GPO and its version when last processed. Figure 7.19 shows what this looks like.

159

Chapter 7

Figure 7.19: Viewing the detailed history information for the last processing of a GPO.

What Figure 7.19 shows: •

This system ran the Scripts CSE (defined by the GUID in the left pane beginning with {42B5F…) against the Default Domain Controllers policy.

•

The DSPath value points to the Machine folder underneath the Group Policy Container (GPC) for this GPO and the FileSysPath value points to the Machine folder within the Group Policy Template (GPT) for this GPO.

•

The Extensions value lists all the CSEs that are implemented within this particular GPO (that is, which types of policy have been set in the GPO) by their CSE GUID.

•

The GPOLink value describes where in AD or on the local computer this particular GPO was linked to when it was processed. The number 4 corresponds to an OU-linked GPO. A number 1 in this value corresponds to the local GPO, 2 to a site-linked GPO, and 3 to a domain-linked one.

•

The GPOName is, of course, the friendly name of this GPO.

•

The Link value shows the full AD path to where this GPO was linked when it was processed—in this case, to the Domain Controllers OU.

•

IParam is an optional value that is used by some CSEs.

•

The Options value shows whether No Override or Disabled flags have been enabled for this GPO.

160

Chapter 7 •

The Version value shows the current version of this GPO. This is the version number stored in the GPT and GPC, not the number of revisions on the GPO. This version number is key because it helps the user or computer know whether the GPO has changed on subsequent processing cycles. If it has not changed and the default processing behavior has not been modified, the GPO will be skipped for this CSE until the version number does change.

As you can imagine, the per-user and per-computer history keys provide a valuable service not only in determining whether a GPO has changed from the last processing cycle, but also in helping Win2K and Windows XP know when a GPO no longer applies to the user or computer. In this case, policy settings that no longer apply can successfully be removed during the next policy processing cycle.

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? A: Yes, Windows .NET Server will provide an additional filtering capability with Group Policy. In addition to being able to filter the effects of Group Policy based on user or computer groups, you will be able to create Windows Management Instrumentation (WMI) queries that provide the ability to dynamically filter GPO effect based on WMI parameters such as hardware configuration, software configuration, and so on. WMI is a set of management providers that ships in Windows 2000 (Win2K) and Windows XP that provides very detailed management information about your Windows systems. WMI is Microsoft’s implementation of the Web-Based Enterprise Management (WBEM) initiative created by the Desktop Management Task Force (DMTF). The ability to filter the effects of a Group Policy Object (GPO) based on WMI information is very powerful. You could, in effect, filter GPO processing based on how much memory a particular computer has or whether a particular application is installed on a computer. If you view a GPO from within the Microsoft Management Console (MMC) Group Policy editor on a Windows .NET Server, you will see a new tab on the GPO’s properties page—called WMI Filter (see Figure 7.20). This tab lets you select a WMI Query Language (WQL)-based query to associate with the GPO.

161

Chapter 7

Figure 7.20: Viewing the option in Windows .NET Server to filter a GPO using a WMI query.

If I click Browse/Manage, I can select an existing query or create a new one. Figure 7.21 shows an example of a WMI query filter that I created on a GPO.

Figure 7.21: Viewing a WMI query created on a GPO.

162

Chapter 7 In Figure 7.21, I have created a WMI query filter that checks the time zone of the computer that processes the GPO. Only machines with a time zone of Pacific Standard Time will process this GPO as a result of the query filter. The format of the query that Figure 7.21 shows is a standard WQL query (SELECT * from Win32_TimeZone WHERE StandardName=”Pacific Standard Time”), pre-pended by the root namespace in WMI (Root\CIMv2). You need to specify that root namespace unless you plan to query another namespace within WMI. Most queries that you are likely to perform will use the CIMv2 namespace. Although a full discussion of WMI and WQL are beyond the scope of this book, an excellent resource for learning about WMI is Marcin Policht’s WMI Essentials for Automating Windows Management (SAMS).

When using WMI filters to filter the effects of a GPO, you will need to keep in mind the performance impact of these WMI queries. The WMI queries are performed dynamically on the computer on which the GPO is being processed. This operation is expensive from a CPU perspective. Thus, a good practice is to use WMI filtering only on those rare occasions in which you really need to filter a GPO based on a parameter specific to the computer that can’t be represented within a regular computer-based group.

163

Chapter 8

Chapter 8: Troubleshooting GPOs 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? A: As I mentioned in Chapter 7 Question 7.1, a Group Policy Object (GPO) is composed of a Group Policy Template (GPT) and Group Policy Container (GPC). These two pieces are replicated to all domain controllers in your Active Directory (AD) domain on separate replication mechanisms. Thus, if a GPO gets out of sync, it will not be processed by a computer or user. GPOTool.exe You need a way to determine whether a GPO has not replicated correctly. There are a couple of quick and easy tools you can use to do so. The Windows 2000 (Win2K) resource kit contains a command-line tool called GPOTool.exe that verifies the consistency of one or more GPOs within your domain across all domain controllers. Suppose I want to determine whether a GPO called HQ Lockdown Policy on a particular domain controller called YQUEM is in sync. I can issue the following GPOTool command to run the check: gpotool /gpo:"HQ Lockdown Policy" /dc:yquem

Figure 8.1 shows the results of this command.

Figure 8.1: Viewing errors found in GPO synchronization using the GPOTool resource kit tool.

164

Chapter 8 In Figure 8.1, GPOTool has found a GPO version mismatch between the GPC (referred to as DS version for directory service in the figure) and the GPT (referred to as Sysvol version). In some cases, version mismatch problems may point to a problem with either AD or SYSVOL replication. If GPOTool shows a version-mismatch problem, check the System and Directory Services event logs on the domain controller showing the problem. Also, check other domain controllers using GPOTool or Replmon.exe, which I describe next, to see if the problem is more widespread. Replmon.exe In addition to GPOTool, the Win2K and Windows XP Support Tools contains a GUI-based tool called Replmon.exe. This tool is a graphical utility for viewing the status of a variety of ADbased replication issues. One of its side benefits is that it also reports on GPO replication status on a per-domain controller basis. Follow these steps to check GPO replication status on a domain controller: 1. Start the Replmon.exe tool from the Support Tools folder. If you haven’t already added a

domain controller to monitor, right-click the Monitored Servers node in the left pane, and select Add Monitored Server. 2. Click Next, then type in the name of the server explicitly. After typing the server name, click Finish. Your domain controller will appear under the name of the site in which it is located, as Figure 8.2 illustrates.

Figure 8.2: Viewing a monitored domain controller within the Replmon tool.

165

Chapter 8 As you can see, in the right pane of Figure 8.2, the replication status of the GPOs stored on the domain controller called Yquem is shown. You can get a better view of this status by rightclicking the server name, and selecting Show Group Policy Object Replication Status. A window similar to the one that Figure 8.3 shows will appear.

Figure 8.3: Viewing GPO replication status from within Replmon.

As you can see in Figure 8.3, there is an X by the HQ Lockdown Policy, indicating that the GPC and GPT are out of sync. You can also see that they’re out of sync to the right—the version numbers are different (the Version column represents the GPC and the SysVol Version column represents the GPT). Replmon is a good tool for giving you a view of all GPOs on a given domain controller. You can also add domain controllers to the Replmon monitor list, and view GPO status across many domain controllers. GPOTool and Replmon are complimentary tools that together help you keep an eye on GPO replication status across your infrastructure.

166

Chapter 8

Q 8.2: How can I use event log entries to troubleshoot Group Policy Object problems? A: In Question 2.1 in Chapter 2, I showed you how you can enable verbose Group Policy Object (GPO) event logging in the Windows Application event log. You can use the event log entries created by this logging to determine where problems are occurring in your GPO processing infrastructure. The key to using GPO event logging is to know how to read the entries that are generated. When a computer starts up, in the Application event log, you will see a number of entries that have a source of Userenv. These entries represent one of the main sources for GPO processing. You can trace the whole path of computer and user GPO processing, from start to finish, fairly easily because event log entries are created at the start and finish of each policy processing cycle (see Figure 8.4).

Figure 8.4: Viewing the start message for computer-specific GPO processing in the Application event log.

Each major step in the GPO processing cycle triggers an event log entry. For example, Figure 8.5 shows the step in which the computer has identified all GPOs to which it is subject (including the local GPO, which is always processed first).

167

Chapter 8

Figure 8.5: The computer has enumerated all the GPOs that it must process.

Where event logging really comes in handy is during the actual processing of GPOs, when entries are generated to describe exactly what’s happening during the processing cycle. For example, in Figure 8.6, the computer has checked the GPOs it must process and has found that none of them have changed since the last time they were processed. Therefore, the computer simply skips processing those GPOs.

Figure 8.6: The computer has not found any changed GPOs, so it skips processing them.

168

Chapter 8 Of course, Userenv is not the only process that will show up as the owner of GPO processing events. In Figure 8.7, a GPO-defined logon script that should have been found was not found, and thus triggered an error that has a source of UserInit—the process responsible for running logon scripts.

Figure 8.7: Viewing an error of source UserInit—a logon script was not found.

In Win2K, you will often see error codes associated with a GPO event log entry. For example, you might see a message that includes error codes and flags. The message will say something to the effect of The operation generated error # xx and returned flags # yy. These messages might seem cryptic and not very well defined, but they indeed correspond to real error codes in Windows. Specifically, the error codes correspond to Win32 error codes, which you can find in the Microsoft Platform software development kit (SDK) in a file called winerr.h or you can find them in a downloadable Excel file found at http://www.microsoft.com/windows2000/techinfo/reskit/ErrorandEventMessages/default.asp. The flag codes are specific to Group Policy, and can also be found in the Platform SDK, within a file called userenv.h. Fortunately, as Figure 8.8 shows, Windows XP does a much better job of detailing the errors behind the error codes and flags than Win2K does.

169

Chapter 8

Figure 8.8 Viewing the GPO event entries in Windows XP.

As Figure 8.8 shows, Windows XP is much better that Win2K is at detailing how to find out why something isn’t working in GPO processing. However, interestingly, Windows XP marks all the GPO-related event log processing entries as error messages, rather than just informational messages in the event logs. This classification can be disconcerting when you start looking at the event logs and see a sea of red x’s. Just be aware that when you open the message, it might or might not be a critical error worthy of concern.

Q 8.3: What is the best way to determine whether security policy is being delivered to a workstation or server? A: The answer to this question depends to some degree upon whether you’re using Windows 2000 (Win2K) or Windows XP. Which tool you use to validate that you’re receiving security policy depends upon the extent of information you need. For example, in Win2K, you can use some built-in tools to determine which are your effective security settings on a workstation or server, but these tools won’t tell you which Group Policy Object (GPO) delivered those settings. To get that basic information, you simply fire up the local GPO editor—gpedit.msc—and view security settings. As Figure 8.9 shows, the local GPO editor shows you the local and “effective” settings for a given security policy.

170

Chapter 8

Figure 8.9:Viewing local and effective security settings on a GPO.

Local settings are those defined on the local machine. If effective settings are different than local settings, a GPO has delivered some alternative settings that take precedence over the local ones. You can also use GPO logging (discussed in Question 8.2) to see which GPOs are delivering security policy, but you can’t see what those policies are for each GPO. In Win2K, if you need to see which GPO is delivering which security policy, you really need to look to third-party tools such as FullArmor’s FAZAM 2000. However, in Windows XP, the story gets a bit better. The gpresult.exe command-line tool that comes with Windows XP has the ability to resolve security settings (the Win2K version does not) and the Resultant Set of Policy (RSoP) MMC snap-in tool (stored as rspop.msc) that comes with Windows XP also has the ability to view effective security settings. Of course, in Windows XP, you can still look at the local GPO to see the current effective security at the workstation or server.

171

Chapter 8

Q 8.4: How can I determine whether Domain Name System problems are affecting my Group Policy Objects’ functionality? A: Domain Name System (DNS) problems are just one of the things that can cause Group Policy Object (GPO) failures. There are several quick and dirty tools you can use to determine whether DNS is causing your problems. Correct GPO processing relies on the ability for a Windows 2000 (Win2K) or Windows XP workstation (or server) to contact an Active Directory (AD) domain controller and make several queries. The system uses the Lightweight Directory Access Protocol (LDAP) to determine where GPOs are linked in AD’s hierarchy and where the Group Policy Containers (GPCs) are for each GPO that is found. To correctly locate the LDAP service on a domain controller in the workstation’s site, DNS is used to query for the SRV record called _ldap._tcp.._sites.dc._msdcs., where is the name of the site the workstation resides in and is the name of the AD domain where that machines resides. If you’re having DNS problems that prevent the workstation from resolving this name, GPO processing will fail, and that failure manifests itself in no GPO processing occurring. The confounding thing about this problem is that it is still possible for the user to successfully authenticate to the domain and logon as if there were no problems. Such usually occurs in domains in which NetBIOS over TCP/IP (NetBT) is still enabled and the Windows Internet Naming Service (WINS) is still in use. Although DNS is not working correctly, the workstation can still use WINS and NetBT to authenticate the user to the domain. However, crucial DNS information required for GPO processing is missing. There are usually two main reasons why DNS-related GPO problems occur. The first is that the domain controllers in your AD domain are not correctly registering all their SRV records with DNS. This process is supposed to be automatic, in which domain controllers use dynamic DNS (DDNS) to register all appropriate records when they come up. However, sometimes this registration does not happen, and in that case, the records are never found. If that turns out to be a problem, you can try running the command Ipconfig /registerdns

from any domain controller having problems. You can also try stopping and restarting the Netlogon service on the problem domain controller, which will usually re-register all appropriate SRV records in DNS. Check out the Microsoft article “SRV Records Missing After Implementing Active Directory and Domain Name System” (Q241505) for more tips about fixing missing SRV records.

The other reason there may be DNS problems is that the client machine may not be able to contact DNS or may be contacting the wrong DNS servers. There could be several reasons for this behavior, including network problems, bad DNS client configurations, or an incorrect DNS server configuration. In any case, you can easily troubleshoot the problem by using the nslookup utility.

172

Chapter 8 Like its UNIX counterpart, nslookup is an important tool for validating DNS client operation. To check whether a client is successfully finding the key SRV record needed for proper GPO operation, simply start nslookup by typing nslookup

at a command prompt. When you reach the nslookup shell, you need only type the name you’re trying to resolve and, if successful, nslookup returns the IP address for the name (see Figure 8.10).

Figure 8.10: Viewing a successful search for the LDAP SRV record in AD.

If the name is not found, you know you’re having DNS issues and need to look either to the server or to the client’s configuration to resolve the problem.

Q 8.5: Why am I having trouble enabling security policy such as auditing and event log settings on my domain controllers? A: There is an interesting interplay between the built-in Default Domain Policy and Default Domain Controllers Policy that can cause confusion when trying to enforce domain-wide security policy. Security policy is a tremendous source of confusion within Active Directory (AD), and the cause of many perceived problems. However, the rules are fairly straightforward, and as long as you stay mindful of them, you won’t have any problems. The first rule is: Domain-wide account policy can only be set at a Group Policy Object (GPO) linked to the domain. Typically the Default Domain Policy is used to set account policy because Default Domain Policy is a special system GPO and can never be deleted. However, you can set account policy in any GPO that is linked at the domain level. Domain controllers, regardless of where they reside in your AD (within the Domain Controllers organizational unit— OU—or elsewhere), will only look to domain-linked GPOs to get their account policy. You can set other account policy for member servers elsewhere in your AD infrastructure, but domain controllers will only respect domain-linked account policy. The second rule is just as useful: By default, the Domain Controllers OU is set to block policy inheritance (see Figure 8.11), meaning that no “upstream” GPOs can override security policy set within GPOs linked to this OU.

173

Chapter 8

Figure 8.11: Viewing the Block Policy Inheritance feature enabled on the Domain Controllers OU.

The exception to this rule is the first rule—Account policy cannot be set at the Domain Controllers OU level, only at the domain level. All other security policy for the domain should be set in the Default Domain Controllers Policy GPO or another GPO linked to the Domain Controllers OU, including audit policy, event log policy, services security, and so on. The bottom line is that if you try to enable local policies such as auditing for your domain on any GPO other than the ones linked to the Domain Controllers OU, those policies will never be processed due to the Block Policy Inheritance check box being selected on that OU. You will save yourself a lot of troubleshooting time trying to figure out why you’re domain controllers don’t have auditing enabled by setting auditing policy on a GPO linked to the Domain Controllers OU. You might think that you can simply disable the Block Policy Inheritance option on the Domain Controllers OU to allow security policy to be set elsewhere. In fact, you can’t! If you disable this option, security policy processing on domain controllers in that OU will simply fail with an SCECLI event and error flag of 81 (as the Application event log with verbose GPO logging enabled will show). This feature prevents any “rogue” GPOs upstream from the Domain Controllers OU from undoing any local security policy for your entire domain. But it can cause confusion when you believe that you’re disabling the Block Policy Inheritance feature and the only error you get is that none of your upstream policies seem to be applied.

174

Chapter 8

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? A: Usually, this outcome is the result of a permissions issue; you might have sufficient permissions to view a Group Policy Object (GPO) link but not to actually edit the GPO. Figure 8.12 shows an example of a message you might see when trying to edit a GPO.

Figure 8.12: Viewing an inaccessible GPO.

The error—inaccessible GPO-Access Denied—is typically caused by the fact that the user who is trying to edit that GPO does not have Read permissions on the GPO. In this case, the access control list (ACL) on the GPO didn’t contain the Authenticated Users group, which normally has Read permissions as a minimum setting on all GPOs. Figure 8.13 shows this GPO’s ACL, which doesn’t contain the Authenticated Users group, resulting in the error.

175

Chapter 8

Figure 8.13: Viewing the ACL on a GPO that results in an inaccessible error.

Special care needs to be taken when removing the Authenticated Users group permission from a GPO. By removing this permission, you effectively prevent all users from being able to read, and thus process a GPO. A user receiving an inaccessible error message can sometimes be a good thing. For example, if the GPO controls security on your domain, you probably don’t want a user account that doesn’t process machine-specific security GPO in the first place to even be able to see it, let alone edit it. You’ll also note that in Figure 8.12, the Edit button is grayed out, indicating that the user doesn’t have write permissions on the GPO either. Permission problems can be tricky, but typically the problem comes down to overlooking a simple granting (or removal) of permissions to straighten things out.

176

Chapter 8

Q 8.7: When I try to edit a Group Policy Object, I get an error message that says the domain controller is not found. DNS isn’t the problem, what else could it be? A: This problem is a known issue when trying to edit Active Directory (AD)-based Group Policy when Microsoft File and Print Sharing has been disabled on the PDC role holder in your domain. Because the ability to edit a Group Policy Object (GPO) relies on File and Print Sharing (and specifically file services) to be available, this service needs to be running in order for you to be able to successfully edit a GPO. Remember that, by default, the Group Policy Microsoft Management Console (MMC) snap-in tries to connect to the PDC emulator within your AD domain first when opening a GPO. If File and Print Sharing services are not running on the PDC role holder, you might get a message similar to the one that Figure 8.14 shows.

Figure 8.14: Viewing the error message you receive when you try to edit a GPO while File and Print Sharing services are disabled.

If you choose one of the other options that Figure 8.14 shows, you might get another error message, as Figure 8.15 shows.

Figure 8.15: Viewing the error message presented after the Group Policy snap-in fails to find a domain controller to connect with.

177

Chapter 8 After you receive the error message that Figure 8.15 shows, a curious thing will happen. If you try to view the GPOs in your domain from that Active Directory Users and Computers MMC snap-in, the list of GPOs linked to a particular container will appear empty; very disconcerting! The quick and easy solution to this problem is to verify that File and Print Sharing services are enabled on the PDC role holder in your domain (at the least). To do so, bring up the network connections applet—I like to simply type ncpa.cpl from a command line in Windows 2000 (Win2K) or Windows XP to start the applet. Right-click the Local Primary Area Connection applet, choose Properties from the context menu, and make sure that the File and Printer Sharing for Microsoft Networks check box is selected (see Figure 8.16).

Figure 8.16: Viewing the dialog box to enable File and Print Sharing in Win2K.

After you re-enable File and Print Sharing, you should be able to successfully connect to and edit GPOs. The interesting part of this problem is that, with this service disabled, you can’t even connect to GPOs if you are sitting at the console of the PDC role holder domain controller. So you don’t have to be remote to feel the effects of this configuration problem.

178

Chapter 8

Q 8.8: I’m having problems with security policy processing. Is it possible to get more in-depth troubleshooting information than that provided by the event logs? A: Yes, you can enable verbose security policy logging that provides much more detailed information than you can get from even the verbose Group Policy Object (GPO) logging that is written to the Application event log or %systemroot%\debug\usermode\userenv.log. To enable verbose security policy logging, you will need to add a value to the registry. Fire up regedit.exe or regedt32.exe and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\G PExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}. Within this GUID-named key, add a new value of type REG_DWORD called ExtensionDebugLevel, and give it a value of 2. The change will take effect right away. The log file that is created by this registry entry is called %systemroot%\security\logs\winlogon.log. If you don’t see winlogon.log appear on a Windows 2000 (Win2K) workstation after enabling logging, try applying Service Pack 3.

Winlogon.log is a text file that contains quite a bit of information about the processing of security policy. You can see the effects of this logging immediately by triggering a background refresh of policy using secedit.exe: Secedit /refreshpolicy machine_policy

Figure 8.17 shows a sample of a log file generated by this registry key change.

Figure 8.17: Viewing the winlogon.log file tracking security policy changes.

The log file will report success or failure of the processing of each section within security policy. It will also report which GPOs are being processed, so you can ensure that all the expected security policy is being processed.

179