Further Explorations of the NT System Policy Editor

Installation and Configuration Tips and Some New Tricks

In his February article, "How to Edit NT 4.0 System Policies,"Robert Slifka introduced the Windows NT 4.0 System Policy Editor (SPE)application and some of the ways you can use it to secure an NT network. Heincluded information about the use and customization of policy template files(.adm files). This month, I expand on this topic, and present some otherfeatures and potential applications of this handy utility.

If you've ever administered a group of NT workstations on a network, youknow the difficulty of maintaining a uniform configuration for all yourcomputers. This problem is especially nasty in organizations that have corporateor MIS policies that mandate certain aspects of the user's environment, such aswhat programs users can access, what control they have over their machine, andthe appearance of their desktop. Ever tried to make a custom Registry change orset the background wallpaper on 500 (or even 50) NT workstations? If so, you'llappreciate the problem and solution I describe here.

A Quick Review
NT stores all its configuration settings in the NT Registry database. Youcan view and modify these settings with one of the NT Registry editors(regedt32.exe or regedit.exe). When you examine the Registry, you seemachine-related information in a branch of the Registry called the HKEY_LOCAL_MACHINE subtree. In addition, you see information related to the currentlylogged-in user. This information appears in the HKEY_CURRENT_USER subtree (forinformation about the NT Registry subtrees and tips on editing the Registry, seeChrista Anderson, "Care and Feeding of the Registry," December 1996).

The HKEY_CURRENT_USER subtree also goes by another name: the current user'suser profile. A user profile contains a variety of information about theuser's desktop environment, such as Control Panel applet settings, networkprinter connections, Win32 application settings, and environment variables.ntuser.dat, the file that contains the user profile (the file from which theHKEY_CURRENT_USER Registry subtree is generated), is typically in the user'ssubdirectory under the user profiles directory on the local machine (e.g.,c:winntprofilessean). The system can store the user profile on a networkserver if the administrator configured the user's account to use a server-based (e.g., mandatory, or roaming) profile. The HKEY_LOCAL_MACHINE subtree, incontrast, contains settings related to user logon, network access, and othersystem-related settings.

That information is fine, but what does this review have to do with SPE?Well, imagine creating a template, or mask, that the systemautomatically applies to an NT workstation's Registry each time a user logs on,so that all the restrictions that apply to both the machine and that particularuser automatically take effect when the user logs in. Furthermore, imagine thatthis template is user- and group-specific, so that the restrictions takingeffect depend on the user's logon name and group memberships. Well, SPE doesjust that.

How SPE Works
You probably know that SPE manages two distinct types of policies: thesystem policy for users and the system policy for computers. Together, these twoentries restrict a user's access to the computer.

When users sitting at NT 4.0 computers log on to their domain with theirdomain user account, NT automatically merges the system policy for usersportion of the file (the required name for an NT system policy file) with theuser's profile (ntuser.dat), replacing any settings in ntuser.dat that don'tmatch those found in ntconfig.pol. In addition, NT adds any machine-relatedsettings defined in the system policy for computers to theHKEY_LOCAL_MACHINE portion of the Registry. The net effect? You get customizedRegistry settings for every NT computer and user in the domain, with all theappropriate restrictions in place.

First Things First: Installing SPE
The February article demonstrated how to start the SPE application, but thiscapability assumes that SPE is already installed on your system. In case itisn't (which is likely because NT doesn't install it by default), here's how toget SPE on your system. The utility ships only with the NT Server 4.0 CD-ROM andnot with the NT Workstation version (presumably because SPE is anadministrative-level tool). However, from the NT Server CD-ROM, you can installSPE on either an NT Server or NT Workstation 4.0 system.

To install SPE (which is part of a group of NT Server client-basedadministration tools), run the setup.bat file in the NT Server CD-ROM'sclientssvrtoolswinnt directory. This batch file automatically detectsyour computer's processor type and installs the files SPE requires and severalother NT Server administration tools. After installation, you must manuallycreate shortcuts to the application poledit.exe, now in the winntsystem32subdirectory on your hard disk (neither the 3.51 nor 4.0 version automaticallycreates a program group and icons for these utilities; is this capability reallytoo much to ask, Microsoft?).

