Hi, 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.

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. Gary.

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 :) https://github.com/MichaelGrafnetter/DSInternals https://github.com/MichaelGrafnetter/DSInternals/blob/master/Documentation/PowerShell/Add-ADDBSidHistory.md 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

How to restore credentials using SID or SIDHistory?

Accepted answer

Gary Reynolds 9,406 Reputation points

2022-08-19T02:50:16.1+00:00

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.

Gary.
Please sign in to rate this answer.
Mountain Pond 1,431 Reputation points

2022-08-19T09:49:33.04+00:00

Thank you!

Frankly, this is not a migration. It's more of a DR solution. In the event that the AWS service becomes unavailable, we need to deploy a temporary working infrastructure. As soon as the primary resource returns to normal, the resources on the standby site will be removed.

If sidHistory works, that will be great.
I confess only a few times I came across migration between domains using sidHistory, it works in trusted domains. I'm not sure if this will work if there is no trusted domain, but there is a server and resources from domain A in domain B in which users have sidHistory set.

Gary Reynolds 9,406 Reputation points

2022-08-19T09:59:37.407+00:00

If it's to provide a DR capability for AWS AD in the event that AWS is off line, would the simpler solution to have Domain Controller located on-premise to cover this scenario, then you don't need to move restores between domains?

Gary.

Mountain Pond 1,431 Reputation points

2022-08-19T10:11:03.46+00:00

Unfortunately, AWS AD does not allow you to add on-premis controllers. Only migrate from on-premis to AWS AD. They have replication technology between sites and adding controllers in another site.

In addition, the administrator in AWS AD is just a user with full rights to the OU. He cannot build trust relationships, change the scheme, sites, etc. Only manage objects in dedicated OUs.

This is such a difficult path.
Script written, it synchronizes directories and all object changes. I warned the customer about the authority, but only after a while the issue became urgent)
In addition, domain names that are the same in domain A and domain B are exactly the same FQDN.

I would be very grateful for any help in this matter.

Gary Reynolds 9,406 Reputation points

2022-08-19T10:48:18.783+00:00

Are you able to provide a bit more information:

What risk are you trying to mitigate?

What infrastructure do you have in AWS?

Do you have both on-premise and AWS servers joined to the domain?

How many users?

Do users have workstations joined to the domain, is it just VDI access?

Mountain Pond 1,431 Reputation points

2022-08-19T10:49:18.473+00:00

It looks like the idea with sidHistory can be forgotten. I don't have a trust relationship. All exports and imports go through json files. You can connect between domains, but they have the same name and domain A is AWS with all the restrictions.

Mountain Pond 1,431 Reputation points

2022-08-19T10:59:19.4+00:00

Are you able to provide a bit more information:

What risk are you trying to mitigate?

There is a direct order from the customer. If AWS in one of the regions is not available. We need to quickly deploy infrastructure in another region.
The primary region uses AWS AD. In the backup, a domain controller is deployed, with the same forest. And servers are replicated between regions.
As soon as the main region becomes unavailable, the servers in the backup will be turned on.

What infrastructure do you have in AWS?

I unfortunately do not know everything, I know there are virtual machines, terminal servers (farm), SQL, applications, web servers or web applications.
File server.

Do you have both on-premise and AWS servers joined to the domain?

On-premis is separated from AWS AD. AWS does not allow you to use their AD to the full extent as classic AD. From this and such difficulties.
If it was classic AD or Azure AD, this problem would not exist.

The domains have the same forest, the same domain, but they are completely separated and not carp with each other (not the best scenario).
Objects are synchronized export from AWS->json files->import On-prem

How many users?

Not much, up to 200 users, up to 100 groups.

Do users have workstations joined to the domain, is it just VDI access?

Yes, there are also terminal servers.

Gary Reynolds 9,406 Reputation points

2022-08-19T11:43:14.677+00:00

If the initial risk is the availability of AWS AD and possible loss of a region, one option would be extend the AWS AD across regions, so AD will be available and then work on making the other services HA and region aware with data replicated across regions. Probably with a small footprint, and CD/CI pipelines defined that could spin up additional resources to provide capability as required.

Sorry probably a different approach that you were looking for, but I'm not sure the DR AD option will be a workable option with the limitation of AWS AD. However, I would suggest you have a look at Quest Migration Manager, as it doesn't use the standard Windows API\Functions and might be able to implement the SIDHistory. But this might also have it's own limitation as some functionality does require the installation of an agent on the DC which wouldn't be an option with AWS AD.

Gary.

Mountain Pond 1,431 Reputation points

2022-08-22T01:38:58.967+00:00

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 :)
https://github.com/MichaelGrafnetter/DSInternals
https://github.com/MichaelGrafnetter/DSInternals/blob/master/Documentation/PowerShell/Add-ADDBSidHistory.md

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
Sign in to comment

Share via

How to restore credentials using SID or SIDHistory?

1 additional answer