In Microsoft Windows NT 4.0 and mixed-mode domains, local groups are only effective when you log on to the computer that hosts the local group. Local groups that are defined on a domain controller (DC) are replicated to all DCs in the domain, and are therefore effective when you log on to all DCs.
When you log on to a domain, the authenticating DC returns a logon token that contains global group security identifiers (SIDs) for which the user is a member, and local groups on the DCs are specifically excluded. The local computer's Local Security Authority (LSA) then checks each SID in the logon token and adds any relevant local group SIDs.
In native mode, Windows 2000 extends the functionality of local groups that are defined on DCs. Membership in domain local groups will be indicated in the logon token that is returned by the DC, provided the user is logging on to a computer in the same domain. If the user is logging on to a computer in another domain, the domain local group's SIDs are not included.
Because of this, in native mode domain local groups can be used to secure resources in the same domain. When a user logs on to a workstation in another domain, and attempts to access a resource in his or her home domain, the NT LAN Manager (NTLM) or Kerberos authentication mechanism ensures that appropriate domain local groups are again included in access checks for the relevant resource.
However, this does not extend to group policy as the client-side engine obtains a list of applicable group policy objects (GPO) through Active Directory searches in the system context, then access checks each GPO's Access Control List (ACL) against the user's token. If the user is not logged into his or her own domain, the token will not contain domain local group membership, and any filtering of group policy by domain local groups will not work as expected.
Therefore, if users are expected to log on to computers in other domains in the forest, GPOs should not be filtered by domain local groups.