Tips for Creating Your Organization's System Policy
Once you have SPE running and have created a system policy file, the nextquestion is usually what SPE settings to be concerned with. The entriesavailable in the system policy for computers and system policy for users includea variety of Registry entries that serve different purposes. For example, someRegistry values are useful for enhancing security, and others help maintain amore consistent desktop look and feel. Still others relate to areas such asperformance and task automation.

Although you can manipulate different settings with the default common.adm and winnt.adm templates, several settings are particularly worthy ofmention. Tables 1 and 2 summarize some of the moreuseful computer and user-related system policy entries, where they're located,and what area the entry corresponds to (e.g., security, performance, uniformdesktop). Table 1 lists computer-related entries, and Table 2 listsuser/group-related policy entries.

To change a policy for a particular Registry change, navigate the policytree by double-clicking the branch you want to expand (or click the + symbol atleft to expand the branch's contents one level down). Once you've expanded abranch and located a value you want to change, you'll see a check box that willbe in one of three states: grayed, white, or checked.

A grayed checkbox means that no change is stipulated for this entry. Agrayed box tells SPE to keep the setting that is already in effect for this itemfrom other policies or the system default. A white box tells SPE to disable theitem, and a checked box tells SPE to enable the item.

When you enable certain entries, SPE sometimes requests additionalinformation related to the item at the bottom of the dialog box. For example, ifyou check the box next to the NT SystemLogonLogon Banner entry to enableit, you must also enter a window caption and banner text for the custom logonbanner in the boxes below. Screens 1 and 2 show samples of editing the systempolicy for computers and users, respectively.

Policy Precedence
What happens when more than one policy applies to a given user? That is tosay, what if a user logs on to the domain, and the system policy file containsmultiple user or group entries that apply to that user (for either computer oruser policies)? In this situation, NT uses a policy evaluation process todetermine the correct policies for that user.

The pecking order goes as follows: When an individual policy exists for auser, this policy is always used in preference to any group policies defined forgroups that the user belongs to. If the user belongs to multiple groups and twoor more of these groups have policies defined, to determine which group policytakes precedence, NT uses the group priority order that the administratordefines.

In much the same way individual policies beat out group policies, grouppolicies take precedence over a default policy if one is defined. A defaultpolicy is used when no other policy definitions exist for a particular user. Ifyou have only a default computer or user policy defined, SPE will apply thispolicy to everyone, including the administrator. Therefore, if you don'twant to limit the administrator's access to the machine, at least be sure todefine a group policy that creates no restrictions for the Domain Admins globalgroup.

Using SPE as a Remote Registry Editor
You already know that you can use SPE to create policy files thatautomatically update an NT system's Registry. Perhaps you don't know, however,that you can also use SPE to directly edit the Registry of the local orremote NT computers. Let's say, for example, that you don't want to implement adomain-wide system policy, but want to use SPE to quickly and easily make thekinds of changes that Tables 1 and 2 describe to selected machines throughoutthe domain. Luckily, SPE lets you do this.

To open the Registry of a remote machine (which requires that you haveadministrative access to that machine), choose Connect from SPE's File menu. Inthe dialog box that appears, enter the NetBIOS name of the computer whoseRegistry you want to connect to (e.g., \SEAN_PPRO). Next, in the Users onRemote Computer dialog, select the currently logged-on user (typically you'llfind only one) whose user profile you want to modify. (If you plan to modify theuser profile of a particular user, first make sure that the user is logged on tothat computer; otherwise, you can't edit the user's profile via SPE.)

At this point, SPE displays icons for a computer and user as usual, butthis time, the icons represent live entries from an NT system's Registry ratherthan a static system policy file. You can now make the same kinds of changes youusually make, but in this case, NT will change only that particular machine'sconfiguration. When used this way, SPE is a graphical front-end for editingportions of the Registry. It provides better explanations of the Registryentries you're modifying and an easier interface for making the modificationsthan the standard NT Registry editors.

