SID History Migration to Retain ACL Rights in Active Directory
Admins who have an Active Directory migration lined up often have many questions in mind. Out of them one that has a significant impact after an AD transfer is how to go about SID history migration. Being a core component of object-level security special care needs to be taken while dealing with Security Identity (SID). As SID can exist without object but object can’t exist without SID.
Moreover, after a domain change admins may witness that users, computers, groups, and other objects start behaving abruptly.
Even while discussing the formation of an AD Migration checklist special emphasis is given to SID.
Whether you wish to maintain or revoke resource access, SID is the key. So, this write-up will help you follow through with your requirements. Let’s start by discussing what exactly a SID is.
Understanding SID and Script to Find SID History
Short for Security Identifier SID can be thought of as a Social Security number for the objects inside AD. These are unique non-physical strings that are kept entirely digital. Likewise, SID History is a sub-attribute containing the list of all previous SIDs that a particular object had in its previous domain.
To list the current SID and SID History of all AD objects admins can use the following PowerShell script:
# Function to discover unique object types
function Get-UniqueADObjectTypes {
param (
[string]$Filter = '*'
)
# Hash table to store encountered object types
$objectTypes = @{}
# Get AD objects based on filter
$objects = Get-ADObject -Filter $Filter -Properties ObjectClass
# Process each object and update hash table
foreach ($object in $objects) {
$objectType = $object.ObjectClass
if (!$objectTypes.ContainsKey($objectType)) {
$objectTypes.Add($objectType, $true)
}
}
# Return the list of unique object types
return $objectTypes.Keys
}
# Get a list of unique object types (call the function)
$uniqueTypes = Get-UniqueADObjectTypes -Filter "Name -like '*'"
# Loop through unique object types and retrieve objects
$allObjects = @()
foreach ($objectType in $uniqueTypes) {
# Construct the Get-AD* cmdlet dynamically
$cmdlet = "Get-AD" + $objectType
try {
# Attempt to retrieve objects using the constructed cmdlet
$objects = & $cmdlet -Filter "*" -Properties Name, SID, SIDHistory # You can adjust properties as needed
$allObjects += $objects # Add retrieved objects to the main array
} catch {
#Write-Warning "Error retrieving objects of type: $objectType. Exception: $_"
}
}
Clear-Host
# Display retrieved objects (optional)
if ($allObjects) {
Write-Host "Retrieved Objects:"
# Use calculated property syntax directly in Format-Table header
$allObjects | Format-Table @{Name="ObjectClass"; Expression={$_.GetType().Name.Replace("Microsoft.ActiveDirectory.Management.AD", "")}}, Name, SID, SIDHistory -AutoSize
} else {
Write-Host "No objects retrieved."
}
Output:
SID Architecture:
Source: Microsoft
A typical SID looks like this:
S-R-X-Y1-Y2-Yn-1-Yn
eg.
S-1-5-21-10036348-17238915-1-512
Each part of the SID has a specific meaning:
S: Indicates an SID.
R (Here 1): Revision level.
X (Here 5): Identifier authority.
Y1-Y2-YN (Here 21-10036348-17238915-1): Unique domain-specific identifier.
512: Relative identifier (RID) for the object within the domain.
History and Usage of SID History
SID saw its first use with the release of Windows Server 2000. Initially, it was made to perform a clean exit from Windows NT 4.0 and go to the Active Directory. However, after that, it became a regular part of all AD environments. This meant that admins could allow an object from its new domain to access the resources it was connected to previously.
SID itself is immutable no matter what modifications happen to the object. This means the SID of the user remains as it is even if their name changes or they receive a privilege upgrade to admin status.
But this also brings in a vulnerability. If a user name is removed then all the reference calls to that particular object mention it as “Account Unkown (SID)”.
Moreover, as the SID is technically free it may get attached to another object unknowingly. Exploitation of this vulnerability that common to many Active Directory attacks. Where hackers successfully link an orphan SID with high-level permission access to their sleeper account. After which they can manipulate the AD as per their wish. So whenever an object is part of a cross forest Active Directory Migration admins must opt for a solution that does not allow the SID to become unattached.
However, many admins have expressed difficulties in maintaining SID history intact during a default migration. Don’t worry we have accumulated a list of such errors so you don’t have to face them in your actual environment.
Check ADMT SID History Not Working Issue Manually
Password migration issues with ADMT are not the only problem that admins have to deal with. Keeping SID history is challenging if admins opt for the traditional migration approach. Due to errors like:
Error Code 6: Invalid Handle
“The handle is invalid (Error code = 6).”
This error is an indication of an underlying Remote Procedure Call (RPC). Here the the Primary DC inside ADMT fails to link with the RPC endpoint. It can occur due to the following reasons.
- If TcpipClientSupport doesn’t launch on the primary DC or its emulator.
- Either one or both the Primary DC and its emulator fail to restart after TcpipClientSupport configuration.
- In case the DNS or the NetBIOS name resolution fails.
Error: Unverified Auditing/TcpipClientSupport
Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate Sid’s. The specified local group does not exist.
It indicates a preexistence of global/universal group {SourceNetBIOSDom}$$$ name. ADMT is responsible for the local group creation. However, this can’t be done if the name is already taken up by some other security principal.
Error: Unverified Auditing and TcpipClientSupport Access Denial
“Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate Sid’s. Access is Denied.”
It occurs when the user account attempts to run the ADMT with insufficient permissions. This can occur in the source, target, or both.
Error: Domain Name Lookup Failure
To find these errors scan the Migration.log file. Most likely scenario is that source domain still maintains some trust configuration not existing inside the target.
Fix it by re-running the trust migration wizard and replicating the source side trusts.
No admin wants to deal with unnecessary troubleshooting in between a migration. Use the ADMT alternative to save countless hours that would have otherwise been wasted on fixing avoidable problems.
Skip All SID History Migration Errors Professionally
If you are thinking about leaving SID history at the source think again. If you continue with this selection it means that no Access Control List (ACL) will work. All of them rely on the SID history to confirm resource allocation.
Therefore we suggest that you instead rely on the SysTools Active Directory Migration tool for all AD transfers as it maintains SID history automatically.
With its advanced set of algorithms and user-friendly design is your best bet for a fully functioning AD post-migration.
You won’t have to struggle with PowerShell Scripts or postpone the migration as all data along with ACL requests move together to the new domain. To see how the tool can keep the history of security identity intact take a look at its working steps.
Procedure to Migrate SID History with an Automated Tool
Step 1. Launch the tool and allow the default (administrator) credentials to fill on their own. Then press the Login button.
Step 2. Press the “REGISTER DOMAIN CONTROLLER” Type the Domain Friendly name and IP address of the source domain.
Step 3. In the Domain Details Page enter the Admin details and press “Save and Continue”.
Step 4. Change the tab from Info to Active Directory and fetch the source objects.
Step 5. Close the Domain Details screen > Add the Target domain and Fetch the objects for the same.
Step 6. In the Migration screen click on “Create Migration Scenario”. Put the registered domains in the source and target then press Save & Continue.
Step 7. Go to the Task tab, and press the “Create Task” button. Select the objects and Press “Save and Continue”.
Step 8. After object selection choose the Create or Merge option to move your objects, The current SID will move into the SID history and a New SID will be allotted to the object.
Step 9. Preview the object list, map it, and press Start Task. When the dialog box appears hit Start and let the tool work its magic.
Conclusion
In this write-up, we gave users a sure-shot solution for keeping SID Migration history whenever admins migrate users and computers from one forest to another. Without it objects lose the ability to use resources that they had in their source domain. Given that the default migration requires countless troubleshooting hours to get the SID history up and running we suggest that you go with the replacement that we gave.
