A little bird (Ned Pyle) at AskDS told me that ADMT 3.2 is released!

The software can be downloaded here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=20c0db45-db16-4d10-99f2-539b7277ccdb

One of the limitations of ADMT 3.1 was that it couldn’t be installed on Windows 2008 R2, ADMT 3.2 now can. Another limitation was that you had to install it on a domain controller to be able to migrate sidHistory using the command line. I hope they solved this issue. This and other issues are described more in detail at KB976659: Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers

Active Directory Migration Toolkit 3.1 does not install on Windows 2008 R2, however there is nothing wrong with installing it on Windows 2008 x64. When you start playing around with the ADMT vbscripting options you might run into the following error: “ActiveX component can’t create object: ‘ADMT.Migration"’.

The solution is easy, run the script with the x86 version of cscript.exe: “c:\windows\syswow64\cscript.exe script.vbs”

My source: TechNet forums

Why was I toying around with the vbscript instead of using the admt.exe commandline options? I wanted a way to find out which attributes are excluded by ADMT. It seems that one the first run ADMT gathers a list of attributes it will always exclude for migration. Examples are “mail” or “proxyAddresses”. The ADMT help states this could only be done through scripting. This is explained in detail in KB937537.

When migrating user or group objects with ADMT, one of the options is to update the user rights for the migrated objects. For me the ADMT help or migration guide have always been pretty unclear what this option in fact does.

If you grant a group or user user rights assignments like “act as part of the operating system” or “impersonate a client after logon” on the domain controllers in the source domain, then “update user rights” option in ADMT will ensure the migrated object will get these user rights assignments as well.

Picture of the source security policy on a DC:

The ADMT migration log saying that the privileges where granted. The seTcbPrivilege means “trusted computing base” privilege and is in fact “act as part of the operating system”.

And in the security policy of a domain controller in the target domain:

This is an option which I would rather not check during migrations. If some of the users or groups require these kind of privileges, I would set them by hand afterwards.

For my current project I wanted to ease some of the ADMT tasks by using an option file and as such avoid the GUI and its repeatedly point and clicks. So I ended up figuring out how to translate the checkboxes from the GUI to the option file equivalent. At first I thought figuring out what the exact options were would be hard. Not at all! A nice sample is given in the ADMT guide and every (I mean every) possible setting/value is explained in a help file located somewhere in the c:\windows\admt installation folder.

The ones which weren’t explained was the syntax for the “source ou” and “target ou”. One could think, how hard can that be?

• ou=users,ou=department,ou=resources,dc=source,dc=com
• ou=users,ou=department,ou=resources
• LDAP://source.com/ou=users,ou=department,ou=resources,dc=source,dc=com

Example error:

The migration log was stored in the database. The migration log can be retrieved from the database by using the 'ADMT TASK' command. Unable to migrate users. Unable to bind to container 'LDAP://targetdomain/OU=users,OU=_Migration,DC=target,DC=com'.  Unable to get distinguished name for 'target.com/LDAP://target.com/OU=users,OU=_Migration,DC=target,DC=com'.  : The parameter is incorrect. (0x80070057)

And a screenshot:

All my options were wrong, so I started google and stumbled upon this: GNT Forums: ADMT command line or vbscript syntax in OU

The required syntax is the following:

• drop the domain part from the DN
• provide the OU’s up to down in the domain tree
• separate OU’s by using “/” (not ou=,)

Example:

• “resources/department/users”

Now that wasn’t obvious to me…

Once the option file is completed, it can be used with the admt commandline tool: “admt user /f:users_to_migrate.txt /o:optionfile.txt”. This is merely and example, a lot of variations on this matter exist.

Another requirement for ADMT to start migrating SIDhistory is the “Audit Account Management” setting on both source and target domain DCs. This should be set to both success and failure. When the domain still has Windows 2003 domain controllers, then this is as easy as setting the following setting in the domain controllers GPO:

However when dealing with Windows 2008 (or 2008 R2) domain controllers, the new fine-grained auditing settings come in play. Setting the above might have no effect. See how the setting is managed by GPO, but the setting says “no auditing”:

The reason for this is the “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” (wow what a setting) which is enabled.

When this setting is active, we have to configure the auditing configuration through auditpol.exe (a built-in command line utility). Try using “auditpol /get/ category:*” to find out the current settings. Or use “auditpol /set /category:”Account Management” /success:enable /failure:enable”. In the end the Account Management category should look like:

Remember: the auditpol commands have to be executed on each domain controller! If you have the MS Enterprise Client model implemented, as referenced in my previous blog entry, you will have to edit the template auditing settings files in the sysvol folder which come with the EC accelerator.

A nice place to start when considering ADMT is the ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains The above requirement comes from this guide.

When users and groups are migrated using the Active Directory Migration Tool (ADMT), there is an option to copy the SID’s of the objects in the source domain to the target domain. The reason for this is to allow migrated users to access resources which are still located in the source domain, and hence are secured with SID’s of the source domain.

By default a trust doesn’t allows users to access resources by using SID’s from their SID history. This is security feature. When creating a trust the following message is shown:

SIDhistory can be temporarily enabled until all resources are migrated from the source domain. SID history should be enabled on the outgoing trust of the trusting domain. The following example will explain the roles of the domains in the commands:

• Source domain
  • contains the user & group objects before migration
  • contains the resources to be accessible during the migration
  • is called the “trusting” domain
• Target domain
  • contains the user & group objects after they are migrated
  • is called the “trusted” domain

Which command to use depends on the type of the trust:

• External trust: netdom trust trustingDomain /domain:trustedDomain /quarantine:no
• Forest trust: netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes

It might seem contradictory that one command requires yes and the other no, but in fact these both enable the use of SIDhistory across the trust. If you want to determine the current state, simply execute the command without the “:no” or “:yes” behind them. An example:

Depending from which side of the trust you launch this command, you might have to specify additional credentials, you can specify (optional) credentials for both the trusting and the trusted domain. The commandline options for netdom trust are explained at TechNet.

Today I received “access is denied” both at trying to enable SIDhistory or simply trying to determine the current setting.

The reason? "Network access: Allow anonymous SID/Name translation" has to be enabled on the domain controllers. This settings can be found in the domain controllers GPO’s (either the default or your custom ones) at "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options". On a Windows 2003 domain this is not disabled by default, but in my Windows 2008 R2 target domain, the Microsoft Enterprise Client security model is implemented and this disables the anonymous SID/Name translation. if you want additional information about this setting, check KB823659

I think it might actually be necessary to enable this when configuring or reading the current setting concerning the SIDhistory. I don’t think this has to be enabled for SIDhistory to actually work. If it does, I’ll post an update in the following weeks.

My source: sid-filtering access is denied

In the end all is fine: