SID History Bulk

SIDHistoryBulk

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 need to successfully complete a validation of the details before the file import and run options are enabled.

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.

Sid History Bulk

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 a 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-comma 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 objects pairs are displayed in the import pane.  When the execute button is pressed, the result of the changes are displayed in the status column.

Side Note:  I have completed numerous domain migrations, with and without SID history and while SID history does make the initial phase of the migration simpler, 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 limited time or appetite to complete this work, and as a result 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, which can reduced this impact, it can still cause intermittent authentication issues, especially with IIS.  My advise 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, which then removes the possibility of SID History issues waiting to bite you later.

Leave a Reply

Your email address will not be published. Required fields are marked *