Issue:
When a user logs into a computer that is a member of a trusted domain the domain group enumeration does not properly list all domain local groups the user is a member of. This can affect logon scripts that rely on domain local group membership to perform actions.
Example:
User1 is a member of Domain1
Domain1 and Domain2 have a two-way transitive trust between the domains
Workstation1 is a member of Domain1
Workstation2 is a member of Domain2
Running GPResult.exe on the separate workstations displays different results. Items in Bold indicate differences.
Domain1\User1 logs into Domain1\Workstation1
Group Enumeration is as follows
Domain Users
Everyone
BUILTIN\Administrators
BUILTIN\Users
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
GGroup1 (Domain1 Global group)
DLGroup1 (Domain1 Domain Local group)
UGroup1 (Domain1 Universal group)
UGroup2 (Domain2 Universal group)
Domain1\User1 logs into Domain2\Workstation2
Group Enumeration is as follows
Domain Users
Everyone
BUILTIN\Administrators
BUILTIN\Users
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
GGroup1 (Domain1 Global group)
DLGroup2 (Domain2 Domain Local group)
UGroup1 (Domain1 Universal group)
UGroup2 (Domain2 Universal group)
Notice how only the Domain Local Groups for the workstation domain (not the user domain) are enumerated.
Basic Group Membership Rules
Global Groups can only contain objects from the same domain.
Domain Local and Universal Groups can contain objects from the local domain or any trusted domain.
Cause:
The TOKEN_GROUPS structure contains information about the group security identifiers (SIDs) in an access token. This access token is generated every time the user logs onto a domain, and it should contain information about all groups the user is a member of in their local domain. However, the workstation Domain SID is used as the local domain when enumerating Domain Local groups. This is a BUG, and the user’s Domain SID should be used instead. See the More Information section below for a detailed explanation of how this process should work.
Workaround:
To workaround this problem, convert all Domain Local groups that are referenced in logon scripts to Universal Groups. This will allow them to be enumerated during logon, which will allow the logon script to complete as desired.
More Information:
In a Windows 2000 domain that is operating in native mode, if a domain user logs in who is a member of a Domain Local Security Group, the token that is generated for the logged on user has Domain Local Security Group in TOKEN_GROUPS.
See also:
Microsoft KB Article Q259392: http://support.microsoft.com/kb/259392/EN-US/
Microsoft Active Directory SDK section “How Security Groups are used in Access Control”
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/how_security_groups_are_used_in_access_control.asp
Applies to:
Windows 2000 Native Mode Domain
Windows 2003 Native Mode Domain