Some Potential Gotchas
Look out for a few gotchas with SPE. First, be careful editing systempolicies. Mistakes are easy to make, especially with items that are negativestatements such as "Do not display last logged on user name," or "DisableRegistry Editing Tools." Disabling these entries means that you dowant that statement to be true (e.g., if you clear the check box to disable thefirst entry mentioned, you're saying, "Do display last logged onuser name"). If you're not careful, you can set up an entry to do exactlythe opposite of what you intend. Remember also that you are not obligated to seta checked or unchecked state for every item in the display. If a particularentry is irrelevant for your organization or already defaults to the correctvalue, you don't need to enable or disable the value.

Also, put the policy file for your domain in the proper place on thePrimary Domain Controller (PDC). For system policies to take effect, the PDCmust find a policy file, ntconfig.pol, in its NETLOGON share, which is the%SYSTEMROOT%SYSTEM32REPLIMPORTSCRIPTS folder by default. If the fileis there and named correctly, the NT clients will automatically receive theRegistry updates (in the system policy file) that are appropriate for theirmachine (based on the computer name, username, and group memberships). If thefile has a different name or is elsewhere on the PDC, client workstations won'tproperly locate and process it.

Another oft-overlooked item is the failure to create special provisions foradministrators and power users. The failure to create exception policies forthese users when you define a system policy file can cause unnecessaryrestrictions on their desktop environments until you redefine the policy. Whenyou create a new system policy file, set up policies with the appropriatesettings for these users, right off the bat.

Finally, a special gotcha can occur in some multidomain environments. Youcan have problems when users log on to their domain account with a computer inanother domain but the domains don't use system policies. Remember the source ofa system policy is always the user's logon domain and not (necessarily) thedomain where the computer is physically located.

Let's say you log on using your account in the SALES domain (your homedomain) from a machine in the FINANCE domain (a foreign domain trusting theSALES domain). If system policies are in effect in the SALES domain, the machineyou're logging on to will receive all the system policy updates. Even after auser logs off the machine in the FINANCE domain, the policies will remain ineffect because later FINANCE domain logons won't reset system policy on thatmachine (because FINANCE doesn't use system policies). To prevent this situationwhen you're implementing system policies in a multidomain environment, bethorough and implement them in every domain; this method will ensure Registriesare reset properly.

Differences Between the NT and Windows 95 SPE
If you've used the Windows 95 SPE to manage your Win95 workstations, youmight wonder if you can combine functionality here. Can you use this NT versionof SPE to create one unified system policy file for both your NT and Win95client workstations?

The SPE online Help file alludes to the fact that some templates includedwith SPE contain Win95-specific Registry settings. Unfortunately, thedifferences in the NT and Win95 Registries preclude creating one,all-encompassing policy file that works with both Win95 and NT systems.

However, you can use the NT 4.0 SPE to manage your NT and Win95 systempolicy files independently of one another. To do so, you have to create and editthe ntconfig.pol file with SPE from an NT system and create and edit the Win95system policy file while running SPE from a Win95 system. This last point isespecially important: You can successfully create a Win95 policy only with NT4.0's SPE from Win95. Although you can create Win95 system policy files with SPEunder NT, they won't work once implemented. Furthermore, when creating andediting the NT system policy, be sure to have the common.adm and winnt.admtemplates loaded; when creating the Win95 policy file, use the common.adm andwindows.adm templates. The common.adm policy template file contains Registrysettings common to both NT and Win95 computers, whereas the windows.adm andwinnt.adm files contain Win95 and NT-specific Registry settings,respectively.

Although you can use the NT 4.0 SPE utility to create and manage a Win95system policy file when using SPE from a Win95 workstation, be aware of a fewdifferences between NT 4.0 SPE and the Win95 version. One difference is that theNT 4.0 version of SPE is capable of using multiple .adm Registry templatessimultaneously; Win95 SPE can use only one at a time. Despite this limitation, Ifind that the default template file Win95 SPE uses (admin.adm) includes someuseful entries I did not find in the two files (common.adm and windows.adm) theNT version includes. Capabilities such as restricting the Network Control PanelApplet are conspicuously absent from the NT version. Check the settingsavailable in both the NT version and the Win95 version before deciding which SPEversion to use. You can have the best of both worlds if you use the admin.admtemplate to create a Win95 policy file with NT SPE. Copy the admin.adm file tothe windowsinf directory of the Win95 workstation you use to create thepolicy.

An Invaluable Tool
NT SPE is an invaluable tool that no NT network administrator will want tolive without. It is a multipurpose application that can serve as an alternativeto the somewhat foreboding NT Registry editors, as a Registry editor for remoteworkstations, and as a centralized control mechanism for implementingdomain-wide computer and user policies.