Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2006-12-27) Migrating Stuff With ADMTv3

Posted by Jorge on 2006-12-27


ADMTv3 has been out for a while and is the free Microsoft Migration Tool available for use (besides other small tools that can help you during your migration like NETDOM, SUBINACL, ROBOCOPY, etc.). It can be downloaded here

Besides the tool you can also view and download documents with loads of info about migrations and how to use ADMT. The following information is available:

 

ADMTv3 is a migration tool that can help you with:

  • Migrating user and group objects (with or without sIDHistory) from one domain to another
  • Migrating computer objects and the actual computers from one domain to another
  • Translate stuff (from source domain –> target domain):
    • Security on file based data ACLs
    • Security on printers ACLs
    • Security on shares ACLs
    • Security on registry ACLs
    • Security on profiles ACLs (and registry information)
    • Service Accounts used by services
      • REMARK: make sure you identify the custom service accounts FIRST on each server to be migrated. This also prevents the option "change password at next logon" being set as the user account is migrated. All accounts NOT identified as service accounts will have the option set. If needed you can revert this afterwards with ADMOD/ADModify
    • It CANNOT help you with:
      • Translate security on services ACLs. For that you can use SUBINACL
      • Translate information within IIS and COM+. For that you need to use a third party tool
      • Translate information within SQL. For that you need to use a third party tool
      • ….other apps…. –> For that you might need to use a third party tool

 

Interesting enhancements within ADMTv3 when compared to ADMTv2:

  • When migrating between AD forests, it is aware of possible schema differences between the AD forests
    • It allows to define attributes for exclusion during migration
    • Schema differences (attributes that are not migrated) are shown within the migration logs
  • SQL or (W)MSDE database support
    • Enables and supports the use of multiple consoles
  • The possibility to select source and target DCs for migrating objects
  • It supports INPUT files for objects to be migrated
  • It allows the rename of objects during migration (through the use of an input file)
  • Performing pre-migration tests to ensure availability of computers to be migrated
  • Additional options when migrating passwords like:
    • "Do not update passwords for existing users"
    • Migration of changed passwords from source domain
  • The "Password Export Server (PES)" can be configured to run with a service account. This enhancement removes the dependency on the "pre-Windows 2000 compatible access" group that PREVIOUS should contain the well-known security principals "Everyone" and "Anonymous Logon" (in W2K only "Everyone" as that by default already contained "Anonymous Logon") (in W2K3 you can revert to the same behavior but that IS NOT recommended!)

 

NOT that of an enhancement:

  • It can only be installed on Windows Server 2003

 

When migrating from one domain (source) to another domain (target) the following are high-level steps to consider:

  • Make sure the target AD has been configured (sites, subnets, replication, OUs, GPOs, delegations, DNS, WINS, DHCP, etc.)
  • Setup name resolution (WINS or DNS) between source and target domain/forest
    • REMARK: When either endpoint of a trust is NT4, you must use NetBIOS name resolution which is made possible by WINS or LMHOSTS. When either endpoint of a trust is W2K or higher, you can either use NetBIOS name resolution, which is made possible by WINS or LMHOSTS, or use DNS name resolution (I prefer the last!)
  • Setup trusts between source and target domain
    • REMARK: When either endpoint of a trust is NOT W2K3, you must use an external trust. When either endpoint of a trust is W2K3 or higher, you can either use an external trust or a forest trust. For the latter, which one you use depends on the environment and your requirements.
      Be aware that sIDFiltering is by default enabled on the outgoing part of an external trust (which therefore impacts the use of sIDHistory AND/OR the use of external domain group membership within the same target forest)
      sIDFiltering is by default NOT enabled on the outgoing part of a forest trust (which therefore does NOT impact the use of sIDHistory AND/OR the use of external domain group membership within the same target forest). Some documents might mention sIDFiltering is enabled by default on the outgoing part of a forest trust. This is not true!
      When sIDFiltering is enabled on the outgoing part of a trust and sIDHistory is used AND/OR domain external domain group membership within the same target forest, you need to disable it using the following command:
      • Netdom TRUST <TrustingDomain> /domain:<TrustedDomain> /quarantine:No /userD:<domainadminAcct> /passwordD:<domainadminpwd>
        (to ENABLE sIDFiltering again specify Yes)

 

SOURCE DOMAIN —————–(trust)—————–> TARGET DOMAIN
                              ^                                             ^
                               |                                              |
                               |                                              |
                               |                &nbsp
;                             |
                    outgoing part                           incoming part
(sIDFiltering is ALWAYS configured on the outgoing part of a trust – not saying if it is configured or not! Just saying WHERE)

