April 1999

Take Security to the Next Level with System Policies

In last month's issue, we showed you how to enforce control over your users' work environment by using mandatory local or roaming profiles. For those environments where the use of mandatory profiles isn't enough, or is inappropriate, you can take security to a whole new level through the use of system policies. For example, you can create a policy specifically for your Guest account that prevents anyone who logs on as a guest from browsing your network.

A System Policy is a group of registry settings that define the desktop settings and computer resources available to an individual user or a group of users. After careful planning, you can use the System Policy Editor, shown in Figure A, to create a policy that not only helps to simplify your network administration duties, but also secures your network. In this article, we'll show you how to create and implement an effective system policy.

Figure A: Use System Policy Editor to create or modify a policy.
[ Figure A ]

The technique

Before creating an effective and functional system policy, you must make some determinations as to whether using system policies will actually help simplify administration and increase security, or create a support nightmare. For instance, what type of restrictions do you want to force on your users? Once you decide that you want to implement system policies, use System Policy Editor (SPE), shown in Figure A, to create a new policy file. Next, use SPE to modify the Default policies and create policies specific to an individual or group. Then, after you have the policy file properly configured, you save it to the validating domain controller.

Precautions

For this procedure to work correctly, the most important thing to remember is that the Ntconfig.pol file must be located in the NETLOGON share on all validating domain controllers. If the workstation doesn't find the policy file in the correct location, then no policy will be applied and the user may log on with more capabilities than you want him to have.

The easiest way to ensure that the Ntconfig.pol file exists in the NETLOGON share of all your validating domain controllers is through the use of directory replication. Through directory replication, you can also make changes to the Ntconfig.pol file and have those changes duplicated across all domain controllers. That way, you'll know that all users are using the latest and greatest system policy.

When implementing system policies, it's also important to remember that no accounts are exempt--including Administrator accounts! So, make sure that you create a policy specifically for all those with Administrative rights.

Creating a policy

Before beginning a new policy, launch System Policy Editor from your Windows NT 4.0 server by clicking Start/Programs/Administrative Tools/System Policy Editor. If you don't want to work directly on the server, you can install SPE on one of your Windows NT 4.0 workstations in the domain by copying the SPE executable (Poledit.exe) and the template files with an ADM extension from the server to the workstation. The Poledit.exe file is located in the \Winnt directory, and the ADM files are in the \Winnt\INF directory. After you copy the files to the corresponding directories on the workstation, you can run SPE by clicking Start/Run and typing Poledit in the Open dropdown list box. To create a new policy, open the File menu and select New Policy. You should now see icons representing the Default Computer and Default User, shown in Figure A. As we mention in the "Behind the scenes" sidebar, when a system policy is in place, the Default User policy applies to all users that don't have their own user policy. Therefore, if you want to standardize control over all users, the easiest way would be to modify the Default User policy.

Modifying the Default User

To begin modifying the Default User, double-click on the Default User icon. When the Default User Properties dialog box shown in Figure B appears, select the configuration options you'd like to apply to anyone who falls under the Default User policy (that is, all users who don't have an individual user policy). The structure of SPE is similar to Windows NT Explorer and, therefore, can be navigated in the same way.

Figure B: Modify the Default User policy settings through the Policies sheet in the Default User Properties dialog box.
[ Figure B ]

As Figure B shows, you can either leave an option's check box shaded, select it, or clear it. If you leave the box shaded, that option is ignored, and the Registry setting on the workstation won't be modified when the policy is applied. The original configuration for the Default User policy is that all the check boxes are shaded in. If you select a check box, that option is enabled and the change is written to the workstation's Registry the next time the user logs on. For example, as Figure B shows, when our Default User policy is applied, the user won't have Taskbar on the Settings menu. Clearing the check box is similar to selecting it--except the option is then disabled rather than enabled.

When enabled, some of the options have additional settings that appear in the panel at the bottom of the Policies sheet, as Figure C shows. For example, once you enable the Run Only Allowed Windows Applications setting, you can further specify which applications to run by clicking the Show button.

Figure C: When some of the settings are enabled,they allow you to make further configuration changes.
[ Figure C ]

Once you finish configuring the settings for the Default User policy, click the OK button to close the Default User Properties dialog box. Just remember--if you restricted the Default User policy, the Administrator account isn't exempt from these restrictions unless you create a separate Administrator policy.

Creating a policy for the Guest account

Although you can quickly standardize control by modifying the Default User policy, the more likely scenario is that you'll want the majority of users to retain their default settings while you modify the settings for a select minority. Take our example of the Guest account. To secure your network from intruders, you can add a policy for your Guest account and restrict access to network resources.

You can do so by selecting Add User from the Edit menu. To locate the Guest user on your domain, click the Browse button and select the user from the Names list box. Or, type Guest in the Type The Name Of The User To Add text box. Next, click Add and then click the OK button. The new user policy takes on all the configuration settings of the Default User until you make the necessary modifications.

For the Guest account, we recommend enabling several of the settings you'll find by double-clicking first Shell and then Restrictions. To prevent the guest from browsing your network, you should enable the Hide Network Neighborhood setting as well as the Hide Drives In My Computer setting. We also recommend enabling the Remove Find Command From Start Menu--although a resourceful user may still be able to launch Find through alternative methods. Depending on how much control you want to enforce over those who log on as Guest, you'll find a multitude of other settings available. When you're finished, click OK to close the Guest property sheet.

Creating a group policy

In medium- to large-sized organizations, keeping track of many individual user policies can become a support nightmare. Therefore, we recommend instead that you create group policies that apply to multiple users in order to simplify administration.

For example, if you restricted the Default User account in any way, you may want to create a group policy specifically for the Domain Admins group to free them from those restrictions. Then, use the Group Priority function that we demonstrate in the "Behind the scenes" sidebar, to give the Domain Admins group the highest-ranking priority. To create the Domain Admins group, select Add Group from the Edit menu. Then, click the Browse button to browse for the Domain Admins group, or type Domain Admins in the Enter The Name Of The Group To Add text box and click OK.

Now let's configure the Domain Admins group. To begin, double-click on the icon to open the Domain Admins Properties dialog box. The group takes on all the same settings as the Default User, so you should remove any restrictions you applied earlier. For example, if you applied the setting to Remove Run Command From Start Menu, as shown in Figure B, then clear the check box so the Domain Admins have access to the Run command. Keep in mind that the Default User settings take precedence over any settings that are ignored (shaded check boxes) in the group policy.

Modifying the Default Computer

Once you've modified the Default User and/or added individual user and group policies, your next step is the computer policy. You need to modify the Default Computer if you want to adjust the Registry settings that apply to all users who log on to a machine without its own specific policy. You can modify the Default Computer settings in the same way you modified the Default User after you double-click on the Default Computer icon.

You can also leave the Default Computer configuration as is if you don't want to make any changes to the Registry settings. Then, to modify the settings on a specific computer, you can always add the computer to the system policy by selecting Add Computer from the Edit menu.

Once you've added all the necessary users, groups, and computers to the system policy, save the policy file. To do this, select Save from the File menu and navigate to the \Winnt\System32\Repl\Import\Scripts directory (NETLOGON share) on the domain controller. Type Ntconfig.pol in the File Name text box and click the Save button. Now, close SPE and your new policy will take effect as the users log off and log back on again.

Conclusion

System Policies are a feature provided with Windows NT to help simplify the administration of your users and workstations. However, implementing a successful policy requires thorough planning on your part. In this article, we've provided you with some crucial information that will help you determine whether the use of system policies is right for your organization.


Copyright © 2000, ZD Inc. All rights reserved. ZD Journals and the ZD Journals logo are trademarks of ZD Inc. Reproduction in whole or in part in any form or medium without express written permission of ZD Inc. is prohibited. All other product names and logos are trademarks or registered trademarks of their respective owners.