SHIFT

--- Sjoerd Hooft's InFormation Technology ---

User Tools

Site Tools


Sidebar

Recently Changed Pages:

View All Pages


View All Tags


LinkedIn




WIKI Disclaimer: As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.
Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.


Pages with comments

View All Comments

admtrequirements

ADMT Requirements

We are planning to do an Active Directory Migration using the ADMT tool provided by Microsoft. The requirements however are not well explained and certainly not at one place. This page will provide all the requirements with extra information if needed.

Note that this article will keep the following versions in mind:

  • Source domain: AD 2003
  • Target domain: AD 2008 R2
  • ADMT version: 3.2
  • PES version: 3.1

ADMT Information

ADMT OS Requirements

  • Windows Server 2008 R2
    • This can be in either the source or the target domain
      • If you migrate passwords as well using PES the ADMT server needs to be installed in the target domain
    • Use a member server if you can

Both the source and target domains must be running on Windows Server 2003, 2008 or 2008 R2.

The ADMT Agent (installed on computers in source domain) runs on:

  • Windows XP
  • Windows Vista
  • Windows 7
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008 R2

ADMT Database Requirements

The following databases can be used (must be pre-installed):

  • SQL Server 2005 Express with Service Pack 3 (SP3) or later
  • SQL Server 2008 Express with Service Pack 1 (SP1) or later
  • SQL Server 2005
  • SQL Server 2008

The SQL installation must be configured for Windows Authentication Mode.

Domain Trust Requirements

By default, when you setup a domain trust SID Filtering will be enabled. This means you can't use the migrated SID History attributes. If you do want to use this feature you have to explicitly enable this. There are two methods, depending on what kind of trust you have. Note that you need to be domain or enterprise admin.

If you have an external trust run this command from the target domain PDC:

Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /usero:domainadmin /passwordo:domainadminpwd

If you have a forest trust run this command from the target domain PDC:

netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /EnableSIDhistory:yes /usero:domainadmin /passwordo:domainadminpwd

You can also query the current status if you use the /EnableSIDhistory without yes or no.

Note: TrustingDomainName = source domain name; TrustedDomainName = target domain name

Security Concerns

Disabling SID filtering requires a level of trust between the two forests, and ultimately those who are responsible for Active Directory. With SID Filtering disabled, a rogue domain administrator could clone a SID from the other domain and add it to their SID History, granting them unauthorized rights.

SID History Requirements

Before SIDhistory will work it has a few requirements of it's own. However, ADMT will set them for you the first time it runs. If you do not want this, you can set these requirements manually:

  • Create a local group in the source domain to support auditing.
  • Enable TCP/IP client support on the source domain primary domain controller (PDC) emulator.
  • Enable auditing in the Windows Server 2008 source and target domains.

Create a Local Group in the Source Domain to Support Auditing

In the source domain, create a local group called SourceDomain$$$, where SourceDomain is the NetBIOS name of your source domain, for example, Boston$$$. Do not add members to this group; if you do, SID history migration will fail.

Enable TCP/IP Client Support on the Source Domain PDC Emulator

  • On the domain controller in the source domain that holds the PDC emulator operations master (also known as flexible single master operations or FSMO) role, go to Start → Run.
  • Type regedit and click OK.
  • Navigate to the following registry subkey:
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
  • Modify the registry entry TcpipClientSupport, of data type REG_DWORD, by setting the value to 1.
  • Close Registry Editor, and then restart the computer.

Enable Auditing in Windows Server 2008 Domains

  • Log on as an administrator to any domain controller in the target domain.
  • Go to Start → All Programs → Administrative Tools → Active Directory Users and Computers.
  • In the console tree, expand the domain, right-click the Domain Controllers OU, and then click Properties.
  • On the Group Policy tab, click Default Domain Controllers Policy, and then click Edit.
  • Double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Audit Policy.
  • Double-click Audit account management, and then select both the Success and Failure check boxes.
  • Click Apply, and then click OK.
Repeat these steps in the source domain.

Permissions requirements

You should just use the domain or enterprise admin accounts, but if you want to go deeper see the resource link for Migration Accounts from the Micrsoft knowledgebase.

PES Requirements

The PES service can be installed on any writable domain controller in the source domain that supports 128-bit encryption (default on both Windows Server 2003 / 2008).

The PES Service should be installed after ADMT.

PES requires an encryption key to be created on the computer running ADMT in the target domain.

Command to create key:

admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password> / *}

To import the key in the sourcedomain (should be done in the wizard while installing but just in case):

admt key /option:import /sourcedomain:sourcedomain.local /keyfile:key.pes
Value Description
<SourceDomain> Specifies the name of the source domain in which the PES service is being installed. Can be specified as either the Domain Name System (DNS) or NetBIOS name.
<KeyFilePath> Specifies the path to the location where the encrypted key is stored.
{<password> / *}A password, which provides key encryption, is optional. To protect the shared key, type either the password or an asterisk (*) on the command line. The asterisk causes you to be prompted for a password that is not displayed on the screen.

PES service should be running as an authenticated user in the target domain.

The PES service should only run during password migrations.


After the installation of PES the DC will have to be restarted.

Resources

Quering SIDs

Use these examples to query for SIDs:

dsquery * -filter "&(objectcategory=user)(samaccountname=sjoerd.hooft)" -attr objectsid
dsquery * -filter (samaccountname=sjoerd.hooft) -attr sIDHistory

Sharepoint

Now Sharepoint proved to be a migration and project by itself. We have a 2007 farm which was out of support and out of maintenance. Seriously out of maintenance. When testing the migration we found that about 40% could not be migrated because of the error:

Cannot complete this action.

Please try again.

Of course, trying again did not meant the error was gone. Also, the error would show up for the same users again and again. We did found the error at the end, with the help of Microsoft support but I decided to create a separate page for it, because of the amount of information:

Sharepoint User Domain Migration using Stsadm

I also came across this bug where stsadm -o migrateuser doesn't work in a sharepoint 2003 environment. We didn't come across this issue, it's just here for reference:

Sharepoint 2003 Bug

There is an issue on Sharepoint 2003 where migrated users could not access their resources using the SID History. Newer sharepoint versions should not have this problem, but anyhow, you can use this command to fix it on user basis:

stsadm -o migrateuser -oldlogin DOMAIN\user -newlogin DOMAIN\user [-ignoresidhistory]

MS KB: After you migrate a user from a different Active Directory domain, the user can no longer access Windows SharePoint Services

Kerberos Max Token Size

After migrating AD User Accounts between Active Directory Domains, and enabling the SID history, some users were not able to logon anymore. This is because the Kerberos token size is too big so users cannot access their profile anymore, cannot access their network mappings and policies are not applied anymore. I created a separate page for it, again, because there is a lot of information:

Fix: After ADMT Migration Users Cannot Logon - Profile Errors - Kerberos - MaxTokenSize

You could leave a comment if you were logged in.
admtrequirements.txt · Last modified: 2021/09/24 00:24 (external edit)