How to restore credentials using SID or SIDHistory?

Mountain Pond 1,101 Reputation points


the essence of the question is that there is a copy of the domain. All objects were copied by the script. Of course, these are new objects in an identical but different domain.

Those. there is domain A and domain B, with the same name (actually it is AD AWS - domain A and On-prem standby domain B). The script copied user groups, group memberships, and so on. Those users and groups were created in domain B.
Now, after migrating a terminal server or file server, as expected, there is no access to resources. Because User and group SIDs are different in domain B than in domain A.

Knowing that during ADMT migration, the SID History is used to work around this issue. I wondered if this could be used to solve the problem. I turned out to be extremely difficult to add data to the sidHistory attribute. Because domain administrator access denied changing it.

I really don't want to write a script that will reassign permissions. Perhaps someone knows a way to restore the permissions?

Thank you.

Windows Server 2019
Windows Server 2019
A Microsoft server operating system that supports enterprise-level management updated to data storage.
3,453 questions
Active Directory
Active Directory
A set of directory-based technologies included in Windows Server.
5,843 questions
Windows Server PowerShell
Windows Server PowerShell
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.PowerShell: A family of Microsoft task automation and configuration management frameworks consisting of a command-line shell and associated scripting language.
5,362 questions
0 comments No comments
{count} votes

Accepted answer
  1. Gary Reynolds 9,391 Reputation points

    Hi @Mountain Pond

    I've responded to your other question on relating to sidhistory permissions.

    When migrating resources between domains or forests sidhistory should be viewed as a temporary mechanism to simplify the migration and not the solution. Using Sidhistory to access migrated resources, provides a buffer to complete the re-permission of the resources based on the new target domain users and groups and then it should be removed.

    At some point you will need to complete the re-permissioning of the resources to include the new target SIDs, the question you need to answer, do you use sidHistory and re-permission later, or don't use sidhistory and re-permission resources in the source domain before they are moved to the target domain.

    I have completed numerous domain migrations and I have only used Sidhistory once on the first one and never again. Sidhistory works but it hides issues with resource access and you only find these issues once sidhistory is removed, which is normally at the end and in a big bang fashion but it doesn't get removed due to timeline or risk appetite and so its just left in place. I can't remember how many domains I've seen where sidhistory still exists for migration were completed years ago.


1 additional answer

Sort by: Most helpful
  1. Mountain Pond 1,101 Reputation points

    Looks like I found what I need. This module works fine, in fact it edits the database offline.

    Maybe it will be useful for someone :)

    PS C:\> Stop-Service -Name ntds -Force  
    PS C:\> Add-ADDBSidHistory -SamAccountName John `  
                               -SidHistory 'S-1-5-21-3623811102-3361044346-30300840-512',  
                                           'S-1-5-21-3623811102-3361044346-30300840-519' `  
                               -DatabasePath C:\Windows\NTDS\ntds.dit  
    PS C:\> Start-Service -Name ntds  
    0 comments No comments