SIDCloner.dll
When you look in WWW to find a way to write sidHistory attribute, you probably will stop at the marvelous SID Cloner website created by Jiri Formacek, MSFT (http://code.msdn.microsoft.com/windowsdesktop/SIDCloner-add-sIDHistory-831ae24b). Jiri provides a managed class library that implements the SIDCloner class, which we can use in Powershell and any .NET programming code.
The SID Cloner class is built upon native API to migrate sidHistory and therefore uses the DsAddSidHistory function under the hood (http://msdn.microsoft.com/en-us/library/windows/desktop/ms675918(v=vs.85).aspx).
Although we do not need to install ADMT on any machine to run the SID Cloner code, we still have to consider to meet the same requirements for the migration setup as ADMT does. SID Cloner and ADMT come from the same “mothership” DsAddSidHistory.
SidHistory requirements
In brief we need the following prerequisites to be in place before we can start writing sidHistory (http://msdn.microsoft.com/en-us/library/windows/desktop/ms677982(v=vs.85).aspx):
+ a trust relationship must exist between source and target domain
+ source and target domain must not be in the same Active Directory forest
+ for source domain all actions will have the PDC Emulator as target; you cannot bind to another DC than the one with the PDC Emulator role
+ Auditing must be enabled in source domain
+ a domain-local group “domain$$$” must be created in source domain
+ a special registry key must be created on PDC Emulator DC in source domain: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\TcpipClientSupport
+ Audit Mode must be turned on in each domain and also Account Management auditing of Success/Failure events must turned to on.
+ the Security Identifier we want to transfer must not already exist in any sidHstory attributes of objects in target domain
Permissions:
For running Powershell code based on SID Cloner you do not necessarily need domain admin credentials in target domain. While read permissions on objects in source domain are sufficient (you are reading the “standard” attribute objectSID there), the permissions to modify the object in target domain by writing the sidHistory value requires more:
+ full access permissions to the object (better OU)
+ special permission “migrateSIDHistory” on the Active Directory domain object in target domain
With all the requirements settled, you are able to migrate sidHistory by using the sample script, that Jiri published on the SID Cloner Website.
However, the most easy way to use the 4 fold overload with SIDCloner did never work in our tests.
Overload with 4 arguments means, you simply define source and target domain, source account from which you want to take the objectSID and target account where you want to write sidHistory.
This approach will probably never succeed because
a) the strict PDC Emulator access is not guaranteed when using a domain call
b) the credentials of the interactively logged user are obviously not passed to the DsAddSidHistory function inside the SID Cloner dll
Let’s have more findings around this Topics in Part 3 of this blog post.
Cloudy Migration Life 
Any chance you have part 3 of this series being published anytime soon? We are attempting to do exactly what you are describing in your scenario and have not yet found a solution.
Hi Eric,
I am currently pretty busy with a large scale Active Directory Migration Project. Will probably not publishing more before end of January.
However, I will not provide “ready-to-Use” PS scripts here since writing sidHistory is a security sensitive field.
But I will give more hints how we did it with good success.
If you have a business critical inquiry, you also can get in contact with Feedback[at]ssc365.de. We can create customized PS scripts and GUI based Tools.
Thanks
Robert
Hello Robert
Thanks for this interesting article!
Did you manage to release part 3 of this blog-series?
I wonder how you’ve got to made things work with the overload of the C++ Functions.
Did you pass the value which you are getting from the [system.directoryservices.activedirectory.domain] class?
Thanks for any answers!
Kind regards
Charly
Very good stuff. I have been writing up a rebuttal to how we can prevent sidHistory from being migrated outside of ADMT and QMM or other COTS products by unauthorized persons or admins, and it appears, as I have exhaustedly searched the internet, that you are limited to the DsAddSIDHistory API, which has all the above requirements, and works great after you figure it out 🙂
(if there are other APIs out there that do this, please please, post. I’m still unaware of any, and it would be a shame if there were, kind of would negate the whole security posture of AD)
(we are a QMM environment)
The customers and entity I work for would prefer no leaks, or unauthorized data access due to something like this, but we are migrating 20k users to a new forest and during the process they would like to be able to reach back to legacy data seamlessly. So QMM brings sidHistory over, yay.
Both sides of the migration efforts security teams are concerned about unauth sid cloning, and from what I have discovered and tested, you can monitor the hell out of the logs, capture the related events that are a indicative of a sid history migration outside of QMM and get alerts that it has happened, with source and target user account. And you can take action.
Since it’s mandatory by STIG that all auditing be turned on, we just can’t turn it off to prevent access. We have too many domain admins, and pruning that is taking time.
So,
You create your sourcedomain$$$ group and deny write access to everyone. and with that done, you get a big ol’ access denied. And if the source domain administrators limit access to that group, over deny to it, or what ever, they have the control to prevent that API from running. Just thought I would share if anyone else was trying to come up with ways to prevent this.
Test : Deny access to source DOMAIN$$$ group
Test attributes:
Source SVC Account: svc.src.sidclone / Domain Admins
Target SVC Account: svc.tgt.sidclone / Domain Admins
Source Group TTSHMF$$$: CREATED / ALL DENY Modify
Auditing Source Domain: As Below
Account Management
User Account Management Success and Failure
Computer Account Management Success and Failure
Security Group Management Success and Failure
Distribution Group Management Success and Failure
Application Group Management Success and Failure
Other Account Management Events Success and Failure
Auditing Target Domain: As Below
Account Management
User Account Management Success and Failure
Computer Account Management Success and Failure
Security Group Management Success and Failure
Distribution Group Management Success and Failure
Application Group Management Success and Failure
Other Account Management Events Success and Failure
Test results:
WARNING: Account ttshmf.test.local\user218shmf failed to clone
Error:Exception calling “CloneSid” with “10” argument(s): “Access is denied”
WARNING: Account ttshmf.test.local\user118shmf failed to clone
Error:Exception calling “CloneSid” with “10” argument(s): “Access is denied”
But of course the security of any PC is only as good as the lock on the door.