6.1 All About System Policies

Windows 2000 supports aggregating users into groups and domains. You can assign users to a particular group or domain, then grant (or deny) permission to use certain system resources based on their membership. For example, you could create a group of users in the accounting department and grant that group access to the printer in the department conference room, without having to grant printer access to users from outside the department. For a complete explanation of managing users, groups, and domains, see Essential Windows NT System Administration, by Æleen Frisch (O'Reilly & Associates).

Besides offering access controls so that users and groups gain or lose access to individual files, shares, servers, and printers, NT 3.1 offered a set of features you could customize on a per-machine or per-user basis. As you might guess, these settings were just keys in the Registry; an example is the warning notice that you can add to the logon process by adding two new values to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Even though these settings were present, there were two serious flaws that made them more difficult than necessary to use:

They weren't organized well

Even though there were a large number of customizable settings in NT 3.1, 3.5, and 3.51, there was little in the way of organized documentation, and related settings weren't grouped together in the user interface (or in any other meaningful way).

They were too hard to use

None of the adjustable settings were difficult to change in and of themselves, but trying to add a logon warning to one machine is much easier than trying to do so for an entire network of several thousand machines. To compound the problem, savvy users could change the settings (assuming they had appropriate privileges).

Microsoft addressed these flaws in the NT 3.51 Resource Kit with the introduction of tools for managing system policies. These policies were nothing more than groups of settings: one group that controlled the appearance of the desktop, one that controlled what programs users could run, and so on. However, the key innovation was a mechanism for distributing policies to all computers in a domain. This made it possible for an administrator to write policies for individual users, groups of users, and individual machines, then let NT take care of the actual work of distributing the policies to each machine in the domain and applying them.^[1] These policy mechanisms were included as a part of the standard installation for Windows NT Server 4.0 and the Windows 2000 Server family.

^[1] Windows 95 and 98 may have system policies applied too, though some of their policy elements live in different keys than the NT equivalents.

6.1.1 Why Is This in a Windows 2000 Book?

Windows 2000 introduced Active Directory. It turns out that among its other features, Active Directory provides a new, and greatly improved, mechanism for setting and delivering system policies. Group policy objects (GPOs) provide a more scalable and greatly expanded set of policies than the tools that shipped with Windows NT 4.0. You might wonder why Microsoft even included the policy tools described in this chapter with Windows 2000. The answer is simple: you can't use GPOs to apply policies on computers that don't support Active Directory. That means that Windows 95, 98, and NT clients are out of luck, as are Windows 2000 computers that aren't part of an Active Directory domain. To effectively set policies on a mixed network, you need to use the NT 4.0 policy mechanism -- detailed in this chapter -- to set policies for these downlevel clients; you normally use them in conjunction with GPOs, as described in Chapter 7.

When you use the NT and 2000 policy systems in combination, you actually end up having to maintain policy settings in two separate places. This is undesirable, but it's better than having no policy capability for older clients.

6.1.2 What's a Policy?

A policy is nothing more than a group of related settings whose values you can specify. Each policy typically has a name, such as "Shell Restrictions." Policies are arranged in a hierarchy like Registry keys or disk files and folders. You use policies to enforce access controls on what users can do. For example, there are policies that let you to restrict what applications users may run, whether they can change the desktop pattern, or what resources can appear in the Network Neighborhood.

6.1.2.1 Categories contain one or more policies

Each user, group, or computer policy is actually made up of several policy categories. For example, the default policy template provided for NT machines provides categories such as "Control Panel" and "Windows NT Shell." Each category in turn contains individual policies such as "Restrict access to desktop" or "Hide Settings tab." This usage can be a little confusing: a user policy can contain several categories, each of which can contain several policies. I use the term "policy" to mean the policies that live in a category and "user policy" to mean the policy settings applied to a user, group, or computer.

6.1.2.2 Policies are made of parts

Policies are made up of parts. Each part represents one aspect of a policy, such as "don't allow users to use the StartRun... command" or "here's a list of applications that the user may run." Parts got their name from the fact that each part of a policy has a control associated with it. Parts have values, and these controls allow you to set them. The permissible set of values for a part depends on what the part controls. Some parts need numeric values, while others accept lists of programs or true/false values.

A single policy may consist of one part or many. Each part within a policy corresponds to a value stored somewhere in the Registry. When you enable a policy, what you're really doing is telling the target computer to assign some particular value to each part in that policy. That in turn forces certain values in the Registry (each of which corresponds to a single part) to have particular values as well. You'll see some more concrete examples later in the chapter. Note that these Registry changes are persistent, an effect known as Registry tattooing.

6.1.2.3 How are policies defined?

Policy definitions are built using policy templates. These templates are nothing more than text files that tell POLEDIT what to display in its interface and how to convert the user's settings into a .POL file.

When you install any of the Windows 2000 or NT Server products, you get three policy files in %systemroot%\INF : WINNT.ADM (which holds settings specific to Windows 2000 and Windows NT), COMMON.ADM (which holds settings that apply to both Windows 9x and NT/2000), and WINDOWS.ADM (the Win9x-only settings). These standard files cover most of the things you can restrict or constrain with policies. However, it's possible for third parties to write policy templates that add new policy definitions for other software. The most widely known examples are Microsoft's Office policy templates; these templates let you restrict Office-specific settings, such as which hosts appear in the FTP dialog within Word. Other vendors have produced policy template files, and you can even create your own (as described in Section 6.3.5 later in this chapter) to control applications that don't ship with their own templates.

The template files use a simple language to specify which keys and values are affected by the policy and its parts. When you create a template, you're really giving POLEDIT instructions on what to display and how to build a .POL file based on the user's policy settings; the system policy mechanism applies that file's changes without regard to what they are.

Simac Software makes a product called Policy Template Editor (see http://www.tools4nt.com/). It's a specialized tool, but it works very well and is much easier than editing template files by hand.

6.1.2.4 User versus machine policies

The policy mechanism allows you to build policies that apply to computers, individual users, or groups of users. Computer policies apply to all users on a machine; they're stored in each machine's HKLM root key, and they remain in effect no matter what user logs on to the machine. By contrast, user and group policies apply only to the user or group named as the target, and they are automatically downloaded and installed onto each machine the user logs into. (The system evaluates group membership at logon time to decide which policies should be applied to the user account logging on.)

Here's an example. Let's say you have four machines in your domain: titan, minuteman, atlas, and trident. Within this domain, you have a few dozen user accounts, but you create policies that apply to two accounts: intern and visitor. Whenever either of these accounts logs into a machine, the defined policy is downloaded from a domain controller and is stored in that machine's HKCU root key. Whenever any other user logs into a machine, the default policy settings will be in effect.

6.1.3 How Are Policies Stored?

Like butterflies, policies go through a number of stages between their initial creation and their final emergence. Understanding where policy settings live at each stage of their lifecycle is key to understanding how to build and apply them.

The System Policy Editor stores policies as individual .POL files. You can think of these files as similar to Registry hives, as they contain a number of Registry key/value pairs that are loaded into the target machine's Registry when the policy is applied. When you create a policy and save it, you're actually generating a file that tells the System Policy Editor what values to change in the policy target's Registry.

Unlike the hives you can create with RegEdt32, these files can contain values from several different subkeys without having to hold the entire contents of their superior root key. For example, a single .POL file might contain values for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and HKLM\SOFTWARE\Netscape\Netscape Navigator, without having to contain all of HKLM\SOFTWARE as well.

When you first create a policy, its .POL file is stored wherever you choose to save it. Once you've created and saved a policy file, the next stage of its lifespan begins: distribution. You can manually apply a policy file to individual machines; you may also store it on a Windows NT or Windows 2000 domain controller so it is be replicated automatically to Windows 95/98 and NT machines in your domain. You may choose to replicate the policy to backup domain controllers if you want users to get the correct policy setting when the primary controller is unavailable.^[2] (In fact, if you want the policy to be automatically distributed, you must put it on the PDC and any BDCs that have replication enabled if you want to ensure that the policy is available.)

^[2] This scheme changes somewhat in Windows 2000, since there's no longer a distinction between primary and backup domain controllers. In that case, you should put the policy files on whichever Windows 2000 server is acting as the PDC emulator.

The final step in a policy's lifetime is the actual installation process. When a computer boots, or when a user logs into a machine running Windows 9x, NT, or 2000 Professional, the system checks the domain controller for an applicable policy. If there is one, a special system component called the policy downloader ^[3] transfers the .POL file to the workstation and merges its contents with the appropriate Registry root key.

^[3] It's unlikely that you'll need to, but Microsoft provides a mechanism for writing your own policy downloaders, which can supplement or replace the system's. Complete documentation for this is included in the MSDN SDK documentation.

6.1.4 How Are Policies Applied?

Once the policy downloader has pulled the policy file down to the workstation, the policy's settings still have to be applied. This is accomplished by merging the policy settings into the appropriate parts of the Registry. As you'll see in more detail later in the chapter, policy parts can have three values:

On

The part's policy is active, and whatever settings are enforced by that part should be applied.

Off

The part's policy is active, and that part's settings should be forced off.

Leave as is

Whatever value is currently in the Registry should be left alone.

If a part's corresponding value in the Registry matches the policy's value, no changes are made. If the part's value is "leave as is," no changes are made either. However, if the part's specified value and the Registry's contents are different, the policy value wins out, and the Registry's value is changed. These changes persist as long as the user's logged in, but--since the merge operation is really just loading a Registry hive--they disappear from the Registry when the user logs out.

Computer-specific policies are merged into HKLM, while user- or group-specific policies are merged into HKCU. It's important to remember that the policy settings are merged with the existing settings; they don't automatically overwrite the existing contents when the corresponding part is set to "leave as is." In addition, changes users make to policy-defined values under HKLM or HKCU are not written back to the policy! This prevents users from changing a policy setting and having the change propagate to other users. (Of course, if you're using policies, probably the first policy you'll set is the "Disable Registry editing tools" flag.)

6.1.4.1 The default policy

It's possible to assign policies to some users and computers, but not others. You might want to put restrictive policies onto machines in a shared lab area without enforcing any policies on individual users' machines, or you might want to restrict what some users can do no matter what machine they log into.

No matter what computers and accounts have policies, you can specify a default policy. This default applies to all users and computers that don't have an explicit policy defined for them. The default computer policy is applied to all computers in a domain (assuming the policy is applied to the whole domain), and the default user policy is applied to all domain users. By convention, these default policies are saved in a file named NTconfig.pol (for NT systems) or config.pol (for Windows 95 systems).

The initial default policies just set all policy parts to their "leave as is" state, meaning that the policy doesn't change anything. You may edit the default policy and save it back to its original filename; whatever changes you make are applied as defaults from that point onward.

Default policies apply to every user, including administrators! If you create a restrictive default policy, it applies to local and domain administrator accounts unless you create less-restrictive group or user accounts for your fellow admins.

6.1.4.2 Applying computer and user policies

When you create computer-specific policies, they're stored in the .POL file as groups of settings, one for each computer. To revive our earlier example, if you define policies for titan and trident, there will be keys with the same name in the policy file. When the policy downloader retrieves the policy file, it decides to apply it, or not, based on two rules. First, if there's a key in the policy file with the same name as the computer, that policy's part values are merged into HKLM. If no such key exists but there is a key named .default, that default key is applied. If neither condition is true no changes are made. A computer-specific policy always overrides the default: in fact, the default policy won't even be examined if there's a policy whose name matches the computer's.

User policies are applied using the same two rules: if there's a policy whose name matches the user who's logging in, it is applied. If not, the .default entry is used if it exists; otherwise, no changes are made.

6.1.4.3 Applying group policies

The rules that decide whether or not to apply a user or computer policy are very simple. However, the rules for applying group policies are a little more complicated. There are only two rules to know. The first, and most important, rule is this: a named user policy always trumps any group policies. For example, a policy for a user named bob overrides policies for any groups of which bob is a member.

The second rule to remember is that group policies are additive. If a user who's in more than one group logs in, the system uses the group priority to decide which policies to apply first. You set the group priority from within the System Policy Editor (as you'll see later in "Setting group policy priorities"). The lowest-priority group policy is applied first; its part settings are applied to the logged-in user's HKCU root key. The next lowest-priority group policy is evaluated next, and so on, until the highest-priority policy is applied. This approach means that if you put conflicting part values into two group policies, any user who's in both groups ends up with the part value of whichever policy is evaluated last.

Let's say you have two groups in your domain for executives and engineers. Your boss is an executive, but has an engineering degree, so you put her in both groups. If the "Don't allow users to play Solitaire" policy is set to "on" for executives and "off" for engineers, your boss's ability to play Solitaire hinges on the priority you assign to the two groups: the highest-priority setting will triumph.