Chapter 14: Using Group Policy
Group Policy … The mere mention of it stirs up strong feelings in seasoned Windows administrators. Typically the reaction is some mixture of awe, revulsion, and resignation. Group Policy is a mixture between dark arts, defense against the dark arts, and your ordinary, run-of-the-mill mystery.
It is no small wonder really. Microsoft's Group Policy Reference for Windows Vista, lists 2,494 (!) settings across 131 administrative templates. To that we need to add at least 163 security settings, plus an arbitrary number of configured restricted groups, services, and registry and file system ACLs. It would be quite easy for even a moderate size enterprise to have thousands of Group Policy settings across tens of templates.
Group Policy can certainly be daunting. In this chapter, we discuss the changes to Group Policy in Windows Vista. The reader who is not familiar with Group Policy is warmly recommended to consult Jeremy Moskowitz's excellent book on the topic, Group Policy: Management, Troubleshooting and Security, which is fully updated for Windows Vista. There is so much to discuss that, for efficiency, we will assume an operating understanding of Group Policy. If you feel rusty you may want to brush up on Group Policy either with Moskowitz (at http://www.GPanswers.com), or by perusing some of the documents on Microsoft's Group Policy tech center.
Windows Vista is seeing the most significant upgrade to Group Policy since its introduction with Windows 2000. In this chapter, we discuss the new and updated features, as well as a selection of the 812 new Group Policy settings and all new and modified security settings in Windows Vista and programs that first shipped with Windows Vista.
New Group Policy Features
By far the most significant change in Group Policy in Windows Vista is not all the new settings, although those are certainly very interesting. The most significant changes are in the new features. The first, and most intriguing of these, is that you can now have several local policies on a single computer.
Multiple Local Group Policies
Windows Vista adds support for multiple local Group Policy objects (MLGPOs). This permits you to set different settings for different types of users on a standalone computer, just like you can on a domain-joined computer. There are three types of local Group Policy objects (GPO):
The Local Computer Policy is identical to the one in earlier versions of Windows. If you simply open GPEdit.msc, the Group Policy Editor, it will open the Local Group Policy object. Changes you make there will affect every user on the computer, and can also affect the computer settings (which also affect every user).
The other two types of local GPOs support only user configuration and are designed to let you control users settings for different types of users. The administrators and non-administrators Group Policy type lets you set different settings for administrators and non-administrators. The user-specific Group Policies let you set different settings for different users or groups of users.
The only object that exists by default is the Local Computer Policy. The others are created only when you add something to them. To create and manage these objects you need to open a new instance of the Microsoft Management Console (MMC) and add the requisite objects to it. To do so, do the following:
-
Launch mmc.exe.
-
Accept the UAC elevation prompts.
-
Click Fileﾀﾀ Add/Remove Snap-ins.
-
Add the Group Policy Object Editor.
-
In the Select Group Policy Object dialog box ensure that Local Computer is selected and click the Finish button.
This adds the Local Computer Policy GPO. If you want additional local GPOs, repeat Steps 3–5 for each object you want. However, instead of selecting Local Computer, click the Browse button, and select a group or a user. For example, if you want to manage policy for Administrators, click the Browse button and select Administrators as shown in Figure 1.
You can add as many of these Group Policy objects as is practical for you to manage. Keep in mind, however, that Group Policy grows in complexity as you add objects. It is a wise process to start with a general policy that is assigned to everyone, and then assign deltas in more granular policies. This simplifies administration. In practicality, you probably won't add a whole lot of policies because unlike domain Group Policy, MLGPOs do not actually filter policies based on arbitrary groups, other than the Administrators/Non-Administrators groups. You can only create policies for users.
Once you have added all the policies you need, you should save your MMC console so that you can easily go back and manage all the objects. If you do not save it, you may find yourself hunting for policies. Also remember that you can only manage computer policy in the Local Computer Policy object. The console makes that quite clear, however, as shown in Figure 2.
To delete an object you would go through the same steps as you would to add it. However, in the browse dialog box, when you see the list of available objects, right-click the one you want to delete and select Remove Group Policy Object, as shown in Figure 3.
Group Policy Precedence
Determining which object's settings will apply can be quite complicated in Group Policy. As with domain-based Group Policy, the most recently applied setting wins. The settings are applied in the order they are listed in Figure 2. Local Computer Policy applies before administrator/non-administrator policy, which is applied before user policies. Since policies for groups are not supported, this application order is completely unambiguous. Should you wish to troubleshoot policies, you can also use the Resultant Set of Policy (RSOP) tools, rsop.msc and gpresult.exe. This is shown in Figure 4 and the following, abbreviated command-line output:
C:\Windows\system32>gpresult /z
Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001
Created On 1/16/2007 at 11:24:41 PM
RSOP data for JJ-VistaRTMTst\Jesper on JJ-VISTARTMTST : Logging Mode
---------------------------------------------------------------------
OS Configuration: Standalone Workstation
OS Version: 6.0.6000
Site Name: N/A
Roaming Profile: N/A
Local Profile: C:\Users\Jesper
Connected over a slow link?: No
COMPUTER SETTINGS
------------------
USER SETTINGS
--------------
Last time Group Policy was applied: 1/16/2007 at 10:51:11 PM
Group Policy was applied from: N/A
Group Policy slow link threshold: 500 kbps
Domain Name: JJ-VistaRTMTst
Domain Type:
Applied Group Policy Objects
-----------------------------
Local Group Policy\Jesper
Local Group Policy\Administrators
Local Group Policy
Resultant Set Of Policies for User
-----------------------------------
Administrative Templates
------------------------
GPO: Local Group Policy\Jesper
KeyName: Software\Policies\Microsoft\Windows\
Task Scheduler5.0\Task Creation
Value: 1, 0, 0, 0
State: Enabled
GPO: Local Group Policy\Administrators
KeyName: Software\Policies\Microsoft\Windows\
Task Scheduler5.0\Task Creation
State: disabled
GPO: Local Group Policy
KeyName: Software\Policies\Microsoft\Windows\
Task Scheduler5.0\Task Creation
Value: 1, 0, 0, 0
State: Enabled
In general, rsop.msc is more user-friendly and is the best tool to use if you want to find out what the ultimate state of a particular setting is and which policy it came from. It also shows the precedence order, as shown in Figure 4. Gpresult.exe is useful if you wish to have text-based output for saving to logs, or sending to others, or if you belong to that group of august curmudgeons who still believe that the only good GUI is one that doesn't get in the way of rapidly finding a good command line.
Using MLGPOs in a Domain Environment
MLGPOs can also be used on domain-joined computers, although it is not really recommended for that scenario due to the difficulty of centrally managing the policies. If it is used in a domain environment, the precedence order does not change from prior versions of Windows. All local GPOs are applied before domain-based GPOs. In other words, if a local GPO defines a particular setting to some value and a domain GPO that applies to the same user or computer defines it to some other value, the domain GPO will be the effective value.
To avoid conflicts altogether, or to exercise additional control, you can disable local GPO processing entirely on domain-members by enabling the "Turn off Local Group Policy objects processing" setting in Computer Configuration\ Administrative Templates\System\Group Policy. Obviously, this setting will only apply the next time local GPOs are about to be processed.
For more information on how to manage Multiple Local Group Policy Objects, see the step-by-step guide: http://www.technet2.microsoft.com/WindowsVista/en/library/1033.mspx?mfr=true.
Difference between Local GPOs and Domain GPOs
There are a few differences between local GPOs (LGPO) and domain-based GPOs in terms of the settings they support. There are notably fewer security options in the LGPOs, largely because certain areas of security management are not meaningful on non-domain joined systems. In addition, some features that are exclusively, or predominantly, designed for domain environments, such as Folder Redirection, Remote Installation Services (RIS) (on pre-Vista machines) or Group Policy Software Installation are not supported on LGPOs. In general, MLGPO is primarily useful to administrators of systems that cannot use regular Group Policy. The output of the Group Policy Object Editor is a .pol file. The .pol file is stored in the netlogon share of all Domain Controllers (DC) for domain-based GPOs. Local Group Policies are stored in various places. Administrative template settings in the Local Computer GPO are stored in %systemroot%\System32\GroupPolicy\Machine\Registry.pol and %systemroot%\ System32\GroupPolicy\User\Registry.pol. User and group specific local policies are stored in %systemroot%\System32\GroupPolicyUsers\\User\Registry.pol.
New Administrative Template Format
Administrative templates are definition files that drive the user interface (UI) in the Group Policy Object Editor. They define which settings can be configured, what values they take, which UI elements are available to edit them, strings to help the administrator understand what is being edited, and so on.
In Windows Vista, Microsoft replaced the aging administrative template file format, ADM, with a new XML-based file-format: ADMX. The ADM template format has been used, with a few updates, since the Windows 95 System Policy Editor. ADM was really just an updated version of that format. The group policy file itself, the .pol file, is still essentially equivalent to the old System Policy Editor output files.
The new file format was created at least in part to support Microsoft's initiative to lower costs associated with localization. Windows XP was fully localized into 24 languages, and partial localization is available in an additional 33 languages. Needless to say, the cost of localization can be significant, especially if the user interface text elements are spread throughout a large number of files. In addition, any change in the text would require complete rebuilding of all affected components. Finally, localization cannot proceed until the code is mostly written because the text elements that are part of the code need to be complete before they can be localized. To simplify and manage this process better, and to enable simultaneous shipping of Windows in multiple languages, Microsoft has separated much of the text elements from the code elements that use them. This means that developers can define their text elements early on and send those out for localization. They can then proceed to write the rest of the code, while the text is being translated. This is a significant security benefit for many users that do not use English versions of the operating system. In the past, it was quite common for Microsoft to ship a service pack in only three languages (typically English, German, and Japanese) with all other service packs to follow over a span of one to six months. However, the errata, lists of all bugs fixed, were published when the original versions were released. This gave attackers a significant advantage. They had complete details on bugs, and even code that was fixed to compare with code that was vulnerable. Customers using other language versions of the product, however, had no patch available to them.
The ADMX file format actually consists of two separate files: an ADMX template that defines the UI elements, and an ADML file that contains localized versions of all strings used in the ADMX template. The new format is more flexible and provides additional control elements. It also handles versioning much better than the old ADM format. For more information on the schema see Microsoft Corporation, 2007b.
Template Embedding
One very simple, but welcome change in GPO in Windows Vista is how the ADMX templates are treated with the policies. Ever since Windows 2000, each GPO has contained a copy of all the ADM templates that were used to create it. For an organization with a large, complex GPO structure, that means that the system.adm template could be replicated in hundreds of policies, creating significant replication overhead.
When building policies with ADMX templates, you may use a central store of ADMX templates instead. This is not done automatically for you to avoid impacting down-level DCs. To create the central store you would create a directory called PolicyDefinitions in the %systemroot%\SYSVOL\domain name\Policies directory of your DC. You can then copy the ADMX and ADML files from the %systemroot%\PolicyDefinitions directory on a Windows Vista member workstation. Note that the ADML templates are language-specific. For instance, the U.S. English ones are in a subdirectory called EN-US. You should copy all the ones that relate to languages you will use to manage Group Policy, but it is not necessary to copy ones that are used on clients that receive the policies, but are not used to manage them. For instance, if you manage a network where about 80 percent of the workstations are localized in Swedish, but the administrative workstations are using U.S. English versions of the OS, you will need to copy only the U.S. English versions. The policies themselves are language independent and work across all languages.
After you have copied the administrative templates to the sysvol share the Windows Vista Group Policy Editor will automatically use templates from the central store instead of the local copies when editing domain-based GPOs. Note that pre-Vista operating systems have no knowledge or recognition of the central store. This ability only comes with Windows Vista (and presumably Windows Longhorn server) when being used to edit your Group Policy Objects.
Migrating to ADMX
If you are interested in migrating existing ADM templates to ADMX this can be done. Microsoft has published the ADMX migration tool which can be used to convert templates from ADM to ADMX. For more details, see http://www.go.microsoft.com/fwlink/?LinkId=77409.
Client-Side Pulling and Network Location Awareness
In the past Group Policy relied on the Internet Control Message Protocol (ICMP). Clients used ICMP ECHO (ping) to locate domain controllers and detect slow links. Starting with Windows Vista, this functionality is provided through Network Location Awareness (NLA) instead. This means that clients will more reliably get Group Policy applied and that administrators who block ICMP for security reasons will still be able to use Group Policy.
In addition, Group Policy settings are now applied whenever domain controller availability returns. Starting with Windows Vista clients pull policy whenever a connection event occurs; such as after resuming from suspend mode (but only if the client missed the last update).
|
