Why does ADMT v3.2 require administrator credentials in the source domain?

Question

The ADMT v 3.2 migration guide states that a domain administrator credential is required in the SOURCE domain when migrating user accounts. Although it specifies this requirement regardless of whether sidHistory is desired, we have found that anadministrator credential is not required in cases where sidHistory is not desired. However, for an upcoming migration project we do wish to use sidHistory and have a team of people who will be dedicated to that task. We want to delegate appropriate permissions in the SOURCE domain to that team.

We have adopted a principal of least-privilege in our organization, and therefore will not grant excessive privileges to anyone for this project.

Why is an administrator credential required to read audit policy and registry entry from a SOURCE domain controller, and a sid value from an object in the SOURCE domain?

Is the current version of ADMT unsuitable for our scenario?

Thank you for your time.
DaveC

Answer 1

Hello,

Thank you so much for posting here.

The administrator credential is not required if SIDHistory is not migrated. While it will be required if we migrate the SIDHistory.

The basic requirements for inter-forest migration operations are:

Wizard-based basic user and group account migration without sIDHistory

The source domain must trust the target domain.
The user account that is running ADMTv2 must have Administrator rights in the source domain.
The ADMT user account must have delegated permissions to create user or group objects in the target container.
DNS (hostname) and NetBIOS name resolution between the domains must exist.

sIDHistory migration requires the following additional dependencies

Success and failure auditing of account management for both source and target domains.
Source domains call this user and group management auditing.
An empty local group in the source domain that is named {SourceNetBIOSDom}$$$.
The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportregistry key must be set to 1 on the source domain primary domain controller.
You must restart the source domain primary domain controller after the registry configuration.
Windows security requires user credentials with the delegated MigratesIDHistory extended right or administrator rights in the target domain. You add these credentials in the wizard when sIDHistory migration is turned on.

For more information, we could refer to:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/inter-forest-sidhistory-migration-with-admt

Hope the information is helpful. Thank so much.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thank you @Hannah Xiong for your quick reply, and I appreciate that you have concisely listed the documented requirements.

However, my question is not "What are the [permission] requirements?"

My question is: "Why is an administrator credential required to read audit policy and registry entry from a SOURCE domain controller, and a sid value from an object in the SOURCE domain?" (Documented requirement = "The user account that is running ADMTv2 must have Administrator rights in the source domain.")

It should be possible to delegate those particular tasks in the SOURCE domain, so the requirement seems outdated and not in line with a least-privilege model for granting access.

If Microsoft has no plans to update this supported utility, then is it correct to conclude that we should not look at ADMT as a solution in our environment?

Thanks again,
DaveC

Answer 3

Hello DaveC,

You are welcome. Thank you so much for your feedback.

As stated in the official documents, the user account that is running ADMTv2 must have administrator rights in the source domain. Or we could create ADMT Service Account.

The ADMT service account needs to have proper permission in source and target domains. We don’t need to use 2 separate accounts. We can use a single service account for the entire migration. Here is the procedure:

1. Create an account in the Target Domain
2. Add this account to the Domain Admins group in the Target Domain
3. In Source Domain, add this account (from target) to the built-in administrator group (not Domain Admin)

Reference: http://portal.sivarajan.com/2010/04/admt-service-account-permission-and.html

According to my knowledge and experience, strict and proper permissions are required for ADMT migration. I totally understand our concerns since we have a principal of least-privilege in our organization. But currently there is no delegate appropriate permissions for ADMT.

If we do not want to share the administrator credentials in the source domain to others, we could enter the credentials remotely during the Remote Desktop Connection. It might be a little complicated and time-consuming, but it could meet our privilege requirement.

Thank you so much for your understanding and support.

Please note: Information posted in the given link is hosted by a third party. Microsoft does not guarantee the accuracy and effectiveness of information.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 4

Hi @Hannah Xiong

For me, the key statement in your reply is here: "But currently there is no delegate appropriate permissions for ADMT."

I have also seen people asking questions about ADMT [v.3.2] support for TLS versions greater than 1.0 and am not certain I've seen any confirmation of whether that's possible.

The indication to me is this utility is very outdated from a security perspective, and I'm struggling to understand why that is; or perhaps they should simply publicly document it only being supported 'as is' if they intend to drop it soon.

I thank you again for your time and support.

-DaveC

Answer 5

Hi DaveC,

Thank you so much for your kindly reply.

The ADMT computer must have TLS 1.0 enabled in order to connect to SQL Server. As for ADMT v.3.2 support for TLS versions greater than 1.0, I have researched but failed to get the confirmation of whether it is possible.

The discussion which was found is about ADMT 3.2 not compatible with TLS 1.2.

https://social.technet.microsoft.com/Forums/en-US/3fdf13c1-7074-428d-8b2a-78cc11f8e4aa/admt-32-not-compatible-with-tls-12?forum=winserver8gen

Thank you so much for your understanding and support.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.