Windows NT System Policies

At a recent Microsoft briefing for enterprise customers, one presenter asked attendees whether they were using Windows NT 4.0's system policy features. A small percentage raised their hands, and an even smaller percentage kept their hands up when the speaker asked whether they had an inhouse resource person who understood how system policies work.

NT system policies are useful for managing user and machine Registry changes in the enterprise. They help systems administrators centralize configuration control in large and small NT environments. They also ease problems associated with desktop configuration management, such as delivering icons to your users' desktops. However, NT system policies can be difficult to configure, can cause widespread damage, and can become unmanageable if you're not careful.

System policies in NT 5.0 will be more powerful than those in NT 4.0. To take advantage of NT system policies, you need to understand how to efficiently implement this tool in your NT infrastructure--what works and what doesn't. In this article, I'll focus on the benefits and challenges of implementing system policies in real-world enterprise NT environments. For a review of how system policies work and how you can customize them, see "Related Articles in Windows NT Magazine," page 148.

The Power of Policy
NT system policies let you deliver user- and machine-specific Registry changes each time a user logs on. You can use the System Policy Editor (SPE) and templates that define which Registry keys your policies affect to create policy files that perform various functions. The default implementation for a system policy is to use the SPE to create an ntconfig.pol file, and copy the file to the replication directory in your domain controller infrastructure. The replicator service then replicates this directory to all other domain controllers, and makes it available via a Netlogon share. If you implement a single or multiple master domain model, you must replicate ntconfig.pol in the master account, or authenticating domain. The ntconfig.pol file has no effect in the resource domain. Even if the computer is registered in the resource domain, the authentication or master account domain delivers policies when a user logs on. You can change the policy file's name and the location where NT workstations look for policy files. You can also have multiple policy files that various NT workstations in a domain can use, which I'll discuss later.

System policies are powerful and can solve many problems. For example, in your work to solve the Year 2000 compliance problem in your NT environment, you might realize that the default configuration on your 5000 NT workstations is to display dates with only two characters to represent the year (e.g., MMDDYY). You can use the user's profile in the Registry (the HKEY_CURRENT_USER Registry hive) to change this date representation to MMDDYYYY, and you can easily create a special policy template that includes this Registry key. Then you can build a new policy file that incorporates the new template, assign it to Default User, and replicate it to your domain controllers. The next time your users log on, NT will update their default date display.

Security Through Obscurity
System policies can secure the user's desktop to reduce the costs of maintaining your NT environment. Microsoft provided the Zero Administration Kit (ZAK) to help reduce the total cost of ownership (TCO) for your NT environment. (For more information about ZAK, see "Zero Administration Kit: The Answer to Your TCO Woes?" January 1998.) ZAK provides extra system policy templates that let you augment NT 4.0's standard templates--common.adm and winnt.adm. You can use these default templates, ZAK's templates, and custom templates that you develop to lock down desktops and prevent users from performing unsafe tasks.

Most restrictions that system policies enforce merely hide features from the errant user rather than provide true security measures. For example, you can use a system policy to remove the Run command from the Explorer shell's Start menu. But a clever user can run a command shell via several back doors, including File Manager (which doesn't respect system policy settings), the MSinfo utility that comes with Microsoft Office, macros, and Visual Basic for Applications (VBA). Likewise, you can use a system policy to prevent a user from interactively running regedit or regedt32, but the user can write a Registry script and use regedit to run it from a command line or association (e.g., regedit myfile.reg).

When you consider implementing policies to secure the desktop against tampering, you need to remember that policies affect user and machine Registry settings only: They don't modify file or Registry access control lists (ACLs) or change a user's NT security context. Policy restrictions work because the Explorer shell checks the user or machine Registry for Registry keys, and then permits or denies user actions based on these keys. Most restrictions related to the Explorer shell (e.g., removal of Start menu elements, access to Network Neighborhood) are in one key in a user's profile--HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies--and Registry settings in this key control most user-specific policies that you set. Typical Registry permissions give users full control over their profiles. But the Policies key is read only, so users can't tamper with policy restrictions.

Policy-based desktop restrictions have inherent limitations, but policies are valuable in managing the enterprise desktop. For example, you can use a policy to remove multiple users' desktop elements at once. Shared folders provide another powerful policy feature. With shared folders, you can use policies to deliver file folders and application shortcuts to a user's desktop similarly to how you deliver desktop restrictions.