Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Migrating from NT and Windows 2000 Domains to Windows Server 2003

If you are unable to do a direct upgrade of your NT or Windows 2000 domain, you can create a new Windows Server 2003 domain and migrate users, computers, and groups into it from an existing domain. Microsoft provides several migration tools in the shrink-wrap for this purpose. The most rudimentary of these tools are a set of scripts for cloning security principals between domains. They are as follows:

• Clonepr .
  Copies a user account to the target domain.




• Clonegg .
  Copies Global groups to the target domain.




• Clonelg .
  Copies local groups to the target domain.




• Cloneggu .
  Copies Global groups and users to the target domain.




• Sidhist .
  Takes the SID of a user or group from one domain and assigns it to a user or group in the target domain. There will be more on SID History in a moment.

Using these scripts can get a little cumbersome in a large migration. They have very little in the way of error reporting and no testing capabilities. For more advanced migrations, Microsoft provides a suite of migration wizards it calls the

Active Directory Migration Tool , or ADMT.

The technology in ADMT was originally licensed from NetIQ. The version that shipped in Windows 2000 was capable of doing small-scale migrations. Version 2 of ADMT in Windows Server 2003 has been extended and modified to permit migrating passwords, preserving user profiles, and simplifying the re-permissioning of file and print servers and user desktops. The documentation has been improved dramatically, as well.

It is entirely possible to handle a large-scale migration using just ADMTv2, but you may want to look at third-party offerings from vendors who make migration and consolidation tools. You may find that spending a few dollars on the right tool can save you hundreds of hours and lots of tedious work during the migration. Here are the major products in this area:

• Controlled Migration Suite .
  Aelita Software, www.aelita.com.




• FastLane Migrator .
  Quest Software (formerly FastLane Technologies), www.quest.com.




• Domain Migration Administrator .
  NetIQ, www.netiq.com.




• bv-Admin for Windows 2000 Migration .
  Bindview, www.bindview.com.

All of these tools handle the small details of migration equally well. They differentiate themselves primarily by their reporting capabilities, simplicity of use, and customizability. The vendors also offer additional tools that simplify domain management after you've completed the migration, so you might want to get a package deal if one of them looks attractive.

SID History

Figure 9.26 shows an example of a classic NT master/resource domain. The user is a member of the account domain. She logs on at a desktop that is a member of the resource domain. She accesses resources on a server that is a member of the same resource domain as the desktop.

A shared resource on the server is protected with an access control list that contains the SID of a Machine Local group. An administrator in the resource domain has nested a Global group from the account domain into the Machine Local group at the server. The user is a member of this Global group.

Here's a quick synopsis of what happens when the user touches the shared resource. The server validates the user's credentials using classic NTLM pass-through authentication, then creates a local process thread for the user and attaches to it an access token. The token contains the user's SID, the SID of the Global group from the account domain, and the SID of the Machine Local group. This SID in the access token gives the user access to the shared resource.

If you create a new account for the user in the Windows Server 2003 domain, the user could log on but would get an entirely new SID with an entirely new set of group memberships. If you did nothing further to support the migration, the user would lose access to resources in the original domain. Sure, you could re-permission all the folders in the original domain with groups and users from the new domain, but that's a

lot of work.

Microsoft provides a technology to resolve this problem, a technology that underlies all the migration tools, both from Microsoft and third parties. This is a function library called

SID History . You'll also hear it called the SID History API.

SID History permits you to create an account for a security principal (user, group, or computer) in a target Windows Server 2003 or Windows 2000 domain then populate a special attribute called SIDHistory with the contents of the principal's original SID.

Figure 9.27 shows what happens when a freshly minted Windows Server 2003 user created using the SID History API touches a resource in the original domain.

The user logs on to the Windows Server 2003 domain using a new account that has been cloned into Active Directory from the original domain. The user touches a resource on a server in the original domain. The server validates the user using classic NTLM pass-through. The domain controller in the Windows Server 2003 domain provides a set of SIDs to the server. This list of SIDs includes the following:

• The user's SID from the Windows Server 2003 domain




• The user's SID from the original domain obtained via the SIDHistory attribute in the user's Active Directory object




• The Windows Server 2003 domain SID for the Global group to which the user belongs




• The original SID of the Global group obtained via the SIDHistory attribute of the Global group's Active Directory object

The local access token built by the server as part of this transaction contain those SIDs plus the SID for the Local Machine group that has the original domain Global group as a member. This local access token gives the user access to the resource even though the user logged on to a completely different domain.

Computer Account Migrations

The server and computer accounts in resource domains, such as those shown in Figure 9.27, present another sort of challenge for migration. The desktop is a member of a resource domain, whereas the user is a member of a trusted account domain. For the migration to work, the resource domain must trust the Windows Server 2003 domain or else the user will not be able to log on to the remote domain from the local desktop. Classic NT trust relationships are not transitive.

The permanent solution is to move the desktop to the new domain. This could be done by disjoining it manually from its resource domain and joining it to the Windows Server 2003 domain, but ADMT and the third-party migration tools have ways to automate the migration. As part of the process, the user's local profile and permissions to local NTFS files are transferred to the user's account in the remote domain.

ADMT has a security translation feature that can re-permission a member desktop or server, either by replacing the old user SIDS with their new SIDs or by using SID History to retain access for both accounts. This security translation feature is called up as part of a computer migration. Access to the user's original profile is maintained during this evolution. Figure 9.28 shows an example.

The Computer Migration Wizard also has options for renaming computers as part of the migration, which is helpful if you would like to add a prefix to indicate that the computer account is a member of the new domain.

The Computer Migration Wizard makes the changes to the local desktops and servers then dispatches an agent to restart the machine. For this to work, the Windows Server 2003 domain account you use to run ADMT must have administrator privileges on the desktops. You cannot put this account in the Domain Admins group of the NT or Windows 2000 domain because Global groups cannot have members from outside the domain. The simplest workaround is to use an account from the source domain that has been given sufficient privileges in the Windows Server 2003 domain to run ADMT.

You can also elect to run the security translation as a separate process after a migration to clean up permissions on desktops and servers and get rid of the old accounts. You should do this prior to decommissioning the NT domain to avoid lots of bare SIDs on the ACLs of your folders and files.

You can use ADMT to migrate IA64 desktops and servers to another domain, but the agent dispatched from an IA32 machine will fail to restart an IA64 machine. You must restart the IA64 machines manually.

Group Account Migrations

Migrating user accounts to the Windows Server 2003 domain only accomplishes half the work necessary to assure that users retain access to their resources in the original domain. On the other side of the equation lies the Machine Local and Global groups to which the user belongs.

When planning the user migration, start out by finding closed sets of users and groups. For example, you might want to migrate user Amcbeal, who is a member of the Legal group. But Jcage is also a member of this group, so you may decide to migrate him, as well. But Jcage is a member of the General_Partners group, so you want to migrate that group at the same time, but it has user Rfish as a member.

Tossing a lasso around all the interlocking users and groups in a domain can get a little complicated. Fortunately, ADMT has the capability to add migrated users into groups that have been previously migrated.

Preparing for Account Migration

As you can imagine, the ability to nab a user's SID from one domain and put it in a user account in another domain is a highly privileged operation. The SID History API has an

extensive list of requirements. If you decide to migrate passwords along with the user accounts, there are even more items you must configure first before proceeding. Here are the prerequisites for performing an inter-forest migration (the next section contains the steps for including password migration):

• Target domain functional level. The target domain must be running in either Windows 2000 Native or Windows Server 2003 functional level. This is required because SID History cannot be stored in a classic SAM, so all BDCs must be off the wire.




• Source domain affiliation. If you are migrating from a Windows 2000 source domain, the domain cannot be in the same forest as the target domain.




• Service packs.
  An NT4 source domain controller must be running SP4 or later. A Windows 2000 source domain controller can be running any service pack.




• Trust relationships.
  The source domain must trust the target domain. This ensures that the ADMT agent has the proper security context.




