 | |||
|
|
||
| |||
| |||
| |||
| |
|
Home > Controlling the desktop |
| |
|
|
|
|
| Book Chapter: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: 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.
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.
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.)
Figure 4-4 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.
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.
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.
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.
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. 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. 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.
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The following excerpt, courtesy of APress, is from
Chapter 4 of the book "Active Directory Field Guide" written by Laura E. Hunter. Click for the 
