Secure Access for Apps & APIs on Windows Server: Key Considerations

Table of Contents

Certain applications and Application Programming Interfaces (APIs) require specific access to the token-groups-global-and-universal (TGGAU) attribute. This attribute is a critical component found on both user and computer account objects within the Active Directory directory service. Without appropriate permissions to read this attribute, these applications and APIs may fail to function correctly, leading to service disruptions or incorrect authorization decisions.

Understanding the Token-Groups-Global-And-Universal (TGGAU) Attribute¶

The token-groups-global-and-universal (TGGAU) attribute is a dynamically computed value. It exists on security principal objects, specifically user and computer accounts, within Active Directory. This attribute enumerates all global group memberships and universal group memberships associated with the respective account. It’s important to note that domain local groups are not included in this attribute, as their scope is restricted to the local domain.

Applications leverage the TGGAU attribute to gather comprehensive group membership information for a user or computer, especially when the security principal is not interactively logged on. This information is crucial for making various authorization and access control decisions offline or remotely. For instance, a service running under a computer account might need to verify the group memberships of a user account to determine access to a resource before the user attempts a direct logon.

Many modern Win32 functions in Windows Server, such as AuthzInitializeContextFromSid and LsaLogonUser, are designed to simplify the process of reading and interpreting the TGGAU attribute. Consequently, applications utilizing these high-level APIs might unknowingly be relying on access to this specific attribute. If the security context under which such an application operates lacks the necessary read permissions for the TGGAU attribute, the application will encounter access denied errors, leading to functionality failure.

Active Directory Permission Compatibility and TGGAU Access¶

Access to the TGGAU attribute is fundamentally governed by the Permission Compatibility setting chosen during the domain creation process via DCPromo.exe. This decision profoundly impacts the default security posture of a new Active Directory domain. The default setting for new Windows Server 2003 domains is configured for stricter security, which inherently limits broad access to the TGGAU attribute.

Historically, in Microsoft Windows NT 4.0 and earlier operating systems, comprehensive group membership information was more readily available by default. This led many legacy applications to depend on this pervasive access. To maintain compatibility with these older applications, Windows 2000 and Windows Server 2003 introduced the Pre-Windows 2000 Compatible Access group. When a domain is configured for this compatibility mode, read access to the TGGAU attribute is granted to a broader set of users, including the Everyone group, through membership in Pre-Windows 2000 Compatible Access.

Impact of DCPromo Permission Compatibility Choices¶

The DCPromo.exe utility plays a pivotal role in defining the initial security landscape of an Active Directory domain. When a new domain is created, administrators are presented with critical choices regarding permission compatibility, which directly influences access to attributes like TGGAU. Understanding these options is paramount for balancing security and application compatibility.

The two primary permission compatibility options presented during DCPromo are:

1. Permissions compatible with pre-Windows 2000 servers (or “Permissions compatible with pre-Windows 2000 server operating systems” on Windows Server 2003): Selecting this option results in the Everyone group being added to the Pre-Windows 2000 Compatible Access group. This grants the Everyone group read access to the TGGAU attribute, along with many other domain objects. While this ensures compatibility for older applications, it significantly broadens the attack surface and is generally not recommended for new, secure environments.
2. Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems: This is the default and recommended setting for new Windows Server 2003 domains. Under this configuration, the Pre-Windows 2000 Compatibility Access group only includes the Authenticated Users built-in security identifier. This drastically limits read access to the TGGAU attribute on objects. Applications requiring this attribute will be denied access unless the specific account running the application has explicit permissions, such as belonging to the Domain Admins group or the specialized Windows Authorization Access Group.

The choice made during domain creation has long-term implications for managing application permissions. Organizations must carefully weigh the need for backward compatibility against modern security best practices. Opting for the stricter compatibility mode by default minimizes unnecessary broad access, aligning with the principle of least privilege.

The Windows Authorization Access (WAA) Group¶

