Securing Windows Desktops Using Group Policy

Managing Windows desktop security can be complex, with a myriad of tools and approaches available. However, Windows OSs include a built-in tool that has all the capabilities most organizations need to create secure, locked down desktops across any size environment— Group Policy.

Group Policy is often thought of by many IT administrators as a tool for performing desktop management tasks such as deploying software, redirecting folders, or locking a user out of regedit.exe. However, Group Policy is also the primary Windows tool for managing security configurations. In fact, Group Policy includes quite a few security capabilities that you might not be aware of. In this article, I explore some of Group Policy’s security features, explain how they work, and give you some tips for getting the most from them.

Core System Security
I break Group Policy’s security configuration capabilities into the following general categories: core system security, application and device restrictions, and Microsoft Internet Explorer (IE) security. The policy settings in the core system security category can typically be found in Group Policy Editor under Computer Configuration Windows Settings\Security Settings, as shown in Web Figure 1 from a Windows Vista system. Here are some of the features found in the core system security area of Group Policy.

Account Policies
You might be familiar with this section of Group Policy because it’s where password and account lockout policies are set. For example, you can set a minimum password length or require passwords to contain complex characters in this area of Group Policy. If you define these policies in a Group Policy Object (GPO) linked to the domain (e.g., within the Default Domain policy), the password policy is processed by all the domain controllers (DCs) in your domain and the GPO controls password policy for your domain user accounts. When the password policy is defined in a GPO linked to the domain, it will also be processed by all workstations and member servers in the domain and will set account policy for any local accounts defined on those systems.

As you might know, you can have only one domain password policy defined through Group Policy. However, Windows Server 2008 supports a new set of password policy objects, defined in Active Directory (AD), that give you more granular control of password policy within a single domain.

Local Policies
The three security policy areas under Local Policies let you control a variety of security settings on your Windows systems. For example, these policies let you use Audit Policy to configure which events are collected by the Windows Security event logs on your servers, use User Rights Assignment to configure who can access a particular set of servers or workstations via Remote Desktop, or use Security Options to configure whether the Administrator account is enabled on a given set of systems and renamed something other than Administrator.

Audit Policy is fairly straightforward in that it lets you control which types of events will be collected by the Windows Security event log. You can specify success and/or failure events here for auditing types ranging from AD access to system object (e.g., file and registry key) access. Depending on where a GPO defining auditing events is linked, you can enable auditing on DCs or member servers and workstations. For example, if I link a GPO containing an audit policy that enables directory service access auditing to the Domain Controllers organizational unit, it will be processed by all the DCs in my domain and thus all access to AD will be logged on the DC that serviced the access request.

User Rights Assignment is another powerful security tool within Group Policy. This tool lets you control who can do what on a given system. Examples of user rights include the Logon Locally right, which lets you control who can log on interactively at the console of a server or workstation, and the Load and Unload Device Drivers right, which grants a group or user the ability to install device drivers such as printer and display drivers. By creating a GPO that’s linked at the domain level and populating the Deny Log on Locally right with the Authenticated Users group, you would effectively prevent all the users in your AD domain from logging on to their workstations. Obviously, the point of this example isn’t to show how to break things, but to show how powerful User Rights Assignment can be and how careful you need to be when using it. As with other policy settings, you want to make sure that the GPO in which you’re setting user rights applies only to the computers you intend it to and that the rights you’re granting or revoking are granted or removed from the correct user groups.

Another thing to keep in mind about User Rights Assignment is that the list of rights that you see in Group Policy Editor changes depending on which version of Windows you’re editing Group Policy from (i.e., the version of Windows that you’re running Group Policy Editor on). Newer versions of Windows, such as Server 2008 and Vista, contain more user rights than older versions such as Windows XP. So, if you define a user right in a GPO running on Vista, and that GPO is applied to an XP system that doesn’t know anything about that user right, the XP system will process the policy but then ignore it.

You can quickly compare the differences in security settings between versions of Windows by downloading the Group Policy Settings Reference spreadsheets that Microsoft maintains for each version of Windows at download.microsoft.com. Search on the term “Group Policy Settings Reference” to see the spreadsheets for each release. The spreadsheets contain a list of all the default Administrative Templates for that version, as well as security settings.

You can use User Rights Assignment, as well as some of the other security areas in Windows, to configure roles that define who can do what within your environment. The built-in groups, such as Server Operators and Backup Operators, are just groups that have been granted a set of user rights and permissions for other resources on a system. You can certainly create a Desktop Administrators group and grant that group rights to perform whatever tasks are needed on your Windows systems, without having to include members of that group in the Administrators group on every system.

The final area in the Local Policies section of Group Policy Editor is Security Options, which is located under Local Policies Security Options. I call these settings the “vulnerability controls” because they define security settings that control configuration behaviors related to a system’s security posture. For example, within this section, you can configure Server Message Block (SMB) signing requirements on clients or servers. SMB signing is a form of secure communication that makes it difficult for attackers that have access to the network between systems to hijack that traffic. Within this section, you can also control the behavior of Vista’s User Account Control (UAC) feature, as shown in Figure 1.

Perhaps the most interesting thing about the Security Options section is that the list of security options that are presented in this section, while dependent on the version of Windows you’re running Group Policy Editor from, can be manually changed. The list is configured from an underlying file, called sceregvl.inf, that’s contained within the %windir%\inf folder on the machine you’re configuring. Within this file, each of the policies that you see in Security Options is defined, and you can edit the file for additional settings that you want to control via Group Policy. More information about customizing this file can be found at support.microsoft.com/kb/214752.

Restricted Groups Policy
The purpose of the Restricted Groups policy is to provide a mechanism for controlling local group membership on member servers and workstations. For example, you can use the Restricted Groups policy to ensure that only Help desk administrators are members of the Remote Desktop Users group on all your workstations. Restricted Groups has two modes of operation—Members and Member Of. The Members mode is the most restrictive mode. It says that for a given local group on a set of workstations, only the listed users and groups are members, and all other groups or users are removed (with the exception of the local Administrator account, which is never affected by the Restricted Groups policy). By contrast, the Members Of mode lets you add users and groups to other groups non-exclusively. In other words, you can create a policy that says Always make the Desktop Administrators group a member of local Administrators on any computers that process the policy. In that case, Desktop Administrators is added to the local Administrators group, but no other group members are affected.

Continue to page 2