Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Determine If the Group Policy Design Is Correctly Implemented

If the GPO is not applied, there may be a number of reasons why this is true. A number of Group Policy-related issues may prevent the policy from being applied. Often these reasons can be viewed by looking on the Summary tab or the Group Policy Results report created in GPMC under the computer configuration summary or user configuration summary. The possible reasons include:

Security filtering
GPOs are linked to sites, domains, and OUs. By default, the GPO will be applied to the accounts that exist within these containers. However, the permissions page of the GPO can be used to limit which accounts get the GPO. By default, the Authenticated Users group is given the Apply to permissions. This means that the GPO will be applied to every Authenticated User account in the container to which the GPO is linked. To filter GPOs, instead of using this generic Authenticated Users group, specific groups can be designated as those who can apply the policy. Any groups, and thus users, not explicitly given permission will be denied. Of course, explicit denial can also be configured. If you determine that a specific user or computer, or a group of users or computers, is not getting the policy applied while all others are, the usual answer is security filtering. Determine who should get the policy and then check the permissions page of the GPO or the Scope page of GPMC to determine if it is set up correctly. To display the Scope page, select the GPO in the GPMC console, as shown in Figure 9-7. In the figure, note that the security filter is configured to apply the GPO to users who are members of the CHICAGO\Finance group. If a user account is in the OU hierarchy for this GPO and is a member in the Finance group, the policy will be applied. The policy will not be applied to other user accounts that reside in the OU hierarchy.

Disabled GPO Link
A disabled GPO will not be applied. Look at the Links section of the Scope page of the GPMC report for the specific GPO, as shown in Figure 9-8. If you find that a valid GPO is marked as disabled, you can correct this by enabling it; however, the wise solution would be to attempt to determine why the GPO is disabled. The reason for disablement might be that some severe, unwanted effect occurs when the policy is applied. Rather than enabling the GPO, the problematic effect of the GPO should be determined and corrected first.

Inaccessible GPO
This can occur if a link to a GPO exists, but the GPO cannot be found or cannot be accessed. This might be due to insufficient permissions on the GPO or on folders in the path to the GPO template. In this case, the Component section of the Group Policy Results Summary tab of the GPO report indicates "failure" for Group Policy Infrastructure. Figure 9-9 shows the location of the Group Policy Infrastructure status. In the figure, no problems are reported. Other reasons may be network connectivity, replication, DNS, or AD processing.

Empty GPO
A GPO without settings can be configured and linked but will not be processed.

WMI filter
A WMI filter restricts GPO processing to computers and users who meet specific qualities as defined in the filter. If the filter is not correctly designed, or if something is wrong in its processing, then a policy may not be applied.

Even if the GPO is applied, the specific setting that is desired may not be. Look in the policy to see if the setting is listed. Look also at the results of one of the tools listed previously. If the setting is not listed in a results set but is in the GPO, then a change to the policy hasn't reached the client, the change is not supported by the operating system, or the change has been overridden by inheritance or the application of special Group Policy settings. The following possibilities should be checked:

Group Policy refresh
By default, the client checks for changes to its GPOs every 90 minutes and will refresh if a change has occurred. Security settings are refreshed periodically, whether or not changes have occurred. Some portions of a GPO will not be applied until a user logs on, and others such as Software Restriction policies require a reboot. If a change occurs to Folder Redirection, Roaming Profiles settings, or Software Installation settings while the user is logged on, it will not take affect until the user logs off and then logs back on again. The use of asynchronous processing can also have an impact. You can check the last time of policy refresh by checking the summary table of the Group Policy Results report under Computer Configuration Summary and User Configuration Summary. Use the secedit /refreshpolicy command on Windows 2000 systems or the gpupdate command on Windows Server 2003 and Windows XP Professional systems to force an update and reexamine the results.

Replication problems
If either AD or FRS replication is not occurring correctly, changes to the policy will not be available. See sections on troubleshooting these systems later in this chapter.

