Once you’ve created policy files that contain the access controls you want to enforce, you still have to get those policies to each machine you want to be under policy control. This process, called policy distribution, is probably the most complex part of the policy development process, since how you do it depends on whether you want to use policies on one machine, a few machines, or many machines.
The simplest way to apply policies is to put them on individual machines. For example, you might want to apply policies to keep transient users from making changes to the configuration of public workstations in a library, factory floor, or conference room. For this type of requirement, you don’t need to blast policies to every machine on a network; a more surgical approach lets you put policies only where you really need them.
POLEDIT allows you to edit the local computer’s Registry using the same interface you’d use to edit policies. When you use the File→Open Registry command, POLEDIT acts as if you’d opened a new policy file, but it actually loads data from the local Registry and displays it as two user policies: “Local User” and “Local Computer” instead of “Default User” and “Default Computer.”
You can edit the contents of these policies as though you were editing any other policy. However, you can’t create new user, group, or computer policies while the local Registry is open. As with other policy files, though, changes you make to the local Registry aren’t saved until you explicitly use the File→Save command, so using File→Open Registry is somewhat safer than using RegEdt32 or RegEdit.
If you want to apply policies to a single remote machine, you can use POLEDIT’s File→Connect... command to open the Registry on a remote machine and set policies on it. When you use this command, the first step is to specify the name of the machine whose policies you want to edit. If you have administrative access to that machine, POLEDIT connects to its Registry and shows you a dialog listing all users who are logged on. Normally, this list has only a single entry representing whoever’s logged into the console, but network users may be listed too. Choose the user whose policy you want to edit. POLEDIT won’t let you interactively edit the policy of a user who isn’t logged on.
Once you’ve completed these two steps, you may edit the computer and user policies as you normally would. You can’t create new user, group, or computer policies; however, before you use File→Connect..., you can attach new policy templates if you want to change the default settings that can be applied within each policy.
Policies offer a robust, useful way to apply settings to many machines, in such a way that the end user can’t change them once they’re applied. This is a boon to system administrators, since with effective policies you can prevent users from changing things you don’t want them to change without a great deal of effort on your part.
The primary method of distributing policies to all machines within a domain depends on the fact that domain controllers have a share named NETLOGON. It points to the domain controller’s %SystemRoot%System32ReplImportScripts directory and contains logon scripts, user profiles, and other data needed to allow local and remote logons with shared environments. NETLOGON can also hold policy files, meaning that the policy downloader on each machine in the domain has easy access to those policy files if they are saved in the NETLOGON share.
Tip
On a Windows 2000 domain controller, the SYSVOL share serves the same function as NETLOGON, so you use it instead.
If you want machines on your network to automatically download policy changes when they happen, you’ll have to make a change to the policy for those machines. For most networks, that means the Default Computer policy, since most admins want automatic updates everywhere; however, you may enable automatic updates on a per-machine basis.
This setting lives in the Network category under the computer policy. Figure 6-6 shows the properties dialog with the appropriate setting selected. You can use the “Update mode” combo box to choose automatic or manual updates. If you choose manual updates, you can specify a UNC path to the share where your policies will live.
It’s important to understand one thing about automatic updates: when you create a new policy file for the first time, it’s downloaded automatically to every machine. If automatic updating is then turned on, each machine receives subsequent updates. If it’s not turned on, the workstations’ policy downloaders won’t ever download policy changes. This may lead to undesirable behavior, since your policy changes will be silently ignored while you’re expecting them to be in effect!
To have your NT-specific policies automatically blasted out to all machines in your domain, save your policy file as NTconfig.pol in the directory you specified when setting up automatic policy updates. I recommend using the NETLOGON or SYSVOL shares to store your policies so they can be automatically replicated among and between domains. However, if you’ve specified another directory you can use it instead.
If you have a mixed network of Win9x and NT machines, you can store both types of policies on your domain controllers so that the Win9x machines get automatic updates too. Save your policy file as config.pol in the directory you specified when setting up automatic policy updates. If you want Win9x policies to be distributed automatically, you must put them in NETLOGON; the Win9x policy downloader can’t get policies from any other share.
Windows 2000 machines won’t pay any attention to an NT-style system policy. If you want to apply a policy to a Windows 2000 server or to a machine using Windows 2000 Professional, you can use the GPO mechanisms to do so if the target machine’s in an Active Directory domain. If not, you can use the Local System Policy object to make local policy settings.
If your network has more than one Windows NT domain controller[35] (either because you have more than one domain or because you have more than one controller for redundancy), you should use NT’s directory replication service to copy your policy files to every domain controller. Since any domain controller in a network can answer logon requests, it’s a good idea to duplicate your policy files to make sure they’re available when a user logs in.
The simplest way to do this is to copy the policy files into the controller’s %SystemRoot%System32ReplExportScripts directory. As long as the directory replication service is running, NT mirrors the files automatically throughout your domains.
While policies can be a great help, they can also pose some subtle pitfalls until you get them working the way you want. Here are some common problems--and solutions--you may run into while deploying policies on your network.
Perhaps the easiest policy mistake to make is putting the policy files in the wrong place. Windows 9x policy files must be named config.pol, and they must be stored in the domain’s NETLOGON share--period! For NT policies, you must name the file NTconfig.pol. Ahough you can put it in a share other than NETLOGON, the policy isn’t used unless you specify the correct path to it when you turn on automatic updates.
Policies are most useful when they’re always kept up to date. The policy downloader can automatically download and apply the appropriate set of user, group, and computer policies whenever a user logs on. To accomplish this magic, though, you have to put the policy in the right place (as described in Applying Policies to Many Machines), and you must turn on automatic downloading. If your policy changes don’t seem to take effect once you’ve made them, be sure you’ve enabled automatic updates as part of the computer policy for all machines you want to keep updated.
If you’re going to implement policies in one domain on your network, you may be in for a rough ride unless you implement policies on all domains. Why? If you have trust relationships between domains so that users from one domain can log onto another, consider this scenario:
You have two domains: HQ and RESEARCH. They trust each other. You’ve enabled system policies for all HQ users, but not for users in RESEARCH.
A user from HQ logs into a machine in the RESEARCH domain. Because RESEARCH gets its logon credential information from HQ, the user’s logon causes the RESEARCH machine to get a system policy update even though policies aren’t enabled in the domain! The HQ user can still log in and get her work done.
When the HQ user logs out, the computer, group, and user policies downloaded at logon time are still on the machine. The next time a RESEARCH user logs onto the same machine, the policies won’t be changed because RESEARCH has no policies of its own to apply.
In case it’s not obvious by now, the solution to this potentially ugly problem is to implement policies on all your domains or none of them. It’s still okay to apply policies to individual users and computers; however, if you set up group policies or policies for users who can log in to other domains, your best bet for avoiding trouble is to enable policies for all domains.
Sometimes your memory can fail you when it comes time to remember which groups a user is in. If you use group policies, make sure all users you want to fall under those policies are actually members of the group! If there are any who aren’t, you can copy the group policy and make an individual user policy out of it, or you can add them to the group.
Don’t forget to double-check your group names, too. If you meant ENGINEERING but typed ENGINEERS, POLEDIT won’t complain, but your policies won’t be activated either. Worse still, they might be activated on the wrong group.
If you want to see what policy is actually being applied to a user or computer, use the File→Connect... command in POLEDIT to connect to the target computer. Once you do, you can open the Local Computer and Local User policies to make sure they contain the settings you want enforced. If they don’t, that’s a clue that your policy distribution or downloading is amiss.
[35] Even small networks should have primary and backup controllers for NT 4.0; in Windows 2000, there’s no longer a distinction between primary and backup controllers, but you should still maintain a second controller for redundancy. You may also find it worthwhile to have several DCs for load balancing.