The SID History (Bulk) option is used to add SID History to multiple objects which is used to support domain migrations. This function is based on the DsAddSidHistory API. This API has a list of requirements that must be in place before it can update the SID history attribute on the target objects. Details of these requirements can be found here. You must complete the validation before the file import and run options are available.
Definitions
Source Domain: this is the domain that has the source objects
Target Domain: this is the domain where the SID from the source object, will be added to the SID History attribute of the target object.
NetTools needs to be run on the domain controller in the target domain. The validation details need to be entered and then click the Validate button.
This is the output of the validation test for a successful validation. If there are any issues, the details will be displayed. The validation test doesn't check for the audit requirements but will be reported as an error when you try to execute the change. Check the Microsoft article above for details of the audit requirements.
Validating Source Domain Information Uplevel Domain Source Domain: TARGET Source DC: dc03.target.net Source domain local group exists Source Domain Validation Complete Validating Target Domain Information Uplevel Domain Target Domain: NETTOOLS Target DC: dc01.nettools.net Target Domain Validation Complete Validating Target Domain SPN Bind Bound to target DC Validation complete
Once the validation is complete, the Import file and execute buttons are enabled. The input file is a semi-colon-separated list of source and target object names. The object names need to be based on the SamAccountName. Once the file has been imported, the source and target object pairs are displayed in the import pane. When the execute button is pressed, the result of the changes are displayed in the status column.
Example input file:
testidm;testidm gary1;gary2 admin;admin
Side Note: I have completed numerous domain migrations, with and without SID history. While SID history simplifies the initial phase of the migration, it does mean you move the remediation of permissions and the removal of SID History to the end of the migration\project. Usually, this means that there is limited time or appetite to complete this work, and SID History never gets removed. This does have the side effect of increasing the size of the user's access token, and while the introduction of Windows 2012, with larger access token buffers, can reduce this impact, it can still cause intermittent authentication issues, especially with IIS. My advice is not to use SID History and complete the remediation of the permissions before migrating the users as this will ensure that you can identify and resolve issues earlier in the project timeline, removing the possibility of SID History issues waiting to bite you later.
Could you please provide an example of a source file? Validation succeeded, but nothing happened when I tried to open the file, containing coma-separated (or semi-colon-separated) source-destination pairs.
Hi Gene,
Thanks for the feedback, I’ve corrected the typo and included an example file, the file should be semi-colon separated.