A system policy can help you manage your users and computers more efficiently. You can create a policy that will prevent users from accessing many aspects of the desktop, as well as define the applications that are allowed to run. In this Daily Drill Down, I’ll discuss policies for Windows NT and how to create and implement them. I’ll also walk you through an example of how to set up a policy for a user.
What is a system policy?
A system policy is a set of registry settings that defines the computer resources available to a group of users, a computer, or an individual user. Policies define the aspects of the desktop environment that a systems administrator needs to be able to control. These aspects include which applications are available, which applications appear on a user’s desktop, which applications and options appear in the Start menu, and who can change attributes of their desktops.
A policy can help simplify system administration, but it deserves careful planning. Be sure to consider points such as:
- Should you set group or user settings?
- Are your computers located across a large geographic area? If so, the computers may be more effective when retrieving policy files from a computer that’s closer in proximity, as opposed to a domain controller.
- What type of restrictions do you want to implement?
- Be careful that administrator-defined program groups, shortcuts, and so forth don’t override locally installed groups.
- Are there any other options that could give you the same results, such as NTFS permissions?
Once you’ve taken these factors into consideration, you may be ready to create or modify a policy.
Modifying default policies
Windows NT comes with built-in policies for all computers and users. You can find the Default Computer and the Default User policies in the System Policy Editor. To get to the System Policy Editor from a domain controller, go to Start | Programs | Administrative Tools | System Policy Editor. In their original state, the Default policies don’t restrict access. You must double-click the policy you wish to modify to pull up a list of the restrictions that you can impose. I’ll discuss the restrictions in more detail later in this Daily Drill Down when I go through the example. Any changes to the Default policies will affect either all Default Users or all Default Computers, depending on which one you choose to modify.
Creating a system policy
The System Policy Editor enables you to create system policies. The System Policy Editor is a graphical tool provided with Windows NT Server 4.0 that allows you to easily update the registry settings that will generate the correct environment for a particular user or group of users. The System Policy Editor creates a file that contains registry settings, which are then written to the user or local machine portion of the registry database each time that user logs on. User profile settings (that are specific to a user who logs on to a given workstation or server) are written to the registry under HKEY_CURRENT_USER. Likewise, machine-specific settings are written under HKEY_LOCAL_MACHINE.
When a user logs on to a Windows NT 4.0 computer, the user’s profile is loaded first, and then the system policy is downloaded. These registry changes take effect before the user has control of the desktop. If you make a change to the system policy, it won’t affect users who are already logged on. Any affected users will have to log off and then log on again before the new policy is implemented.
A good use of a system policy
If your computers have multiple uses, they are good candidates for a system policy. For instance, staff may also use computers that are used in a training lab. In a training environment, you’d probably want to limit access to the desktop and programs, but you’d still want to allow the staff full control. In this situation, you could create a system policy based on the trainee’s user name. Your policy could restrict access to the Control Panel, Wallpaper, Color Scheme, the Run command, Network Neighborhood, the drive in My Computer, and so forth. When a trainee logs on to the computer, the current registry is changed by the system policy to implement the restrictions. When a staff member logs on to the computer, the system policy is not applied, and full control to the computer is permitted.
System policy limitations
If you wish to implement a system policy that prevents users from deleting files when logged on, you could restrict access to the hard drive, eliminate the Run command, and allow only certain programs to run. This will work to a certain extent—I’ve found that some programs, such as Microsoft Word, Excel, and PowerPoint will still allow the user to access hard drives even when the System Policy Editor has restricted access to the hard drive. These programs allow you to delete and rename files from within. Other programs, such as Paint and Notepad adhere to the policy restrictions.
In short, if you restrict access to the hard drive in your policy, there are still ways around it. If the drive is formatted with NTFS, you can further restrict access at the local machine. One option that you can pursue with programs that ignore the hard drive access restriction is to change the default path where files are saved. If you make drive A the default path, the novice user may be prevented from browsing the drive and causing damage.
Group policies don’t operate in a NetWare-only environment because Windows NT checks for Windows NT global groups only—not NetWare groups. Administrative accounts are not exempt from policies, which should be a key factor to consider when implementing policies. If you create a policy for a computer, that policy will also restrict the administrative accounts.
The location of the system policy
If you create a policy that will be automatically downloaded from validating domain controllers, you should name the file Ntconfig.pol and place it in the \WinNT\System32\Repl\Scripts\Export directory (this is also the NetLogon Share on the PDC). If you’re the systems administrator, you can rename the policy file and, by modifying the Windows NT-based workstation, you can direct the computer to update the policy from a manual path. You can do this by either manually changing the registry or by using a system policy. This path can even be a local path and the local machine can have its own policy file, but if you have to make a change to all machines, this change would have to be made individually to each workstation.
To create a new policy for a domain
Follow these instructions to create a new policy for a domain:
- Open the System Policy Editor (Start | Programs | Administrative Tools | System Policy Editor).
- From the File menu, select New Policy.
- To specify the computers to which your registry-setting changes will apply, you can do the following:
Double-click Default User to change HKEY_CURRENT_USER Registry settings for all computers on the domain.
Double-click Default Computer to change HKEY_LOCAL_MACHINE Registry settings for all computers on the domain.
- To add to the registry settings and create a new policy for a specific user, group, or computer, select Commands from the Edit menu to do the following:
To change HKEY_CURRENT_USER for specific users, click Add User.
To change HKEY_LOCAL_MACHINE for specific computers, click Add Computer.
To change HKEY_CURRENT_USER for specific groups click Add Group.
In our example, we’ll create a policy for the user Test. After you have created the initial policy name, a new icon called Test will appear in the System Policy Editor window.
When you double-click the icon you created for the new policy (Test), you’ll see the Test Properties dialog box. From here, you will see the main tree structure for the available restrictions:
- Control Panel—Enables you to restrict access to the Control Panel. In the bottom pane of the Properties window, you will see the available restrictions (Settings For Restrict Display).
- Desktop—You can restrict the Wallpaper and Color Scheme settings to ensure that the same wallpaper and color scheme are used every time the targeted user logs on.
- Shell—You can remove the Run command from the Start menu, which will prevent the user from getting around other restrictions you may have set. Some of the other valuable restrictions that are available include: Hide Drives In My Computer, Hide Network Neighborhood, Hide All Items On Desktop, Remove Shut Down Command From Start Menu, and Don’t Save Settings At Exit. It’s possible to restrict the access to the computer to the point that the user can hardly do anything.
- System—Allows you to deny access to the registry editing tools, which are probably the most powerful and potentially destructive tools on your computer. From here, you can also restrict the applications that the user is allowed to run. Click the Show button in the bottom pane of the Properties sheet to view the window that allows you to configure the allowed applications. To add an application, click the Add button and type the name of the file that runs that application.
- Windows NT Shell—Allows you to configure a custom look for the user’s desktop and interface. You can customize features such as Network Neighborhood, desktop icons, program folders, and the Start menu. You’re also allowed to restrict several other items including: Remove File Menu From Explorer, Remove The Map Network Drive and Disconnect Network Drive, and Remove Common Program Groups From Start Menu.
- Windows NT System—Enables you to restrict access to components such as: Disable Logoff, Disable Task Manager, Disable Lock Workstation, and Disable Change Password.
- Windows NT User Profiles—Allows you to limit the profile size and exclude directories in roaming profiles. You can input the settings for the profile in the bottom pane of the Properties sheet.
When you’re finished creating the policy, be sure to save it as NTconfig.pol in the NetLogon Share.
The policy is enforced on each computer running Windows NT Workstation or Windows NT Server when users log on. If you create a policy for a user and he or she is already logged on, the policy won’t take effect until the user logs off and logs back on again.
System Policy Editor template (.adm) files
The System Policy Editor uses administrative (.adm) files to determine which registry settings can be modified. An .adm file is a template that consists of categories and subcategories that dictate which settings are available through the user interface. An .adm file contains the registry locations where changes must be made for a particular selection. You can create your own template file by using a text editor to modify the Winnt.adm file. You should make a copy of the file first.
You have to use Server Manager to configure directory replication. Replicating the Netlogon folder from the PDC to all backup domain controllers (BDCs) will ensure that the policy file and logon scripts are copied to the domain controllers.
The order in which groups are evaluated is important if some users belong to more than one group for which a policy is defined, and if the policy settings in two or more of these groups contain different settings for the policy. To specify which policy has priority, use Group Order to order the groups.
To set the group priority, do the following:
- From the Options menu, select Group Priority.
- Select a group in Group Order, and select Move Up or Move Down.
Groups at the top of the list have the highest priority.
Using the Policy Editor to change the registry on remote computers
You can also use the Policy Editor to modify the registry on a remote computer. To accomplish this, do the following:
From the File menu, select Connect.
Type the name of the remote computer.
In the Users on Remote Computer dialog box, click the user that is interactively logged on, and then click OK.
Double-click Local User to change HKEY_CURRENT_USER registry settings.
Double-click Local Computer to change HKEY_LOCAL_MACHINE registry settings.
From the File menu, click Save.
From the File menu, click Disconnect.
Many administrators overlook the System Policy Editor as a tool that can help simplify network administration. It’s a very flexible tool that’s easy to use. Make sure that you plan and test your policy before you implement it.
Troy Thompson, MCSE+Internet, has worked in the automation field for 15 years, dealing with a variety of systems: Wang OIS, Unisys BTOS, UNIX, Windows 3.11, Novell NetWare, Windows NT 3.51, and Windows NT 4.0. He’s also worked as an administrator of a Novell and NT network, as well as a systems analyst for an IBM mainframe. Currently, Troy is the Information System Security Officer at the Information Management shop at Fort Knox. If you’d like to contact Troy, send him an e-mail.
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.