• Administrator privileges.
  The account you use to perform the migration must have full administrator privileges in both the source and target domain. You can accomplish this by taking advantage of the trust relationship between the source and target domain. Place the Windows Server 2003 domain account you're using to perform the migration into the Administrators group in the source domain.




• Resource domain trusts.
  If you are migrating computer and server accounts out of a resource domain, the resource domain must have a direct trust to the Windows Server 2003 domain. You cannot use the trust between the account domain and the Windows Server 2003 domain because classic trusts are not transitive.




• Migration tracking group.
  The source domain must have a local group named

  Domain $$$, where

  Domain is the NetBIOS name of the domainfor example, NT-DOM$$$. This group cannot have any members. It is used to verify the identity of the source domain. ADMT will create this group automatically if it does not already exist. If you create it yourself, be sure to create a Domain Local group, not a Global group.




• Network Connections.
  Break all connections between the source and target domain controllers, including mapped drives and printers. The ADMT agent must have unambiguous control of the communication between the machines.




• TCP/

  IP access to SAM.
  Ordinarily, the SAM can only be accessed via RPC connections. For purposes of migration, ADMT needs access using TCP/IP connections. This requires a Registry change in the source domain. ADMT will make this change automatically, but here it is if you want to do the change manually:

  
  Key:    HKLM | System | CurrentControlSet | Control | Lsa
  Value:  TcpipClientSupport
  Data:   1 (REG_DWORD)
  




• Auditing.
  Account management auditing must be enabled in both domains. This ensures that a record is kept of anyone who exercises the SID History API. See the sidebar, "Account Management Auditing," for details. Be sure to turn off auditing when migration is complete or you will fill the Security log.




• Administrative shares.
  The so-called dollar-sign ($) shares must be available on both the source and target domain controllers. Check this by running NET SHARE from the command line.




• Target

  OU .
  The migrated groups, users, and computers must be placed in an OU in the target domain. You can use existing OUs or create new ones for this purpose.

Password Migration

ADMT can preserve passwords by installing a password migration agent at the source domain controller that can respond to password dump requests from the target domain controller. For security reasons, the source DC must validate the identity of the target DC independently of the normal NTLM authentication. This is done using a password migration key.

You create the password migration key at the target DC by running a command-line version of ADMT. You then transport it by floppy to the source domain controller, where you run a Password Migration Wizard from the Windows Server 2003 CD. The wizard verifies that you have the password migration key prior to installing and initializing the migration agent on the source DC.

The password migration agent at the source DC needs access to user accounts in Active Directory at the target DC. This requires support for null session access to Active Directory because the source DC is running NT and cannot perform a Kerberos logon. Part of the migration preparation, then, involves setting domain controller policies to permit null session access.

Perform the steps in Procedure 9.4 prior to running ADMT if you want to migrate passwords along with user accounts.

Procedure 9.4 Configuring the Password Migration Agent

1. Enable the Network Access: Let Everyone Permissions Apply To Anonymous Users group policy in the Default Domain Controllers Policy of the target domain. This policy is located in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.

2. Add the Everyone group to the Pre-Windows 2000 Compatible Access group in the target domain.

3. Create the password migration key and save it to a floppy using the ADMT command-line tool with the following syntax: admt key <

   source_domain_name > <

   drive letter > <

   password >. If you do not want to type the password in clear text on the screen, enter an asterisk (*) and you will be prompted to enter it. The password key will have a PES extension.

4. Transport the floppy containing the password to the source domain controller along with the Windows Server 2003 CD, which contains the password migration utility.

5. At the source domain controller, insert the floppy in the floppy drive and launch the password migration utility from the Windows Server 2003 CD in the \Valueadd\Msft\Mgmt\Admt\Pwmig folder.

6. The Password Migration Wizard finds the password file on the floppy and prompts you for the password to open it. The wizard then completes the installation of the migration utility to the source domain controller.

At this point, the password migration agent is installed on the source domain controller but it will not respond to dump requests until you toggle a Registry entry created by the setup wizard. Here is the Registry entry:

Key:    HKLM | System | CurrentControlSet | Control | Lsa
Value:  AllowPasswordExport
Data:   0 (REG_DWORD)

Toggle the Data entry from 0 to 1. With this done, you're ready to begin the account migration.

Migrating User and Group Accounts

After the password migration agent is installed and properly configured on the source DC, and you've met the prerequisites for the account migration, you can run through a test migration using ADMT to verify that everything works as it should.

The example in Procedure 9.5 uses the Group Account Migration Wizard in ADMT to migrate groups and their users from an NT domain to a Windows Server 2003 domain. For me, it is simpler to select a single group to migrate than cherry-picking individual users from what might be a lengthy list. You may feel differently and want to migrate individual users. The end result is the same.

Procedure 9.5 Performing a User and Group Migration Using ADMT

1. Launch the ADMT utility from the A

   DMINISTRATIVE T

   OOLS menu.

2. Right-click top of the tree and select G

   ROUP A

   CCOUNT M

   IGRATION from the flyout menu. This launches the Group Account Migration Wizard.

3. Click Next. The Test or Make Changes window opens. At this point, you only want to test the migration.

4. Click Next. The Domain Select window opens. Select the source and target domains from the pick lists. If the domain does not appear, you have a problem with WINS or DNS.

5. Click Next. The Group Selection window opens. Click Add to open the standard object chooser window. Select the groups you want to migrate from the source domain. You cannot migrate Builtin groups.

6. Click Next. The Organizational Unit selection window opens. Use the Target OU browser to select the OU where you want the groups to be migrated.

7. Click Next. The Group Options window opens (see Figure 9.29). Select all check blocks in this window except for Update Previously Migrated Objects.

   Figure 9.29. Group Migration WizardGroup Options window.

   

8. Click Next. The wizard reports that you do not have a TARGET$$$ local group in the source domain and offers to create it.

9. Click Yes. The wizard reports that you do not have the TCP/IP Registry support key in the source domain and offers to create it.

10. Click Yes. The wizard prompts whether you want to reboot the source domain controller to ensure the changes take effect. This is required for the Registry update.

11. Click Yes. While the source domain controller restarts, the wizard continues. The User Account window opens. Enter the credentials of an administrator in the source domain. Wait for the source domain controller to finish restarting before proceeding.

12. Click Next. The Naming Conflicts window opens (see Figure 9.30). Choose an option for handling situations where a group or username already exists. The safest option is Ignore Conflicting Accounts And Don't Migrate.

    Figure 9.30. Group Migration WizardNaming Conflicts window.

    

13. Click Next. The Group Member Password Options window opens. You can create passwords for the users or you can migrate their existing passwords. Select the Migrate Passwords radio button and select the source domain controller. If you did not install the password migration agent on the source domain controller, you will get a series of errors.

14. Click Next. The Group Member Transition Options window opens. You can elect to enable the target accounts and disable the source accounts, but it's safer to leave both sets of accounts active in case something unexpected goes awry with the Windows Server 2003 logon. You can set an interval after which the source accounts are disabled automatically.

15. Click Next. A summary window opens.

16. Click Finish. The Group Migration Wizard walks through a trial migration and displays the results as it goes. This information is saved to a local Jet database where it can be referenced by later migrations.

If ADMT encounters any errors on the test migration, it lists them in the progress window with details in the Migration log. If there are no errors, you can proceed with the actual migration using the same steps.

When the actual migration is finished, verify the following:

• User and group accounts are in the correct OU.




• Group membership shows the correct users.




• Users can log on to the Windows Server 2003 domain using their original passwords.




• Users can log on to the Windows Server 2003 domain and access shared folders and printers on NT or Windows 2000 servers in the source domain.




• Users retained their original profiles with access to all share points.

A full migration of users, groups, and computers takes a long time. When the smoke clears, and you no longer need the source domains, take an afternoon and run through the ADMT Security Translation Wizard to remove the old accounts from the desktops and servers. This avoids having a bunch of bare SIDs that cannot be resolved to friendly names after the source domain controllers are no longer available.

You should also clear out the SID History entries from the security principal accounts in Active Directory. This speeds up performance somewhat and eliminates quite a bit of complexity when dealing with access rights issues.