The Sysadmins

Tips and tricks from the Sysadmins

ADMT Series – 3. SID History

In the first post we setup the trust and prepared Active directory for the migration. One of the last messages provided when creating the trust states:

To improve the security of this external trust, security identifier (SID) filtering is enabled. However, if users have been migrated to the trusted domain and their SID histories have been preserved, you may choose to turn off this feature.

What is SID History

SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you migrate users into the target domain you will have the option to migrate the users SID to the target domain. This becomes the sIDHistory attribute under the new user object.

Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.

SID history can be used for roaming user profile access, certification authority access, software installation access and resource access.

To visualise this I’ve created a user called Ronnie Coleman in the source domain and run dsquery to display the user’s SID.

dsquery * -filter "&(objectcategory=user)(samaccountname=ronnie.coleman)" -attr objectsid

Here is Ronnie Coleman’s SID in the Source Domain:

If we use ADMT to migrate Ronnie Coleman to the target domain and migrate his SID from the source domain you will see both the new SID, and the sIDHistory from the source domain.

The actual process of migrating the sIDHistory will be shown in the Migrating Users part of the series, this post is simply to explain what SID History is and why you would use it in your migration.

In Action

On DC1.source.local (source domain) I have shared a folder called Ronnie Coleman, on which only Ronnie.Coleman@source.local can access. I’ve then migrated Ronnie.Coleman@source.local to the target.local (target) domain and migrated the SID (as above).

Ronnie.Coleman@target.local has logged onto the (target domain) and attempted to access the file share with SID Filtering still enabled, as you can see- access is denied:

After SID filtering has been disabled (and Ronnie has logged off and back on) he is granted access, despite his user account not being directly in the NTFS permissions. SID History has allowed Ronnie.Coleman@target.local access to the resource.

How to Disable SID Filtering

If you choose to utilise SID history you will need to disable SID filtering. Run Netdom as a domain or enterprise administrator from the target domain.

External trust: Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd

In our test bed, source.local (source) is trusting target.local making it the trusting domain.

If you are using a Forest trust, the command is slightly different:

Forest trust: netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes /usero:domainadministratorAcct /passwordo:domainadminpwd

Security Concerns

Disabling SID filtering requires a level of trust between the two forests, and ultimately those who are responsible for Active Directory. With SID Filtering disabled, a rogue domain administrator could clone a SID from the other domain and add it to their SID History, granting them unauthorized rights.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard – Local Profiles
ADMT Series – 11. Computer Migration Wizard


  1. Fan of Ronnie Coleman, eh? A great bodybuilder.

  2. Great article! Though it is in the screenshot, you left out the /passwordo:* parameter in your text. Using /passwordo:* will make it prompt for the password of the source domain account specified by /usero:.

  3. One thing to keep in mind is sid history still doesn’t work if the user is granted access through a global security group. If the user is getting access through a global security group that group must be migrated before the sid history link will work.

  4. Thew me there, as the second command for checking the sIDHistory was not written down and I had copied the first example.

    dsquery * -filter “&(objectcategory=user)(samaccountname=ronnie.coleman)” -attr objectsid sIDHistory

    Thanks anyway, you assisted me.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.