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 [email protected] can access. I’ve then migrated [email protected] to the target.local (target) domain and migrated the SID (as above).
[email protected] has logged onto the AD1.target.local (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 [email protected] 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.