To streamline the process of granting necessary read access to the TGGAU attribute without resorting to the broad permissions of Pre-Windows 2000 Compatible Access, Windows Server 2003 introduced a dedicated security group: the Windows Authorization Access (WAA) group. This group is specifically designed to manage permissions for applications and services that require access to authorization-related attributes, including TGGAU.

On new installations of Windows Server 2003 domains configured with the stricter permission compatibility, the WAA group is automatically granted read access to the TGGAU attribute on user objects and computer objects. This provides a more granular and secure method for delegating this specific permission. Administrators can simply add the service accounts or user accounts under which critical applications run to the WAA group, thereby granting them the necessary TGGAU read permissions without compromising overall domain security.

Managing TGGAU Access in Different Domain Environments¶

The approach to enabling TGGAU access varies significantly depending on the Active Directory domain’s operating system version and its permission compatibility mode. Understanding these nuances is crucial for proper configuration and troubleshooting.

Windows 2000 Domains¶

In Windows 2000 domains, the Windows Authorization Access group does not exist. Therefore, managing TGGAU access requires a different strategy:

• Pre-Windows 2000 Compatibility Mode: If the Windows 2000 domain is operating in Pre-Windows 2000 Compatible Access mode, the Everyone group inherently has read access to the TGGAU attribute on user and computer account objects. In this scenario, most applications and functions will have the required access without further configuration.
• Non-Compatibility Mode: If the domain is not in Pre-Windows 2000 Compatible Access mode, a more targeted approach is needed. It is recommended to create a custom domain local group specifically for this purpose. Administrators should then add the user or computer accounts that require TGGAU access to this newly created group. Subsequently, explicit read permissions for the tokenGroupsGlobalAndUniversal attribute must be granted to this custom group on user objects, computer objects, and iNetOrgPerson objects within Active Directory. This granular approach adheres to the principle of least privilege, even in older domain environments.

Mixed Mode Domains and Upgraded Domains¶

When a Windows Server 2003 domain controller is introduced into an existing Windows 2000 domain (creating a mixed-mode environment) or when a Windows 2000 domain is upgraded to Windows Server 2003, the initial permission compatibility selection is preserved.

• Pre-Windows 2000 Compatibility Mode: If the original Windows 2000 domain was in Pre-Windows 2000 Compatible Access mode, this configuration will persist. Consequently, the Everyone group will remain a member of Pre-Windows 2000 Compatible Access, ensuring continued broad access to the TGGAU attribute. Applications will generally function as expected.
• Non-Compatibility Mode: For mixed-mode or upgraded domains that were not in Pre-Windows 2000 Compatible Access mode, the Windows Authorization Access (WAA) group becomes available. This group is automatically created when a Windows Server 2003 domain controller is promoted and holds the Flexible Single Master Operations (FSMO) Schema Master role. However, it’s crucial to note that the WAA group is not automatically granted access to the TGGAU attribute in these upgrade scenarios. Administrators must manually grant the WAA group explicit read permissions to the TGGAU attribute on relevant objects. Once permissions are granted, accounts requiring TGGAU access can be added to the WAA group.

New Windows Server 2003 Domains¶

New Windows Server 2003 domains offer the most straightforward configuration for TGGAU access, especially when following best practices:

• Pre-Windows 2000 Compatibility Mode: Similar to other domain types, if a new Windows Server 2003 domain is deliberately configured in Pre-Windows 2000 Compatible Access mode during DCPromo, the Everyone group will have read access to the TGGAU attribute. This setting is typically chosen only when absolute backward compatibility with legacy applications is a non-negotiable requirement.
• Default (Stricter) Compatibility Mode: When a new Windows Server 2003 domain is created with the default setting (Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems), the WAA group is automatically created and, crucially, is pre-configured with read access to the TGGAU attribute on user and computer objects. This streamlines secure access delegation significantly. To enable an application to read TGGAU, simply add the application’s service account or the user account it runs under to the WAA group. This is the recommended and most secure method for managing TGGAU access in new Windows Server 2003 environments.

