Group Policy Settings
Now that you know how GPOs are processed, what can you do with them anyway? The GPO that was used on Windows Server 2003 and Windows XP had about 1,700 settings (1,671, as of March 31, 2005). The new GPO for Windows Vista has approximately 2,500 settings (2,495 with the initial release of Vista, to be exact). So what can you do with a GPO in Windows Vista? A lot and then some. The truth is that every configurable parameter of the operating system and every configurable parameter of every application that uses the Registry can be controlled with a GPO. Even if the Registry key or value doesn't exist, it can be added by GPO and then configured by GPO. So the real answer is that approximately everything on the computer that uses or could use the Registry can be controlled by GPO.
The next intelligent question might be "So what are they going to test me on?" That is an excellent question. You're going to look at a handful of specific GPO uses and settings that are potential targets on the exam.
Desktop Settings
One of the first target areas has to do with locking down your Desktop settings. Remember that GPOs have two halves: the computer configuration half and the user configuration half. Desktop settings are user-based settings, so you can find these settings in a GPO under User Configuration > Administrative Templates > Desktop, as shown in Figure 3.8.
Figure 3.8 Desktop controls by GPO are in the user configuration half.
Software Deployment by GPO
The next area to look at is software deployment GPOs. These are used to deploy applications to many computers or users automatically, over the network.
Software can only be assigned to the computer by GPO. Software can also be published or assigned to the user by GPO. The exam question should identify if the target is the computer or the user. Read the exam question carefully.
If the software is assigned to the computer, it is installed at computer bootup, by default. If the software is assigned to the user, it is installed at user logon, by default. If the software is published to you (the user), you have to install the application by using Control Panel > Programs > Get Programs.
Applications can also be configured for deployment by enabling the Auto-install This Application By File Extension Activation setting. This means that if the application being published is Excel, for example, you might trigger its installation by double-clicking on a file with an .xls extension.
GPOs can be used to deploy application software packages with the following extensions:
- .MSI—A Microsoft Installer package. This is the preferred software deployment package format. These files can be installed automatically, uninstalled automatically, and even repair themselves (application maintenance) if any of the application's files on the client computer go missing or corrupt.
- .MST—A Microsoft Transform file. These files are used to modify the installation behavior of an .MSI package—for example, to deploy only Word and Excel from the MS Office suite.
- .MSP—A Microsoft Patch file. These files are used to deploy patches for Microsoft and third-party applications. (MS application patches are usually deployed through Microsoft Update these days.)
- .ZAP—A script file used to deploy software packages that do not have an .MSI file for deployment. This script must be created by an administrator to deploy software when all that is available is a Setup.exe, or the like. Although these files can be used to deploy software, the .ZAP file cannot be used to maintain or automatically uninstall the deployed software.
The software deployment package must reside on a network share, and users must have at least Allow—Read permissions on the share and on the NTFS permissions for the package. This network share point is called the Software Distribution Point (SDP).
Software Restrictions
The next major area of GPO category is in Software Restrictions. These GPOs are used to deny all executables except those specifically allowed using the Restricted Default Rule, or used to allow all executables and then disallow specific executables using the Unrestricted Default Rule. These GPO settings are located in the GPO under Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies.
By default, the execution of applications is configured as Unrestricted, as shown in Figure 3.10. Application execution is intended to be controlled by the access permissions (share and NTFS) of the user on the executable.
Figure 3.10 By default, software execution is unrestricted.
You can configure permissions to keep users from executing applications. You need to do this on each computer where the application resides, a huge task in a large environment. Or you can do it much more easily and on a larger scale by creating a GPO with Software Restriction Rules and then link them appropriately.
Four types of Software Restriction Policy Rules can be used to modify the Default Rule:
- Certificate Rule—A digital signature embedded within the executable file.
- Hash Rule—A numeric fingerprint of the executable file.
- Internet Zone Rule—From tab. They include Internet, Local Intranet, Trusted Sites, and Restricted Sites.
- Path Rule—The local path or UNC path to the executable file.
These rules are shown in Figure 3.11.
Figure 3.11 Modifying the Software Restriction Policy Rules.
These rules often get applied in combinations, and it can get tricky to figure out which GPOs will effectively restrict which applications. As GPOs get processed on the computer, the Software Restriction GPOs are evaluated and then are prioritized in the following order:
- Certificate Rule—Strongest
- Hash Rule
- Path Rule
- Internet Zone Rule
- Default Rule—Weakest
Managing Device Installation
Another powerful control within a GPO that you have over users is the management device installations. This has been a security concern for years. How do you keep users from using USB thumb drives and USB CD/DVD burners to take copies of confidential data and programs away from the office? I have heard of companies actually gluing the USB mouse and keyboard into the USB ports and then filling all other USB ports with glue just to prevent the use of USB thumb drives that could be used to steal confidential data. Not exactly the perfect solution, but one that addresses the security vulnerability. But now what do you do if the mouse or keyboard fails?
Windows Vista and Windows Server 2008 have addressed and solved this problem through new GPO settings that can control what types of devices can be installed by users, by administrators, or both. These Device Installation GPO settings can be configured on a Windows Vista or Windows Server 2008 computer under Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions, as shown in Figure 3.13.
Figure 3.13 Setting the Device Installation Restriction policies.
Standard users are not allowed to install many devices. However, by default, they can install a handful of devices, like USB thumb drives.
Devices are identified by Setup Classes (a Registry key) or by Device IDs (a more descriptive label for the devices). By using these identification values, you can configure Prevent Installation policies to include USB thumb drives and other types of devices, as shown in Figure 3.14.
Figure 3.14 Preventing installation of devices that match any of these Device IDs.
You can configure a GPO to establish a default Prevent Installation of Devices Not Described by Other Policy Settings policy, and then you can configure Allow Installation policies only for specific devices that you want users to be able to install.
The Prevent Installation of Devices Not Described by Other Policy Settings policy setting disallows even an administrator from installing restricted devices. If you need to allow administrators to install restricted devices, you must enable the Allow Administrators to Override Device Installation Restriction Policies, as shown in Figure 3.15, and link it to the appropriate AD container (site, domain, or OU).
Figure 3.15 Setting Allow Device Installation policies for users and for administrators.
The Audit Policy
Auditing is a critical component of the security program for every company. You can configure systems to record what your users do (Success) and what your users attempt to do (Failure). Audit policies are defined within the Local Computer Policy (LCP) and within GPOs. The audit policy is located under Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy. You can configure nine audit policies, as shown in Figure 3.16.
Figure 3.16 Configuring the Object Access audit policy within a GPO.
Audited events get recorded in the Security log on the computer where the event occurs and can be reviewed in the Event Viewer on that computer. The Security logs (and any other types of events) from multiple Windows Vista computers can be forwarded to an Event Collector server, a topic addressed later in this chapter.
Most of the audit policies require only the LCP or GPO settings configured to be effective. Two of the audit policies require some additional configuration in addition to the GPO audit policy settings to be effective. They are Directory Service Access and Object Access policies. The additional settings that are required reside on the properties of the objects being tracked by the audit policy and must be configured on the objects' System Access Control List (SACL). (This may also be called the Security Access Control List—SACL.) The GPO turns on the auditing engine, and the SACL identifies specifically which users and which objects will be tracked.
You can access the SACL by following these steps:
- Right-click on the Files, Folders, Printers, or AD objects of interest and select Properties.
- Select the Security tab and click Advanced.
- Select the Auditing tab to access the SACL for these types of objects.
On Registry objects, after enabling the Audit Object Access audit policy, right-click the desired Registry object and select Permissions. Click Advanced and select the Auditing tab. This is the SACL for Registry Keys, Values, and Data, as shown in Figure 3.17.
Figure 3.17 Configuring the System Access Control List (SACL) in the Registry.
Point and Print Restrictions
Point and Print restrictions allow you to control access to selected shared printers on the corporate network. By default, printers are shared with the permissions set to Allow—Print for the Everyone group. This says that any user can connect to a shared printer, automatically download any required printer drivers, and submit print jobs to that device. Permissions can be adjusted on the printer properties to further control this access. The Point and Print restrictions in a GPO can be used in addition to these permissions to control printer access for large groups of users in an AD environment.
This setting is located under User Configuration > Administrative Templates > Control Panel > Printers, as shown in Figure 3.18.
Figure 3.18 Configuring Point and Print restrictions.
The fully qualified domain name (FQDN) of the print server must be added to complete the GPO setting.
This GPO setting requires that you construct a list of print servers that the users are allowed to download drivers from and then submit print jobs to. You can further restrict the driver download to only those drivers that have been tested, approved, and digitally signed by Microsoft's Windows Hardware Quality Labs (WHQL), the testing arm of Microsoft for third-party drivers.
Digital Certificates and Authenticode
As users connect to web servers, their browsers download the HTML file and image files and also download and execute active content, like ActiveX controls. Active content, also called mobile code, is a major source of malware (viruses and spyware) and is often heavily restricted in a corporate environment.
To ensure that your ActiveX controls are safe and usable by all who visit your website is to have the ActiveX control tested and digitally signed by Microsoft. When an ActiveX control is signed by Microsoft, it is called Authenticode, and it is generally trusted to be safe for your users to run. However, on occasion, these tested and approved ActiveX controls can still conflict with other software running on your client computers, so having it signed by Microsoft is still not a guarantee of safety.
You can restrict the browsers on your users' computers to execute Authenticode only from a select list of publishers that you approve. To do this, you must enable a setting in a GPO that is located under User Configuration > Windows Settings > Internet Explorer Maintenance > Security > Authenticode Settings. The setting is labeled Enable Trusted Publisher Lockdown. This setting, shown in Figure 3.19, disables users from accepting any certificates (used in the Authenticode) from publishers that aren't on your approved publishers list.
Figure 3.19 Configuring trusted publisher lockdown.