Also see:

  • Setup migration accounts to be use with the migration tooling
    • REMARK: this really depends if you have a one-way or two way trust, what you want to migrate and if the source and or target domain are AD… see the migration guide for this!
  • Install and configure migration tooling and if needed for password migration, also designate a source DC as the Password Export Server (PES) and install the required software
  • Identify service accounts across servers in the source environment
  • Migrate groups, user accounts with passwords and group memberships (with sidhistory)
    • REMARK: When resource access is provided by a sID, sIDHistory can help you. However if resource access is provided in another way (e.g. <domain><user or group>, or something else), you MUST add the target ACEs first before the users switch over to their new account. When not taken care of, resource access might be lost. Examples of applications where this can occur is SQL server.
    • REMARK: To use sIDHistory your target domain MUST be in at least "Windows 2000 Native" mode or domain functional level. Well, this is the supported configuration! There exists migration tooling that is able to migrate sIDHistory without the AD domain being in at least "Windows 2000 Native" mode or domain functional level, or in other words, still being in "Windows 2000 Mixed" mode or domain functional level. Remember, the latter is NOT supported by Microsoft! I also do not know that the impact is of this and what requirements might exist emposed by the migration tool.
  • Migrate clients from the source domain to the target domain, translate security on the client, and translate profiles (at this moment users start logging on with their new AD account on the migrated clients that have been migrated previously to the w2k3 domain)
  • Migrate mailboxes if needed
    • REMARK: This is another story and it depends if you are migrating from Exchange 5.5 or Exchange 2000/2003
  • Migrate servers to the new domain or migrate data to new servers
  • Translate security (Re-ACL) and other stuff of the data/resources from source security principals to target security principals (replace the security descriptors from the old domain with the security descriptors from the new domain) (see list above)
    • REMARK: Although you might have not yet translated security it might look like the ACLs already show security principals from the target domain. This DOES NOT mean security has been translated. This occurs when using sIDHistory as the target system recognizes the sID (because it is stored in the sIDHistory field) and shows the target security principal instead of the source security principal. If you would cleanup sIDHistory suddendly the source security principal is shown and if you additionally remove the trust an "unknown sID" is shown
  • Cleanup temporary configurations
  • Cleanup sidhistory (recommended!).
    • REMARK: sIDHistory is a temporary configuration and is used to access resources while those resources still have security descriptors from the source domain. As soon as all data (file, folders, mailboxes, etc.) have been re-ACL-ed sIDHistory can be cleaned. sIDHistory should only be used temporary for migration purposes! To clean sIDHistory you can use ADFIND and ADMOD. The command line looks like:
      • For the complete target domain:
        • adfind -default -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
      • For just some OU within the target domain:
        • adfind -b "<DN of some OU>" -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
  • Remove trusts
  • Decommission old domain(s)

 

For more information about ADMTv3 and possible steps needed for migration see the ADMT v3 Migration Guide.

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

10 Responses to “(2006-12-27) Migrating Stuff With ADMTv3”

  1. Hi Jurgen,
    Thanks for a nice article, there is very few of them that reflect ADMT 3.0. I’m in the process of doing a migration and I was wondering if you have any experience as regards to Transitioning Service accounts. In the ADMT guide it state that you should select Click Generate complex passwords. If I haven’t missed something, this will defenty crash my applications that uses servicee accounts. If you have any information, please send me a mail bjorn at advisec.com.
    Thanks!
    Björn

  2. Jorge said

    even for service accounts you can migrate its password.

    have a look at the ADMT migration guide (see above) to see how to configure the migration of password

  3. Great article & great add-on to the ADMTv3 guide! I have one question: since ADMTv3 came out before Windows 2003 R2 SP2, do you know if there’s any incompatible issue between them ot have you tried installing ADMT3 on R2 SP2 & had a successful migration?

  4. Jorge said

    I assume there should not be any issues installing ADMTv3 on a W2K3R2-SP2 server.
    Why? Are you experiencing issues?

  5. Hi there!
    Do you know if this application could be used to create a test AD Environment, same as Production AD Environment?
    Is there any way to mirror a Prod AD Env to a Test AD Env?
    Thanks,

  6. Was unable to use adfindadmod to update sidHistory ended up following Microsoft’s script. Didn’t have the time to figure out why it was giving me the access denied. Was fully elevated, blah, blah, blah. Nice coverage in this article, was looking for adfind and sidHistory and you hit exactly what I wanted.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;295758

    You have a broken link on the “When To Create An External Trust”

  7. […] this post I explain what you can do with ADMTv3 and what you cannot do. Additionally I also define common […]

  8. […] info about ADMT can be found here and […]

  9. […] More info about performing migrations with ADMT can be found through this link. […]

  10. […] The latest ADMT Migration Guide in WORD format can be downloaded through this link. The web-based version of the ADMT Migration Guide can be downloaded through this link. For additional migration related information you may also want to check this link. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: