Using Windows System Policies to Secure Client Computers

In an ideal world, a computer lab would be a pristine place, with gleaming computers that are configured perfectly and never break down, and users who happily use the computers without messing anything up.

Alas, in the real world, things are rarely so simple. One of the main problems computer lab administrators face is dealing with computers that users have messed up by changing settings, installing software, or otherwise monkeying around with them. Labs may even have users that maliciously or unknowingly break computers.

One way to stop this is by implementing system policies. System policies were introduced in Windows NT 4 and enhanced significantly with Windows 2000 Server. These policies allow an administrator to enforce certain system settings through the Windows Registry, an extremely complicated array of system settings in the Windows Operating System that became available with Windows 95. Policies can define which applications are available on the desktop or in the Start menu, who can change the desktop background and who cannot, whether users can start a command prompt, and so forth.

Unfortunately, in Windows NT these system policies are extremely complicated to create, distribute, and change. So this useful feature is out of reach for most regular users and more in the realm of Microsoft Certified System Engineers (MCSEs).

But with Windows 2000 Server, this feature became a core part of the operating system, making policies easier to create and control. However, in order to take advantage of this greater simplicity, all computers have to be running Windows 2000 or Windows XP.

It is possible to create policies and distribute them from a Windows NT server to 2000 clients, but there are limitations. These limitations are outlined in the Microsoft article, "Group Policies for Windows 2000 Professional Clients in Windows NT 4.0 Domain or Workgroups."

In this article, we will focus on the Local System Policies method for installing and distributing policies, since this method is more applicable when the organization moves to a Windows 2000 server.

In general, proper use of Group Policy requires careful planning and systematic testing prior to implementation. Using the following methods you should be able to keep track of the policies you set and troubleshoot effectively:

• Keep careful track of settings you enable or disable for troubleshooting and testing.
• Use groups to apply the settings, making sure that the administrator group does not have the security settings applied.
• Configure and test one policy at a time. Though this is time-consuming and annoying it will GREATLY help to resolve problems that arise and will help avoid "over-locking" a computer.

You should start by defining what things you want to protect. With all the available options, deciding what to implement in your environment can be overwhelming.

First identify the 10 most likely things you want to protect against. You then need to determine how to achieve this protection using group policy. You might decide to disable the run command, disable access to the control panel, or choose to Hide My Network Places from the desktop.

By focusing on the top 10 problems, you can ensure that you are fixing problems, rather than just disabling the functionality of the computer. The Group Policy editor (Select Start > Run > gpedit.msc) can be a great help when you're identifying the available options. You can select each item, click "Properties," and select the "Explain" tab to determine exactly how to control the item.

In addition, the appendices in the Microsoft Group Policy white paper white paper can help you determine what is possible using Windows 2000 Group Policy.

Keep track of each setting you want to change by using the following table:

Setting	Location	Status
Prohibit access to properties of a LAN connection	User Configuration\Network\Network Connection	Enabled

You can create policies using the following method:

1. Log on to the computer as an administrator and run the group policy editor by selecting Start > Run > gpedit.msc
2. Configure the settings according to the desired settings; they will be applied to all users that access the system. Most of the settings should be in the User Configuration > Administrative Templates folder. Configure each setting one at a time, log off and log back on to ensure that the setting is correct. If you are unclear as to what a setting does, or how to enable it, right-click the setting and select "Properties," and click the "Explain" tab.
3. Once your local policy is configured, you will want to copy the folder containing this policy to all the other computers. The files are located in %systemroot%\system32\group policy.
4. You will want to change the permissions on this folder so that the Administrator does not have access to the files. This way the policy will not be applied to the Administrator log-in.