Replication latency
Normal AD and FRS replication is not instantaneous. The process by which changes replicate and all domain controllers obtain them is called replication convergence. The time it takes for complete replication is the replication latency. Replication latency will vary depending on bandwidth, number of sites, and amount of replication traffic. If the normal latency of replication of the organization is known, it can be determined whether that is the problem. Consider also that it's not just policies and their associated files that must be replicated but also changes to group membership or domain membership for users and computers. If, for example, a GPO is linked to the Accountants OU, and Jeff Smith's account has just been added to that OU, the user portion of the GPO will not apply until knowledge of his account in that OU has replicated to the domain controller at which his authentication takes place. Likewise, if security groups filter the GPO, and membership in the group has recently changed, the GPO may not be applied to the new members of the group.

Default behavior
The determination of which GPO will win when multiple policies are applied can usually be ascribed to inheritance rules. The last policy applied wins. However, some settings, such as those in the password policy, can only be set in a specific location. Only the final settings will appear in the Group Policy Results Report in the "Winning GPO column," as shown in Figure 9-10.

Operating system support
Several hundred new Group Policy settings are available in Windows Server 2003, and many of these are not supported by Windows 2000. If the setting is not supported, it cannot be applied. To determine if a setting is supported by the client operating system, download and examine the Excel file "Groups Policy Settings Reference for Windows Server 2003" from http://microsoft.com/downloads/details.aspx?FamilyID=7821c32f-da15-438d-8e48-45915cd2bc14&DisplayLang=en.

Service pack issue
Service Pack 2 for Windows XP includes a large number of new XP-related Group Policy settings. The settings are included in a new system.adm file. When a Windows XP SP2 computer is used to edit GPOs, the new adm file is added to the GPO. Each GPO that will be used to manage Windows XP computers must be updated. To use these settings for XP in a Windows Server 2003 domain, the system.adm file must be copied from the systemroot\inf\folder on the Windows XP computer, renamed, and added to the systemroot\inf folder on the Windows 2000 domain controller. The old system.adm file should then be removed from the Group Policy Object that is linked to the OU within which the XP computer accounts reside. The new .adm file can then be linked and used to apply the new XP settings. If the new .adm file is not added, then the new settings will not show up in the GPO.

GPO inheritance
Remember the rules of Group Policy inheritance. When multiple policies are applied, the last one applied wins, unless blocking or overriding has been configured. Blocking and overriding inheritance exceptions can also prevent a GPO from being applied at all. A detailed explanation of how Group Policy inheritance works was included in Chapter 7, "Active Directory's Role in Domain Security." Figure 9-11 displays the Group Policy Inheritance tab of the Chicago\Finance\ Accounting OU. The top GPO (listed as 1 in the figure) is the "winning" GPO, but all GPOs may contribute to the policy setting. A results report for a specific computer or user in this OU will display the exact settings that are applied.

Loopback processing
Loopback processing applies the User sections of a computer GPO after all other GPOs have been applied. Normally, the User sections of a GPO in the location where the user account lies will be the last GPO applied, and thus will "win." If loopback processing is used, the local computer policy is reapplied after all other normal processing. When loopback processing is in place, all normal processing rules are followed, but because the final settings that are applied are from the local computer, settings that differ may be lost. If a GPO in the accounting OU, for example, enables access to the Run button and exposes Control Panel applet access, but the local computer GPO disables them, users of this computer who have accounts in the Accounting OU will not be able to use Control Panel applets or the Run button. On a computer without loopback configured, users would be able to use control panel applets or the run button. While loopback seeks to solve the problem presented by computer labs, kiosks, and other generally publicly exposed computer systems, remember that loopback will only impact users whose accounts are in Windows 2000 or Windows Server 2003 domains. If a trust exists with a Windows NT 4.0 domain, and a Windows NT 4.0 domain user is allowed to access the computer, no loopback will occur. To check for loopback processing, directly check the Group Policy loopback settings in the administrative templates section of all GPOs that affect the computer, as shown in Chapter 7.

