When users and groups are migrated using the Active Directory Migration Tool (ADMT) or using Quest Migration Manager, there is an option to copy the SID’s of the objects in the source domain to the target domain. The reason for this is to allow migrated users to access resources which are still located in the source domain, and hence are secured with SID’s of the source domain.

By default a trust doesn’t allows users to access resources by using SID’s from their SID history. This is security feature. When creating a trust the following message is shown:


SIDhistory can be temporarily enabled until all resources are migrated from the source domain. SID history should be enabled on the outgoing trust of the trusting domain. The following example will explain the roles of the domains in the commands:

  • Source domain
    • contains the user & group objects before migration
    • contains the resources to be accessible during the migration
    • is called the “trusting” domain
  • Target domain
    • contains the user & group objects after they are migrated
    • is called the “trusted” domain

Which command to use depends on the type of the trust:

  • External trust: netdom trust trustingDomain /domain:trustedDomain /quarantine:no
  • Forest trust: netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes

It might seem contradictory that one command requires yes and the other no, but in fact these both enable the use of SIDhistory across the trust. If you want to determine the current state, simply execute the command without the “:no” or “:yes” behind them. An example:


Depending from which side of the trust you launch this command, you might have to specify additional credentials, you can specify (optional) credentials for both the trusting and the trusted domain. The commandline options for netdom trust are explained at TechNet.

Today I received “access is denied” both at trying to enable SIDhistory or simply trying to determine the current setting.


The reason? “Network access: Allow anonymous SID/Name translation” has to be enabled on the domain controllers. This settings can be found in the domain controllers GPO’s (either the default or your custom ones) at “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options”. On a Windows 2003 domain this is not disabled by default, but in my Windows 2008 R2 target domain, the Microsoft Enterprise Client security model is implemented and this disables the anonymous SID/Name translation. if you want additional information about this setting, check KB823659

I think it might actually be necessary to enable this when configuring or reading the current setting concerning the SIDhistory. I don’t think this has to be enabled for SIDhistory to actually work. If it does, I’ll post an update in the following weeks.

My source: http://portal.sivarajan.com/2009/06/sid-filtering-access-is-denied.html

In the end all is fine: