As I discussed in a previous column, the way you configure Windows 2000 is very different from the way you configure Windows NT. In general, you no longer directly touch a system’s settings in Win2K. Instead, you modify one or more Group Policy Objects (GPOs) in Active Directory (AD) and cumulatively apply those settings to the system when it boots.
If you’ve worked with computers for as long as I have, you know that no matter how good a system claims to be, deferred or queued updates can fail—this scenario is definitely true in Win2K if the OS fails to apply a security-related setting in Group Policy. More often though, improperly configured systems result from human errors that occur while navigating Group Policy's many confusing options. When a system boots, Win2K traverses the organizational unit (OU) hierarchy from the root of the domain to the OU where the computer’s account object resides and applies any GPOs that you've linked to each OU. During this process, different GPOs can override a given setting multiple times according to many Group Policy options, including priority, inheritance, inheritance blocking, override flags, and even GPO permissions. You can easily produce a reasonable structure of GPOs and end up with unexpected results. Regardless of whether the cause is a Group Policy processing error or administrator mistakes, improper use of Group Policy can result in serious weaknesses in your systems. So how do you know when Win2K is applying your Group Policy settings as you intended? How do you find out what a given system’s configuration really is? You can find the answers to these questions by looking at the actual configuration settings and troubleshooting problems with the effective policy setting.
Determining Your System's Actual Configuration
Although you might have a good idea of what a system’s security configuration should be from your knowledge of the GPOs that are relevant to that system, wouldn’t it be nice to be able to see your system’s actual configuration? To see the actual settings, go to the Start menu, click Administrative Tools\Open Local Security Policy, and maneuver to Audit Policy under Local Policies, as Screen 1 shows. Compare this screen to the Audit Policy section of a typical GPO in AD, as Screen 2 shows. Whereas the Audit Policy section in Screen 2 has just one column of settings, the Local Security Policy has two. The first column, Local Setting, shows the setting in the local system’s GPO. Each computer has a local GPO, but it is the least influential of all the GPOs that the system applies. More important is the second column, Effective Setting, which shows you the setting that the system is currently enforcing. The Effective Setting is the final value that Win2K arrives at after
having evaluated all the relevant GPOs that define a value for this setting. If this
setting doesn’t match what you expect, a problem exists somewhere between your GPOs
in AD and this particular computer. To help troubleshoot the problem of why a computer's
Effective Setting doesn't match what you expect, you can examine three possible causes.
Latency. First, a latency period might affect the system's ability to process Group Policy changes. So, if you recently made changes to Group Policy, Win2K might still be in the process of applying those changes. By default, a Win2K system applies Group Policy changes whenever a system boots and approximately every 90 minutes thereafter. Domain controllers, which refresh Group Policy every 5 minutes, are the exception. You can force an immediate refresh of security settings in Group Policy by typing
Secedit /refreshpolicy machine_policy
at the command line. This command is useful when you want to confirm that a setting is taking effect simply because of latency or to immediately test the effect of a Group Policy change.
Processing errors. A second reason your system might not be getting the Group Policy settings you expect involves Group Policy processing errors. To apply Group Policy changes, several services in the domain must be functioning properly. For instance, the Group Policy engine needs AD to determine which GPOs Win2K should apply. The Group Policy engine also requires DNS services to be available on the network to find Group Policy files, and file sharing must be functional on the domain controllers so that the Group Policy engine can access the template files. If any of these services aren’t available, Win2K won't apply your security policy.
To determine whether a system is successfully applying a Group Policy change, you need to examine that system’s local Application Event Log (AEL) for messages from two event sources, Userenv and SceCli. Userenv is the engine that applies Group Policy changes in general. Win2K uses SceCli (security configuration editor client) to apply the security settings portion of a GPO. Look for errors from either of these event sources to determine whether Win2K is having trouble applying the Group Policy changes. Unfortunately, the errors you might find are pretty cryptic, but you can follow a few tips. First, search Microsoft’s Knowledge Base under the Windows 2000 category using the event source (SceCli or Userenv) and the event number as keywords. Second, many Group Policy error events include a decimal or hex error number within the description. This number is usually the Win32 error code that the OS provided to the Group Policy engine. You can decipher these codes at Microsoft's Web site to help identify the problem. For instance, if you translate the error code (53) in Screen 3, you find that it means ERROR_BAD_NETPATH — "The network path was not found." In this case, the problem was with the system’s network client settings, which weren't configured with the IP address of the DNS server. Alternatively, if you find event ID 1704 from SceCli (security policy in the GPO is applied successfully), this confirms that security policy is indeed making it from AD to your system.
Improper Group Policy option use. The third reason you might get unexpected results is simply improper usage of Group Policy options. Group Policy has rich functionality that gives you great flexibility and lets you create a complex web of policies. This third problem is by far the hardest to address because few diagnostics tools exist. A great value-added product would be one that queries AD and graphically depicts Group Policy flow for that domain. Unfortunately, such a utility does not exist. However, I'll show you how to diagnose Group Policy using what tools Microsoft does provide. By following a few easy steps, you can ensure that you have configured your systems with the security policy you intended.
First, when adjusting your security policy, carefully determine which GPO in the OU hierarchy you want to use to make the change. After making the change, use Local Security Policy to check one or more of the systems where the policy should have taken effect. If the system hasn't updated the effective setting, go to the command prompt and type
Secedit /refreshpolicy machine_policy
Wait for a few moments to give the system time to apply the Group Policy changes, then check the AEL for Userenv or SceCli errors and diagnose them. After the system has successfully applied the policy, you will see event ID 1704 in the AEL. Check the Local Security Policy again to determine whether the system has updated the effective settings as you expected. To refresh the display, right-click Security Settings in the tree pane of Local Security Policy and select Reload. If Win2K still has not updated the policy as you expected, you need to investigate all the GPOs from the root of the domain down to your local system to determine where your policy is configured incorrectly.
It is important to understand how Group Policy's many processing options interact with each other. In future articles, I’ll show you how Group Policy priority, inheritance, inheritance blocking, override flags, and GPO permissions affect how Win2K applies GPOs and how to limit complexity through judicious use of these options.