Client-side extension
After a GPO is downloaded, client-side extensions perform some of the processing. Examples of client-side extensions are Folder Redirection, Registry, and script processing. If the extension is missing or corrupt, processing will be incomplete.

Asynchronous processing
Group Policy processing can be synchronous or asynchronous. That is, either GPO processing is completed before a user may use the computer (synchronous), or it is not. In asynchronous processing, policies are applied as a background task during and after startup and logon. If asynchronous processing is used, a user may be able to do something that, once GPO processing is complete, he will not be able to do. By default, startup and logon processing for Windows 2000 and Windows Server 2003 is synchronous. The user will have to wait to log on until Group Policy application is complete. If the client is Windows XP, asynchronous processing during startup and logon is automatic. This means to the user, startup appears to be faster. There is another side effect to asynchronous possessing. When asynchronous processing is used, and changes are made in items such as Folder Redirection, Roaming Profiles, Script Processing, and Software Installation, the changes may not be available until the user logs off and logs on again. If the behavior is not desired, then processing should be changed. To do so, use the GPO settings Computer Configuration, Administrative Templates, System, Logon Always Wait for the Network at Computer Startup and Logon. Group Policy Refresh is asynchronous for Windows 2000, Windows XP Professional, and Windows Server 2003.

Slow network links
Some parts of Group Policy processing can be restricted when the computer is connected via a slow link. Application installation, for example, will not occur over a slow link by default, while the application of administrative templates will. A slow link is defined as 500 kilobits per second or less. You can modify the specifics of slow link connections and Group Policy in the Administrative Templates, System, Group Policy section.

GPO editing issues
If a GPO is edited at two different DCs, the last change wins. This means that the current GPO might not reflect the desired settings. To help counter this issue, it is always wise to make GPO changes at the same DC and to have designated administrators responsible for specific GPOs or GPOs on specific OUs.

True policies versus preferences
Administrative templates include both true policies and preferences. Preferences can be deployed using Group Policy but cannot be enforced as well and are not removed even when the GPO that first set them is removed. Many preferences do not take affect when set, but only after the next startup or logon. Preferences are hidden by default in the Group Policy Editor. If preferences are used, users may see their behavior as unpredictable and wrong, even though the processing of these settings, which are made directly in the registry, is working as designed. To view preferences, in the Group Policy Editor, select an Administrative Templates node, and on the View menu, click Filtering. Then clear the Only show policy settings that can be fully managed check box.

Script processing
Startup, logon, and logoff scripts can be applied using a GPO. However, the scripts merely update the registry with a script location so that normal user initialization processing knows where to look. The CSE reports success when this is accomplished, not after the script has run. The script CSE has no way of reporting errors in scripts and thus can't report that a script failed due to an error. Another possible problem is that the script processing can time out. A setting for Maximum wait time for Group Policy Scripts can be adjusted if this is the case. To find script-processing errors, look in the Application Event log for errors with a source of UserInit.

Software installation
Network connectivity issues can prevent software installation. Other problems include misspelled or non-existent shares or paths within the share, and insufficient permissions on the share. Software installation can also be used to remove software should conditions change and the user or computer be removed from the scope of the policy. This condition should be checked for. When Windows Installer packages are used for software installation, the policy can be configured to install even if the user does not have administrative privileges. If it is not used, this can be a cause of software installation failure. Windows Installer package problems can also be the cause if they are corrupt. Use the Software Installation Diagnostics tool (addiag.exe) to find the details of applications installed via AD for the current user.

Folder redirection
Only the My Documents, Application Data, Desktop, and Start Menu folders can be redirected. Problems can occur if the share and file system permissions are incorrect. The user must have ownership privileges on the redirected folder. Allow the system to create the folder, and permissions will be set correctly. The minimum permissions that are necessary are listed in Table 9-3.

NOTE: Troubleshooting Resource

A good source for additional troubleshooting information is the article "Troubleshooting Group Policy in Windows Server 2003" at http://microsoft.com/downloads/details.aspx?FamilyId=B24BF2D5-0D7A-4FC5-A14D-E91D211C21B2&displaylang=en.