| Previous | Next |
| ERROR_DS_UNIVERSAL_CANT_HAVE_LOCAL_MEMBER | ERROR_DS_LOCAL_CANT_HAVE_CROSSDOMAIN_LOCAL_MEMBER |
ERROR_DS_GLOBAL_CANT_HAVE_CROSSDOMAIN_MEMBER
Global-group members must originate in the group’s domain
Global groups are domain-scoped membership collections even though a security-enabled global group can be granted permissions elsewhere. Their user and global-group members must belong to the same domain as the group. A principal from another domain must instead be collected through a universal or domain-local design, depending on where permissions are assigned.
Compare the domain SID prefix of the group and candidate member, not only their DNS names. During migrations, stale distinguished names, SID history, or foreign-security-principal objects can make the apparent origin unclear. Choose a universal group for forest-wide identity aggregation or a domain-local group in the resource domain for permission assignment. Do not duplicate the account in the local domain merely to satisfy nesting; that creates a separate security principal.
What to inspect
- Compare objectSid domain prefixes.
- Identify whether the member is a foreign security principal.
- Select universal or domain-local scope for cross-domain membership.
References
- MS-ADTS: global-group membership domain
- Microsoft: cross-domain group membership rules
- Microsoft: source and destination security principals
Looking for a different code? Search another status or error code.