Microsoft Small Business Server 2003 Unleashed

As showcased in Microsoft KB article 320065 (http://support.microsoft.com/?id=320065) under the category of Computer Configuration\Windows Settings\Security Settings\Restricted Groups, add a group under the local computer that will be restricted users and add your organizational unit members there.

Unfortunately, if it was as easy as this, we would all be operating our workstations in this manner. Chapter 21, "Managing Workstations Through Group Policy," lists some of the specific items you can consider locking down; however, it's recommended by Microsoft to use the Groups feature instead of adjusting every item, line by line. The reality is much different. Many line-of-business applications run in offices require either local administrator rights or power user rights. Now power user rights many not sound that unreasonable until you read Microsoft Knowledge Base Bulletin 825069 (http://support.microsoft.com/default.aspx?scid=kb;en-us;825069), which clearly states that a member of the Power Users group may obtain administrator rights; therefore, the use of Power User is not recommended.

Although running as a restricted user is not the answer to all virus and worm issues, it does go a long way toward blocking one particular threat in a firmthat of the end user who is tricked into downloading a piece of unwanted software. That unwanted software could easily include Trojans, backdoors, keystroke loggers, or other malicious software. Protecting your users by preventing them from being tricked into downloading software goes a long way toward helping the overall defense in depth. Discuss this process with your clients.

The first step is to change one user's machine to restricted user and identify all the software that will not properly operate in this mode. Typically, the application will not launch from the normal process. An easier way may be to simply determine that an application has the Designed for Windows XP logo because those applications are required to support running in restricted user mode. You may want to investigate software vendors that have obtained this logo for their software.

If the software is not certified, you must determine what Registry permissions need to be adjusted. Two software tools, FileMon and RegMon (both of which are available at http://www.sysinternals.com free of charge), can be used to identify these Registry and folder permission changes.

You may first begin this process by using Google to see whether anyone else has gone through this process with the application you are attempting to do this on. You may find that someone has already identified the Registry and file permissions.

Change the workstation to restricted user, launch RegMon with RunAs rights, and now launch the application. Right click and click on RunAs; enter administrator credentials to review those Registry keys that the software applications are requiring full rights on and note these.

As a general rule, the file location needs to be opened up as well as the Registry keys for the application. In some cases you may find that the application dynamically adds so many Registry keys to certain hives to make it nearly impossible to specifically identify those Registry settings. Thus you may need to balance the time you spend to perform this process with the benefit from protection. You may end up merely opening an entire hive such as ClassesRoot. Note that in this example, it is not the author's preferred recommendation, but rather the accepted balance between time spent attempting to identify the needed hives, versus the benefit of at least ensuring that some protection is offered to the end user. Exposing the entire ClassesRoot hive is not preferred, but rather a compromise.

Those items on which you need to adjust the permissions are as follows:

• Assign full permission to C:\Program Files\Intuit.

• Assign full permission to C:\Program Files\Common Files\Intuit.

• Assign full permission to HKEY_LOCAL_MACHINE\SOFTWARE\INTUIT.

• Assign full permission to HKEY_CLASSES_ROOT.

Although you could walk around to each workstation and manually add these Registry and file permission changes, in a network setting, you can use the power of group policy to perform these steps to the needed workstations. Identify those users who need these settings.

Setting Up a Security Group

The first step is to set up a security group that includes only those users who need these rights. There is no need to deploy these settings to all authenticated users, but only to the needed user.

Click on Server Management and then on Active Directory Users and Computers. On the right-hand side of the screen is the Add a New Security Group option. Go through the wizard to add a new security group, making sure that it has a descriptive name, unique enough so that you know what the group is used for. Add only those users to whom you want the policy applied.

Now you need to build a policy to set the permissions. In SBS 2003, open up the Group Policy Management Console. Under the domain, right-click and select Create and Link a GPO Here. Name the group policy, again using a descriptive name so that you can know that you have added the policy. Do not adjust an existing policy, but rather ensure that you are setting up a new one. Right-click on the newly named policy and click Edit to begin the process of building the policy. Scroll down to Computer Configuration, Windows Settings, Security Settings, and then to File System, as shown in Figure 10.2.

Click on Add File, and a window that looks like a standard computer browser window appears. In the Folder location box, type in C:\Program Files\Intuit and click OK (see Figure 10.3).

Click on Advanced and then click on Find Now. Scroll down and click to add the specific security group you built earlier, and specifically add Full Control (see Figure 10.4).

In the Add Object dialog box, select Configure This File or Folder Then and Propagate Inheritable Permissions to All Subfolders and Files (see Figure 10.5).

Now do this again for C:\Program Files\Common Files\Intuit following the same instructions. The resulting screens for files should look like Figure 10.6.

Now perform the same process for the Registry keys. In the same window, select the hive of Registry and right-click on Add Key. Remember, you don't need to use the HKEY part of the hive. You want to add permissions to HKEY_LOCAL_MACHINE\SOFTWARE\INTUIT. We remove the HKEY_LOCAL MACHINE and when building our rule, only need MACHINE and then the SOFTWARE key and then add a slash "\" and the word "Intuit," as shown in Figure 10.7.

As before, adjust the permissions of this entry you made, scrolling down and finding the security group you added earlier. Add full permissions and allow propagation. Finally, once again, choose Registry, Add key; browse to the entire key of CLASSES_ROOT (see Figure 10.8) and change the permissions to your security group to Full Control.

After those four steps are complete, type gpupdate /force in a command prompt or in Start, Run to force the policy's effect. You should now be able to use this software in restricted user mode on your workstations.

The key to this process is finding the hives that need to be adjusted for permissions. It is preferable to have software that supports restricted user mode from the beginning, so keep this in mind when identifying line-of-business software for your clients' use.

Note

For an alternate method (and quite probably more secure method) of adjusting the permissions of the registry hives, review the instructions at http://www.quickbooksgroup.com/webx?14@@.eeb323b/9. This method also allows the user to update the program for payroll updates.

Microsoft Vista will utilize more of this restricted user mode concept. Therefore, if you purchase this software that supports this now, you will be better able to protect your desktops in the future.