By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Controlling the Desktop
Perhaps the most visible effect of Group Policy Object is your ability to control the desktop environment for your end users' workstations. It can, however, create one of those tricky balancing acts between being in control of your desktops and being a control freak about them. Now, from an administrative standpoint, we all know that consistency is good: if everyone's desktop is configured the same way, it makes it that much easier to troubleshoot file incompatibilities or to make large-scale changes as applications need installing or upgrading. On the other hand, there's also a school of thought that says that too rigid of an environment makes for unhappy users (which can thus make for unhappy administrators). In most corporate environments, for example, you're not going to want to allow people to install games or other personal software on their business workstations, but is there really any harm in allowing some flexibility to customize their wallpaper, their screensaver, and the like? There are situations where such tight control is warranted, of course, such as a public kiosk in a library or an airport, or in a 24✕7 customer service center where users share workstations over multiple shifts. Like anything else, it's a compromise; you need to decide where your organization's computers need to live on the "lockdown scale." Luckily, Group Policy allows you to grant varying levels of autonomy to different groups of users and computers, as we'll discuss in this section.
Configuring Lockdown (Kiosk) Workstations
In some cases, you'll want to lock down a workstation as much as possible, especially if it's in a public area like a library or a retail store. In many cases, such a machine will be used solely for accessing a specific web page to look up prices, check reservations, and the like. When configuring a GPO for this type of machine, you want to be as stringent as possible in controlling what the user is able to access and change. Some of the settings that you might want to enable (either from the GPMC or the Group Policy tab in Active Directory Users & Computers) include the following:
Computer ConfigurationWindows ComponentsInternet Explorer:Disable Automatic Install of Internet Explorer components— EnabledComputer ConfigurationWindows ComponentsControl PanelDisplay:
Disable Periodic Check for Internet Explorer software updates— Enabled
Security Zones: Do not allow users to add/delete sites—Enabled
Security Zones: Do not allow users to change policies—Enabled
Security Zones:Use only machine settings—EnabledHide Appearance and Themes tab—EnabledComputer ConfigurationWindows ComponentsDesktop:
Hide Desktop tab—Enabled
Hide Screen Saver tab—Enabled
Hide Settings tab—Enabled
Prevent changing wallpaper—Enabled
Remove display in Control Panel—EnabledDo not add shares of recently opened documents to My Network Places—Enabled
Don't save settings at exit—Enabled
Hide and disable all items on the desktop—Disabled
Hide Internet Explorer icon on desktop—Enabled
Hide My Network Places icon on desktop—Enabled
Prevent adding, dragging, dropping, and closing the Taskbar's toolbars—Enabled
Prohibit adjusting desktop toolbars—Enabled
Prohibit user from changing My Documents path—Enabled
Remove My Computer icon on the desktop—Enabled
Remove My Documents icon on the desktop—Enabled
Remove Recycle Bin icon from desktop—Enabled
Remove the Desktop Cleanup Wizard—Enabled
As you can see, these settings are quite rigid and designed for machines that are installed in public areas. You can certainly modify these settings to create a more relaxed desktop environment for machines that are "owned" by one particular individual. But the most powerful lockdown mechanism that you can (and should) employ involves controlling the applications that a user can launch from her client workstation; we'll discuss this in detail in the next section.
Using Software Restriction Policies
High on the wish list of most administrators is the ability to restrict what kind of software can run on the workstations on their network. Windows NT and 2000 offered a certain amount of control in this area, but it ranged from "hit-or-miss" to "darn near impossible to configure." You could disallow freecell.exe, for example, and a savvy client could simply rename the file to notepad.exe or another application on the permitted list. Once he did that, the blocked application would open as if you'd put no restrictions in place at all.
Windows Server 2003 has made significant advances in this area, providing nearly foolproof options for controlling how software is used on your network. This can be useful not only for restricting the use of games and other nonbusiness software on your client workstations, but also as a way to restrict viruses and malware. How is this possible? Imagine a virus that executes a VBScript to launch a Denial of Service attack. If you've configured software restrictions so that no VBScripts can run on your network, then the virus will be stopped even if someone accidentally opens an infected e-mail attachment. And even nonmalicious software can create issues for an enterprise network if it hasn't been tested and approved: system files can be overwritten and can create the dreaded DLL Hell that makes Windows troubleshooting such a joy.
SOAPBOX: BLAME THE USER?
Wouldn't our lives all get a whole lot simpler if we could make those pesky users go away and stop bothering us? I mean, they're horrible! Always clicking on attachments and needing more disk space and generally making a mess of our nice, orderly networks!
But despite our occasional frustrations, part of what separates good network admins from great ones is the ability to secure a network without driving their clients to open revolt. It's very easy to say "We wouldn't need antivirus scanners if people would just stop clicking on things they're not supposed to." But that's also a bit of an oversimplification, since it assumes that every client on your network is just as technically savvy as you are. And this, as we all know, is hardly ever the case. If your network security strategy is "Get users to stop doing things they shouldn't," then it's a plan that's doomed to failure. And that's because it only takes one—one person who was in a rush, or forgot, or got fooled by a forged e-mail header, or any number of things that could happen to any of us. The reason I'm a big advocate of technologies like Group Policy and Software Restriction Policies is that they help to protect your clients from themselves. And if your clients are protected, then so, by extension, is your network.
Software Restriction Policies begin with one of two configurations whereby you decide how applications should be treated on your network, called Unrestricted and Disallowed. The difference between the two is pretty obvious: you need to make a choice between "Run everything except the stuff I tell you is bad" versus "Don't run anything except what I explicitly tell you is allowed." Once you've made this initial decision, there are four rules that Windows Server 2003 can use to restrict software usage on your network: Path, Hash, Certificate, and Zone.
CAUTION: If you don't use a test environment for anything else, I strongly urge you to create one before you deploy Software Restriction Policies. Imagine a worst-case scenario: if you create a policy, set the default to Disallowed, and then don't specify any programs that are allowed to run, you've just created a policy that won't allow anything to run. You wouldn't even be able to log on to a workstation or server that's been configured this way. Even in less extreme situations, this is a powerful tool that warrants thorough testing before implementing it on a production network.
Creating a Software Restriction Policy
Rather than drown you in details, I'll first walk through creating a basic Software Restriction Policy using some default options. Once you've got the big picture at that point, you can get into the nitty-gritty of each rule type and some of the other advanced options that you can set within the policy.
To create a Software Restriction Policy, follow these steps:
1. Open the target GPO in the Group Policy Management Console. (Right-click the object and click Edit.)
2. Navigate to User Configuration ➤ Windows Settings ➤ Security Settings ➤ Software Restriction Policies.
3. Right-click the Software Restriction Policies folder and select New Software Restriction Policy.
4. Your first step is to decide whether your overall software policy will be Unrestricted or Disallowed. By default, a new policy will use the Unrestricted setting. To change this, right-click Disallowed and select Set as default. (But you really should configure rules for what programs are allowed to run before you do this.) For our purposes, we'll assume that you're leaving the default Unrestricted setting, and want to disallow specific programs instead.
5. Next, configure a Path rule to disallow a specific application. Let's say that you've been instructed to restrict use of the AOL Instant Messenger application on your network. Right-click the Additional Rules folder and select New Path Rule. You'll see the dialog box shown in Figure 4-4. Enter the path to the AIM executable, and set the security level to Disallowed. This change will take effect the next time that the GPO is refreshed, or when a user logs out and logs back in.
CAUTION: If you support Windows XP workstations, Software Restriction Policies will take two (I've even heard anecdotal reports of three) reboots to take effect. This is because of the Fast Logon Optimization feature, in which Windows XP doesn't wait for a network connection to come all the way up before applying Group Policies. Check out Knowledge Base Article 305293 for the full explanation, available from Microsoft.
Configuring Zone Rules
A Zone rule allows you to restrict software based on the Internet Explorer zone that it was downloaded from: Internet, Local Intranet, Restricted Sites, Trusted Sites, or Local Computer. This would be useful if you use an intranet site to make software applications available to your users: they could install and run software downloaded from the Local Intranet zone, but not anything they downloaded from an untrusted game server.
NOTE: Why are you using an intranet site to deploy software? Group Policy can do that for you! Never mind, we'll get there in a minute.
Before you break into a happy dance over how cool this feature is, though, you can only use it to regulate MSI installers, not .EXE files or other downloadable files. This makes it perhaps the least useful of the software restriction rules, unfortunately. Maybe it'll be improved in a future Group Policy or Windows operating system release, because it really is a great idea.
Configuring Hash Rules
One of the largest challenges of software restriction in Windows NT and Windows 2000 was the fact that restrictions were keyed to the file name of the executable that you were trying to allow or disallow. So you could disallow sol.exe or kazaa.exe all you wanted to, but all a crafty user needed to do was rename the executable to notepad.exe or a similarly innocuous name, and any software restrictions would be circumvented. In Windows Server 2003, you can use a Hash rule to increase the effectiveness of your software restrictions. A hash refers to a kind of mathematical fingerprint that will uniquely identify a file regardless of where it lives within the file system, and even regardless of whether it's been renamed. This fingerprint remains unchanged when the file is copied, moved, or even renamed. This means that our intrepid user's "rename the file" strategy would be foiled if Hash rules were in effect. Creating a Hash rule is nearly identical to the way we created the Path rule, except that you'll select only the file name rather than the full path.
NOTE: Most antivirus companies will make the hash values of known virus files available to the public. You can then paste this hash into a Software Restriction rule to prevent the virus from running on your network.
Another great use for Hash rules is to prevent damage caused by viruses and Trojans that attempt to overwrite operating system files with malicious copies. So if your policy were configured to only allow the applications that you name, even if a virus could overwrite WINWORD.EXE with a malicious Trojan, it still wouldn't be able to launch because the hash value would not match the one specified in the Hash rule.
Configuring Certificate Path Rules
You can also configure Software Restriction Policies to use certificates to determine whether software can run or not. For example, you can use Certificate rules to automatically trust software from a third-party vendor or from within your organization. Certificates used in a Certificate rule can come from a commercial CA like Thawte or VeriSign, a Windows 2000/ Windows Server 2003 PKI server, or a self-signed certificate. This is a really useful way to prevent users from downloaded unauthorized ActiveX controls from untrusted websites.
Configuring Path Rules
As you saw in the sample policy we created, Path rules can specify the fully qualified path to a program. You can also use wildcards and folder names to create less-specific Path rules. When a Path rule specifies a folder, it will apply to any program that's contained in that folder, as well as any programs contained within any subfolders. You can use both local and UNC paths to create a Path rule, as well as environmental path variables like %WINDIR%.
CAUTION: Use system variables with caution since they are client-specific. If a user can modify her local environment variables, it can affect the results of any Path rules that rely on those variables.
You can also use the familiar * and ? wildcards to increase the flexibility and effectiveness of your Path rules. For example, *Windows will apply to C:Windows, D:Windows, and E:Windows, in case your clients have their OS installed to a nondefault logical drive. You can also use wildcards for such familiar tricks as *.exe, *.vbs, and the like.
If you need even more flexibility than wildcards offer, you can control your Path rules using Registry paths. This is especially useful if you need to restrict the contents of an application that may not be installed in a consistent location, but that stores its installation directory within a Registry key. So a Registry Path rule could look up the value in a Registry key such as this:
%HKEY_LOCAL_MACHINESOFTWAREVendorNameAppName DirectoriesInstall Dir%.
When creating a Registry Path rule, you'll use the following format:
%[Registry Hive][Registry Key Name][Value Name]%
Path Rule Precedence
There's a specific order in which multiple Path rules will be enforced, depending on how specific the policy is. What does this mean? Essentially, a Path rule that is defined on a specific file (a more restrictive rule) will take precedence over policies applied to a file folder, or to policies involving wildcards (less restrictive rules). Any conflicts between Path rules will be resolved using the following precedence:
1. Drive:Folder1 will be applied first and has the lowest precedence.
5. Drive:Folder1Folder2FileName.Extension will be applied last and has the highest precedence.
Software Restriction Rule Precedence
In addition to resolving conflicts between Path rules, you'll need to understand how the different restriction types interact with each other as well. If multiple rule types are in effect, policies will be applied in the following order:
1. The Internet Zone rule has the lowest precedence of all Software Restriction Policies.
2. Path rules, in the following order:Drive:Folder1
3. The Certificate rule.
4. The Hash rule has the highest precedence of all Software Restriction Policies, and will be applied last so that its settings "win."
Much like Group Policies, the last policy that applies is the one that takes precedence. So if you create a Hash rule that allows Unrestricted access to iexplorer.exe, but define a Path rule that disallows it, the program will be allowed to run.
If after all of this you still have two identical rules that are applying differing security levels to the same executable, the more stringent rule will take precedence. For example, if two Hash rules—one with a security level of Disallowed and one with a security level of Unrestricted—are applied to the same software program, the Disallowed rule will take effect and the program will not run.
NOTE: As with any configuration policies on your network, I'm going to tell you that your best bet is to keep it simple. Applying multiple policies and worrying about precedence rules is mostly going to add to troubleshooting difficulties and not much else.
Click for the next excerpt in this series: Securing client operating systems
Click for the complete book excerpt series.