Fix ERROR_DS_LOCAL_CANT_HAVE_CROSSDOMAIN_LOCAL_MEMBER

When This Error Shows Up

You're working on a member server or a domain-joined workstation, and you try to add a security group from another domain into a local group (like Administrators or Remote Desktop Users). For example, you're on a file server in domain A and you try to add DOMAIN_B\HelpDesk_Admins (which is a domain local group in domain B) to the local Administrators group. Windows kicks back error 0X00002148 and tells you: "A local group cannot have another cross domain local group as a member."

I've seen this most often in multi-domain forests where admins try to get fancy with group nesting. The trigger is always the same — trying to nest a domain local group from a different domain into a local group. The error doesn't discriminate between workstations and member servers. It fires every time.

Why It Happens

Active Directory has three group scopes: universal, global, and domain local. Microsoft's rules around allowed nesting are strict:

Domain local groups can contain global groups, universal groups, and user accounts from any domain in the forest.
Domain local groups cannot contain other domain local groups from a different domain.
On member servers and workstations, the local SAM groups (like Administrators) are essentially domain local groups in behavior — they play by the same rules.

So when you try to put a domain local group from another domain into a local group, you're violating rule #2. The culprit here is almost always a misunderstanding of group scope. Someone created the source group as domain local when it should have been global or universal.

How to Fix It

Check the source group scope.
Open Active Directory Users and Computers (ADUC) on a domain controller in the source domain. Find the group you're trying to add. Right-click it → Properties → General tab. Look at "Group scope." If it says Domain Local, that's your problem.
Change the group scope (if possible).
Right-click the group → Properties → General tab → change scope to Universal or Global.
Warning: You can't change a domain local group to global or universal if it contains other domain local groups. If that's the case, remove those members first. Universal works best for cross-domain nesting — it's designed for this.
Click OK. Wait for replication (or force it with repadmin /syncall).
If you can't change the scope, replace the group.
Let's say the source group has 50 users and you can't touch it. Create a new universal or global group in the source domain. Add the 50 users to it. Then add that new group to your local group on the target server.
Clear cached credentials (sometimes necessary).
On the target server, run this in an elevated command prompt to flush stale group memberships:
```
klist purge
```
Then log off and back on. The new group membership should take effect.
Test the fix.
Add the corrected group to the local group. If you get no error, you're golden. Verify with:
```
net localgroup Administrators
```
(Replace Administrators with your local group name.)

What to Check If It Still Fails

If the error persists after changing the group scope, you're likely dealing with replication lag. Run repadmin /showrepl on both domain controllers to see if changes have synced. Force replication with repadmin /syncall /AdeP if needed.

Another gotcha: nested domain local groups within the same domain work fine. If both groups are domain locals in the same domain, the error shouldn't appear. Double-check you're not making a cross-domain mistake.

Finally, if you're dealing with a resource domain in a legacy forest (pre-2003 functional level), upgrade to at least Windows Server 2012 R2 functional level. Old functional levels have stricter nesting rules. A quick Get-ADForest | fl ForestMode in PowerShell tells you what you're working with.

Bottom line: don't try to mash domain local groups across domains. Use universal groups for cross-domain membership. It's the cleanest workaround and avoids this error entirely.