Summary of TGGAU Access Scenarios¶

To provide a clearer overview, here’s a summary of TGGAU access management based on domain type and compatibility mode:

Domain Type	Permission Compatibility Mode	TGGAU Access Mechanism
Windows 2000	Pre-Windows 2000 Compatible Access	Everyone group has read access (via Pre-Windows 2000 Compatible Access group). Applications generally have access.
	Windows 2000 Only (Stricter)	Create custom domain local group, add accounts, and manually grant read permissions to tokenGroupsGlobalAndUniversal attribute on user/computer/iNetOrgPerson objects for that group. WAA group does not exist.
Mixed Mode / Upgraded	Pre-Windows 2000 Compatible Access	Everyone group has read access (retains original settings). WAA group exists (if W2K3 DC added) but is not automatically granted TGGAU access.
	Windows 2000/2003 Only (Stricter)	WAA group exists (created upon W2K3 DC FSMO role). Manually grant WAA group read permissions to tokenGroupsGlobalAndUniversal on user/computer objects. Add requiring accounts to WAA group.
New Windows Server 2003	Pre-Windows 2000 Compatible Access	Everyone group has read access (via Pre-Windows 2000 Compatible Access group). WAA group exists but isn’t strictly needed for TGGAU in this mode.
	Windows 2000/2003 Only (Default/Stricter)	WAA group exists and is automatically granted read access to tokenGroupsGlobalAndUniversal on user/computer objects. Add requiring accounts to WAA group. Recommended secure practice.

Security Implications and Best Practices¶

Granting access to the TGGAU attribute should always be done with careful consideration of the principle of least privilege. While necessary for some applications, overly broad access can expose sensitive group membership information to unauthorized entities. This information could potentially be leveraged in reconnaissance phases of an attack.

• Avoid “Pre-Windows 2000 Compatible Access” for New Domains: For new Windows Server 2003 deployments, always select the stricter permission compatibility option during DCPromo. This sets a secure baseline.
• Utilize the WAA Group: In environments where the Windows Authorization Access group is available and properly configured, leverage it to grant targeted access to the TGGAU attribute. This is significantly more secure than adding accounts to the Pre-Windows 2000 Compatible Access group or directly modifying ACLs for individual attributes unless absolutely necessary.
• Document Permissions: Maintain thorough documentation of which applications and service accounts require TGGAU access, and why. This aids in auditing and troubleshooting.
• Monitor Access: Implement monitoring for unauthorized attempts to read the TGGAU attribute, which could indicate a security concern.
• Regular Auditing: Periodically audit the membership of security groups that have access to TGGAU (e.g., WAA, Pre-Windows 2000 Compatible Access, or custom groups) to ensure only authorized entities retain this privilege.

Further Considerations for Application Developers¶

Application developers should be aware of the security context under which their applications will run and design them to gracefully handle access denied errors when attempting to read the TGGAU attribute. Instead of assuming universal access, applications should explicitly request the necessary permissions or provide clear error messages and guidance to administrators if access is denied. This fosters a more secure and manageable deployment experience.

For applications that truly need comprehensive group information, direct querying of TGGAU might be efficient. However, developers should also consider alternative mechanisms provided by the operating system for checking user permissions and group memberships, which might abstract away the need for direct TGGAU access, thus relying on the underlying system’s authorization capabilities.

Conclusion¶

Securing access to critical Active Directory attributes like token-groups-global-and-universal is a fundamental aspect of maintaining a robust and secure Windows Server environment. While legacy compatibility considerations exist, modern deployments and best practices emphasize granular control through mechanisms like the Windows Authorization Access group. By carefully configuring permission compatibility and strategically delegating access, organizations can ensure application functionality while upholding strong security principles.

We invite your comments and insights on how you manage TGGAU access in your Active Directory environments. Share your experiences, challenges, and best practices below!