Some applications and APIs require access to authorization information on account objects (331951)

MORE INFORMATION

The token-groups-global-and-universal (TGGAU) attribute is a dynamically computed value on computer account objects and on user account objects in Active Directory. This attribute enumerates the global group memberships and the universal group memberships for the corresponding user account or computer account. Applications can use the group information that is provided by the TGGAU attribute to make various decisions about a specific user when the user is not logged on.

For example, an application can use this information to determine whether a user has been granted access to a resource that the application controls access for. Applications that require this information can read the TGGAU attribute directly by using either Lightweight Directory Access Protocol interfaces or Active Directory Services Interfaces. However, Microsoft Windows Server 2003 introduced several functions (including the AuthzInitializeContextFromSid function and the LsaLogonUser function) that simplify reading and interpretation of the TGGAU attribute. Therefore, applications that use these functions may unknowingly be reading the TGGAU attribute.

For applications to be able to directly read this attribute or indirectly read this attribute (through the use of an API), the security context that the application runs in must have been granted read access to the TGGAU object on the user objects and on the computer objects. You do not expect applications to assume that they have access to TGGAU. Therefore, you can expect applications to be unsuccessful when access is denied. In this situation, you (the user) may receive an error message or a log entry that explains that access was denied while trying to read this information, and that provides instructions about how to obtain access (as described later in this article).

Several existing applications depend on the information that is provided by TGGAU because the information is available by default in Microsoft Windows NT 4.0 and in earlier operating systems. Therefore, on Microsoft Windows 2000 and Windows Server 2003 operating systems, read access to the TGGAU attribute is granted to the Pre-Windows 2000 Compatible Access group.

For domains that use existing applications, you can handle these applications by adding the security contexts that those applications run as to the Pre-Windows 2000 Compatible Access group. Alternatively, you can select the "Permissions compatible with pre-Windows 2000 servers" option during the DCPromo process when you create a domain. (On Windows Server 2003, this option is worded as follows: "Permissions compatible with pre-Windows 2000 server operating systems".) This selection adds the Everyone group to the Pre-Windows 2000 Compatible Access group, and thereby grants the Everyone group read access to the TGGAU attribute and to many other domain objects.

For more information about the pre-Windows 2000 Compatibility Access group, click the following article number to view the article in the Microsoft Knowledge Base:

257988 Description of Dcpromo permissions choices

When a new Windows Server 2003 domain is created, the default access compatibility selection is "Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems." This default option results in the Pre-Windows 2000 Compatibility Access group being empty, and read access to the TGGAU attribute on objects is limited. In this case, applications that require access to the TGGAU group are not successful if they are not running as a Domain Administrator or as a similarly empowered account.

Enabling Applications to Read the TGGAU Attribute

To simplify the process of granting read access on the token-groups-global-and-universal (TGGAU) attribute to users who must read the attribute, Windows Server 2003 introduces the Windows Authorization Access (WAA) group.

On new installations of Windows Server 2003 domains, the WAA group is granted access to the read TGGAU attribute on user objects and on group objects.

Windows 2000 Domains

If the domain is in pre-Windows 2000 compatibility access mode, the Everyone group has read access to the TGGAU attribute on user account objects and on computer account objects. In this mode, applications and functions have access to TGGAU.

If the domain is not in pre-Windows 2000 compatibility access mode, you may have to enable certain applications to read the TGGAU. Because the Windows Authorization Access Group does not exist on Windows 2000, it is recommended that you create a domain local group for this purpose, and that you add the user or computer account that requires access to the TGGAU attribute to that group. This group would have to be given access to the tokenGroupsGlobalAndUniversal attribute on user objects, on computer objects, and on iNetOrgPerson objects.

For more information about how to do this by using a sample script, click the following article number to view the article in the Microsoft Knowledge Base:

331947 How to programmatically apply access permissions for Windows Server 2003 built-in groups in the Active Directory directory service

Mixed Mode Domains and Upgraded Domains

When a Windows Server 2003 domain controller is added to a Windows 2000 domain, the access compatibility selection that was previously selected is not changed. Therefore, mixed mode domains and domains that were upgraded to Windows Server 2003 that were in pre-Windows 2000 compatibility access mode continue to have the Everyone group in the Pre-Windows 2000 Compatibility Access group. Additionally, the Everyone group still has access to the TGGAU attribute. In this mode, applications and functions have access to TGGAU.

If the mixed mode domain is not in pre-Windows 2000 compatibility access mode, you can grant permissions by means of the WAA group:

The WAA group is automatically created when a Windows Server 2003 domain controller is promoted to the Floating Single Master Operations Server.
The WAA group is not automatically granted access to the TGGAU attribute on mixed-mode domains and on upgraded domains.

For more information about a script that demonstrates how to apply these permissions, click the following article number to view the article in the Microsoft Knowledge Base: