Active Directory 2008 : Managing Enterprise Security and Configuration with Group Policy Settings -- Managing Software with Group Policy (part 2)

When a client performs a Group Policy refresh, it tests the performance of the network to determine whether it is connected using a slow link, defined by default as 500 kilobits per second (kbps). Each client-side extension is configured to process Group Policy or to skip the application of settings on a slow link. By default, GPSI does not process Group Policy settings over a slow link because the installation of software over a slow link could cause significant delays.

You can change the slow link policy processing behavior of each client-side extension by using policy settings located in Computer Configuration\Policies\Administrative Templates\System\Group Policy. For example, you could modify the behavior of the software installation extension so that it does process policies over a slow link.

You can also change the connection speed threshold that constitutes a slow link. By configuring a low threshold for the connection speed, you can convince the client-side extensions that a connection is not a slow link, even if it actually is. Group Policy Slow Link Detection has separate policy settings for computer policy processing and user policy processing. The policies are in the Administrative Templates\System\Group Policy folders in Computer Configuration and User Configuration.

In a typical enterprise, computers are deployed with a highly managed configuration that is based on an image of the operating system and core applications. But, over time, the applications that are installed on a computer drift away from the managed, well-defined initial state. When a user logs on as a non-privileged user—when she is not a member of the local Administrators groups of her computer—her ability to install new applications is greatly restricted, but not entirely prevented. For example, a user can copy a self-contained application in a single executable (.exe file) to her desktop and launch it.

When a user installs unmanaged applications, the risk and cost of supporting that user increases. The new applications may cause instability or incompatibility with other applications, resulting in increased support calls, or may introduce malware into the environment. Additionally, a new application may not be licensed correctly for use in your enterprise.

For these and other manageability reasons, it is best practice to restrict program execution—to ensure that users can run only those applications that have been vetted by the enterprise for compatibility, security, and licensing. Windows XP and Windows Vista featured Software Restriction Policy (SRP), with which you could specify applications that were allowed or disallowed. But SRP was difficult to manage effectively, because—in its best practice configuration—an application policy was associated with the signature of a specific executable or component. If the application was patched or updated, the policy had to be revised to reflect the updated signature.

Windows 7 and Windows Server 2008 R2 feature AppLocker, a more powerful, robust, and manageable framework with which to restrict application execution. AppLocker uses Allow rules and Deny rules, which both support exceptions. For example, you can define a rule that allows users to run all components of the Windows operating system, except built-in games and Registry Editor. You could create a rule that denies users the ability to launch any executable that is in the C:\Users folder, except ZoomIt.exe. An enterprise typically applies a combination of Allow and Deny rules, and exceptions, to implement application lock-down with a minimal number of rules.

As with SRP, rules can be associated with the path or hash of an executable, but these rules can be circumvented and are difficult to manage. AppLocker rules can also be associated with the digital signature of a publisher, the name of a product, and the name and versions of a file. Such rules are more flexible, more manageable, and more secure. For example, you could define a rule that allows users to run Adobe Reader version 9.0 or greater. Rules can also be associated with a collection of files so that a user can launch an installer, which itself executes related components. And rules can be applied to users or groups so that, for example, you could allow the Finance group to run the approved accounting software, but other users would not be able to run the same application.

Rules can be created on a computer running Windows 7 Professional, Windows 7 Ultimate, Windows 7 Enterprise, or Windows Server 2008 R2. For Group Policy deployment of rules, you must use the Windows Server 2008 R2 version of Group Policy Management, which can be installed on Windows 7 by adding the Remote Server Administration Tools (RSAT). AppLocker rules can be enforced on most editions of Windows Server 2008 R2, Windows 7 Enterprise, or Windows 7 Ultimate. You cannot enforce AppLocker rules on Windows 7 Professional, Windows 7 Home Premium, or any other consumer-focused edition of Windows 7. You also cannot enforce AppLocker rules on Windows Web Server 2008 R2 or Windows Server 2008 R2 Foundation.