Whenever organizations have to move their Active Directory, one of the major questions in the minds of all admins is how to go about SID history migration. As SID history is directly tied to the security of objects like users, computers, and groups, this can’t be taken lightly.
Moreover, as cross-forest migrations become more common, so does the need for SID history maintenance. That’s why we prepared this article to help admins in their migration. Before we get to the issue resolution let’s see the structure of an SID. Also the importance of keeping it unchanged.
What is SID and Why Maintain them During Migration?
SID stands for secure identity, a unique combination of alphanumeric characters to indicate a particular within an AD. SID became a part of Windows Server in 2000 and has since expanded its role as the sole means of identity management. Within a domain, SID looks like the following,
S-1-5-21-1004336348-1177238915-682003330-512
With each part separated using a hyphen “-”. All SIDs begin with the letter “S” followed by the revision level, then identifier authority (from 0- 5), after that, we have the domain identifier, terminating with the relative identifier.
The reasons to copy SID history during an AD migration can be many. Some of them are discussed below:
Migration is a complicated subject, so administrators often try to maintain backward compatibility to roll back the changes if anything goes wrong. Therefore, if the SID of objects changes, the source AD domain can’t verify them and has no other option but to reject the objects due to security concerns. Then it is a long procedure to sync the objects back and reattempt the migration again.
Also Read: Follow Active Directory Migration Checklist and Mitigate Migration Challenges
Access to legacy systems is only possible if the SID requests are genuine. Moreover, any changes in SID make them unrecognizable to the legacy systems. Combined with the fact that legacy systems can’t be migrated to the new environment, access to them may be completely revoked. This is a huge blow to organizations that rely heavily on such workloads. So it is better to keep the SID the same when we migrate SID to new domain.
AD is also a part of industries with strict compliance requirements. So any changes in the SID might not be allowed and lead to legal trouble down the line. Therefore, it is smart to stay on the safer side and avoid changes in the SID altogether.
Manual Methods to Troubleshoot SID History Migration Issues
Here we are going to cover some of the major error codes that users encounter during inter-forest SID change.
'The handle is invalid (Error code = 6).'
This error signifies an RPC issue where ADMT cannot establish a connection with an RPC endpoint on the source primary domain controller. Potential reasons consist of the following:
- Unable to launch the TcpipClientSupport either on the source primary domain controller or primary domain controller emulator.
- One or both source primary DC and primary DC emulators are not restarting after TcpipClientSupport setup.
- Name resolution failure in DNS or NetBIOS systems.
'Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate SIDs. The specified local group does not exist.'
This error commonly indicates the existence of a user, global, or universal group with the name {SourceNetBIOSDom}$$$. ADMT typically creates a local group with this name, but it cannot do so if a security principal with the same name already exists.
Also Read: Guide to Copy OU Structure from One Domain to Another in Active Directory
'Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate SIDs. Access is Denied.'
This error typically points to insufficient permissions for the user account running ADMT to perform the migration in one or both of the domains.
‘Domain name lookup failed, rc=1332. No mapping between account names and security IDs was done.’
This error, found in the Migration.log file after migration with SID history, often suggests that the source domain has trusts configured that does not exist in the target domain. To resolve this, execute the Trust Migration Wizard to map the trusts in the source domain and replicate them.
Conclusion
With this article, users now have the tools to perform SID history migration without issues. Moreover, we have also provided guidelines to mitigate the problems that pop up in a SID after an AD domain change. A simple way with which users can make sure that their SID history remains intact is through the application of a professional tool provided above.