Fix 0XC00002AF: Cross Domain Move Failed Error

Quick Answer

Delete the security descriptor inheritance on the source object, then retry the move. If that doesn't work, check SID history and domain trust SID filtering.

Why This Happens

I ran into this last month moving 200 users from a legacy 2008 domain to a new 2022 domain. The 0XC00002AF error means Active Directory couldn't update the object's security descriptor during the move. Happens when the source object has inherited permissions that don't translate cleanly, or when SID history is blocked.

Most common triggers:

SID history exists on the source object and is being filtered out by the destination domain's trust
Security descriptor on the source object has ACEs that reference SIDs the destination domain doesn't recognize
You're using ADMT (Active Directory Migration Tool) and the SID filtering quarantine isn't disabled

Fix Steps

Check SID history on the source object — Use Active Directory Users and Computers or PowerShell:
```
Get-ADUser -Identity username -Properties SIDHistory | Select-Object SIDHistory
```
If SID history exists and you're crossing trusts, the destination domain might reject the move if SID filtering is enabled.
Disable SID filtering on the destination domain trust — Only do this temporarily. On the destination domain controller, run:
```
netdom trust sourceDomain.com /domain:destinationDomain.com /quarantine:No /add
```
Then retry the move. Had a client where this alone fixed it for 90% of users.
Strip inherited permissions from the source object — Open ADSI Edit, locate the object, right-click Properties, go to Security tab, click Advanced, hit Disable inheritance, choose Convert inherited permissions into explicit permissions. Apply, then attempt the move again.
Manually remove bad ACEs — After disabling inheritance, review the ACL. Look for entries referencing SIDs from the old domain. Delete them. Save, then retry.
Use ADMT with /SIDHistoryEnabled — If using ADMT, run:
```
admt.exe /SourceDomain:source /TargetDomain:target /MoveUser /User:username /SIDHistoryEnabled
```
This adds SID history to the destination object, preventing the rejection.

Alternative Fixes

If the main fix fails, try these:

Check event logs — Look in Security and Directory Service logs on the destination DC for more specific error details. I've seen cases where a stale group membership referenced a deleted object.
Recreate the object manually — Export the source object's attributes with CSVDE, delete it, create a new one in the destination domain, then import. Not ideal but works when the security descriptor is too corrupted.
Update schema — If the source domain has a newer schema than the destination, update the destination schema via adprep /forestprep and adprep /domainprep. This is rare but hit me once with a 2016 to 2019 move.

Prevention Tips

Never move objects with inherited permissions across domains. Always convert to explicit first. And always test with a single user before bulk operations.

Also, keep your domain functional levels in sync—don't try moving objects from a 2012 domain to a 2022 domain without updating schema first. And if you're doing frequent cross-domain moves, set up a staging OU with explicit-only ACLs to avoid cleanup hell later.