The "Effective Permissions" tab may report incorrect permissions in Windows Server 2003

When you use the Effective Permissions tab to determine the permissions that a user has for a certain resource in the domain on a Windows Server 2003-based computer, the results that are displayed in the user interface are inconsistent with the actual permissions of the user for that resource. Specifically, check boxes for some Allow permissions may appear unchecked. Or, check boxes for some Deny permissions may appear checked.

This problem occurs when one of the following conditions is true:

• You run the administrative tools remotely from the resource server.
• The user account that you use to run the administrative tools is not in the same domain as the resource.

For example, consider the following scenario:

• You have a global group in domain A.
• You have a domain local group in domain B.
• A resource is located in domain B.
• The local group has full access to the resource. This access includes Delete permissions.
• The global group is a member of the local group. However, the global group does not have direct access to the resource.
• You view the resource permissions of a user in the global group by using an administrative user account in domain A. You take this action remotely from a computer that has joined domain A.

In this scenario, you see that the user does not have Delete permissions for the resource. However, the user actually does have Delete permissions for the resource.

If you are running the Active Directory administrative tools on a member of one domain and you connect the administrative tools to a domain controller in another domain, you may also see incorrect effective permissions results.

Note Because different effective permissions results are displayed when objects are accessed through a global catalog server that is running in another domain, Microsoft discourages securing objects in Active Directory by using domain local groups.

The properties dialog box uses the Authorization Manager Runtime (AuthZ.dll) engine. This engine uses a Kerberos Service for User (Kerberos S4U) transaction to obtain a token of the user. However, this token is not relative to the resource server. Instead, this token is relative to the administrative station or to the user who executes the management tool. Therefore, one of the following scenarios occurs:

• If the resource is in a different domain than the administrative station or than the administrative user, the token does not include the domain local groups of the computer that hosts the resource.
• If the resource has permissions that are assigned to built-in groups, the built-in groups are confused with the domain groups.

In either scenario, incorrect effective permissions results are displayed.

To avoid this problem, make sure that you take the following actions when you check a user's effective permissions for a resource:

• Always check effective permissions locally on a computer that hosts the resource.
• If your configuration enables Kerberos S4U, make sure that the administrative user and the resource are in the same domain.
• If you check the effective permissions for an Active Directory object, you should run the administrative tools on a domain controller that has a full copy of the object on a global catalog server.
• If you check the effective permissions for a clustered resource, you can run the administrative tools from any cluster node.

Additionally, the hotfix that is described later in this section introduces a UseGroupRecursion registry entry that lets you force the group recursion method.

To use the hotfix

You should apply this hotfix to the computer on which you want to run the administrative tools.

To have us set the UseGroupRecursion registry entry for you, go to the "Fix it for me" section. If you would rather set the UseGroupRecursion registry entry yourself, go to the "Let me fix it myself" section.

Fix it for me

To set the UseGroupRecursion registry entry automatically, click the Fix this problem link. Then, click Run in the File Download dialog box and follow the steps in the wizard.



Note this wizard may be in English only; however, the automatic fix also works for other language versions of Windows.

Note If you are not on the computer that has the problem, you can save the automatic fix to a flash drive or to a CD, and then you can run it on the computer that has the problem.

Now go to the "Did this fix the problem?" section.

Let me fix it myself

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: To use the UseGroupRecursion registry entry, follow these steps:

1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Authz
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type UseGroupRecursion, and then press ENTER.
5. Right-click UseGroupRecursion, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Exit Registry Editor.

Note By default, when the value in the Value data box is set to 0, the Authorization Manager Runtime engine uses the Kerberos method. When this value is set to 1, the Authorization Manager Runtime engine uses the recursive method.

Now go to the "Did this fix the problem?" section.

Did this fix the problem?

After you use the registry entry to change the group recursion method, you must take the following actions:

• Always check effective permissions locally on a computer that hosts the resource.
• Make sure that the administrative user has read access to the user account for which you are checking the effective permissions.

Note The administrative user and the resource do not have to be in the same domain.

Check whether the problem is fixed. If the problem is fixed, you are finished with this article. If the problem is not fixed, you can contact support.

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site: Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

You must have Windows Server 2003 Service Pack 1 or Windows Server 2003 Service Pack 2 installed to apply this hotfix. For more information about Windows Server 2003 service packs, click the following article number to view the article in the Microsoft Knowledge Base:

Restart requirement

You must restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace any other hotfixes.

File information

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.

Windows Server 2003 with Service Pack 1, x86-based versions

Windows Server 2003 with Service Pack 2, x86-based versions

Windows Server 2003 with Service Pack 1, Itanium-based versions

Windows Server 2003 with Service Pack 2, Itanium-based versions

Windows Server 2003 with Service Pack 1, x64-based versions

Windows Server 2003 with Service Pack 2, x64-based versions

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base: For another specific symptom of this problem, click the following article number to view the article in the Microsoft Knowledge Base: