Software Restriction Policies allow you to control the execution of certain programs. It's an excellent feature to use on terminal servers or machines serving as a public kiosk, so users are locked into one specific function and can't mess with administrative tools or Internet applications and utilities.
Windows can identify software to either restrict or allow in several different ways. For one, it can use hash rules, which are made by identifying characteristics of files and executables that come with a program and generating an algorithmic hash from them. Hashes are great for identifying specific versions of programs because the hash value would change when different files are used to compute the hash (which is a near certainty with newer version of a program). Certificate rules can identify software via a digital signature, which is a useful method to secure authorized scripts. Windows also can identify software via its path and the Internet zone (inside Internet Explorer) from which a particular piece of software is downloaded. Finally, Windows can create a rule that catches any software not explicitly identified either in a list or by any other rule. (Control for programs executed within a browser is lacking from the GP standpoint, but improvements to Internet Explorer in Windows XP Service Pack 2 pick up a bit of this slack.) Windows matches programs to rules in the order in which they're listed in the software restriction GPO, and if more than one rule identifies the same program, the rule that catches the program most specifically will trump any other rule.
You might be tempted to create a rule that disallows programs from running by default aside from those explicitly placed in an exception list. This seems like an easy way out, but it really can lobotomize a system unless you take great care to create an exception for every Windows executable a user might need, including his application programs. It can also step on the toes of any user logon scripts that might be necessary to create a secure environment. If you decide to go this route, it's imperative that you extensively test any restriction policies and exception lists in a lab. Also, when you do create the actual software restriction GPO, make sure to add the Domain Administrators group to the GPO's ACL and explicitly deny the Apply Group Policy permission to the GPO—this will enable an administrator to reverse the policy and not lock himself out.
Once you're ready to create the policy, follow this procedure:
1. Create a new GPO for each restriction policy. This makes it easier to disable a policy that might be overly restrictive.
2. Choose Computer Configuration or User Configuration to apply the restrictions to machines or users, and then navigate through Policies à Windows Settings à Security Settings à Software Restriction Policies.
3. Right-click Software Restriction Policies and choose New Software Restriction Policy from the context menu.
4. Set a default identifier rule: in the left pane, click Security Levels, and then right-click a specific security level and choose Set as Default from the pop-up context menu.
5. Now, create the actual rules that will catch software on which to enforce a restriction. Right-click Additional Rules in the lefthand pane. Choose New Certificate Rule and select the certificate to require or block, New Hash Rule and the file to allow or block, New Internet Zone Rule and the zone from which to allow or block programs, or New Path Rule and the file or Registry key to allow or restrict.
6. In the righthand pane, double-click Enforcement. Here, indicate how these restrictions should be enforced. Use of the following options is recommended:
"All software files except libraries" will help you avoid blocking critical system and application function files.
"All users except local administrators" indicates that Windows should enforce the policy for everyone except those in the local administrator group.
7. Next, in the righthand pane, double-click Designated File Types. On this sheet, review and add file extensions associated with applications included in the software restriction policies. The list should be fairly complete, but ensure that any scripting languages you use in your organization have their associated file extensions included.
8. Finally, in the righthand pane, double-click Trusted Publishers. Here you can specify whether normal users, local administrators, or enterprise administrators are allowed to decide what certificates to trust when opening digitally signed programs and controls.
*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide
No comments:
Post a Comment