CSCF Migration Path From NT4 Domain to Active Directory

The full deliberations that took place with respect to migrating CS Windows computing from the old MFCF NT4 domain to the CSCF Active Directory forest can be found in the ST item [UW-MFCF#39655]. Below is an outline of the key steps made in the development of the new forest and the movement of users and computers into the forest.

Initial Migration Outline

Upon review of this item we've considered the following:

• In splitting the MFCF domain, CS will create a new Windows 2003 Active Directory forest and not a new NT 4 type domain.
• Finalize a forest structure. The simplest form involves three domains. This would require anywhere from six domain controllers (at minimum) to nine domain controllers (ideal as recommended by Microsoft).
  • One empty domain to serve as the forest root.
  • One production domain for research, administration and graduate students (GENERAL)
  • One production domain for undergraduate teaching (STUDENT)
    • Our intent to create the STUDENT domain remained proposed only during the planning stage.
• Determine and order required server hardware.
• Build the CSCF Active Directory forest on the new servers using the CSCF Standard Windows 2003 Server image.
• Establish two way trusts between the existing MFCF domain and the new GENERAL domain. A similar trust relationship should also be done between the prototype DRAGONFLY domain (where the elegans terminal servers were initially managed) and STUDENT, if the STUDENT domain was to be implemented.
• Migrate (copy) CS user accounts into their corresponding new domains.
  • We had already determined, through course work and experimentation, that user accounts can be migrated (copied) from an NT4 domain to a Windows 2003 domain. This includes a users' password, group membership and SID history. According to the documentation, computers can be migrated in a similar fashion. Microsoft provides a Migration Tool in their Windows 2003 server Installation CD for this purpose.
• Migrate CS Windows computers into their corresponding new domains.
  • Workstation and Terminal server migration was ultimately handled in a different manner which will be discussed later in this document.
• Change the default logon domain on all workstations and terminal servers to reflect the new domain names
  • This is a simple registry key edit that can be managed remotely during the migration process.
• Terminate the trusts to the old domains.

This plan would be later expanded to include the creation of two new samba servers in the core and teaching regions for Windows access to user file and print services.

• smb-files.cs
• smb-files.student.cs

Defining the CSCF Active Directory Forest Structure

The final structure for the CSCF Active Directory is outlined in the document ADForestLayout. You will note that the GENERAL domain became known as the CS-GENERAL domain. The STUDENT domain is also renamed and called CS-TEACHING. These names will continue to be used in the rest of this document.

Acquiring the Server Hardware

Creation of Forest Root Domain: CSCF (cscf.uwaterloo.ca)

dcpromo.exe run by a local Administrator initiates the process of promoting a Windows 2003 server into a domain controller. The local Administrator is presented with a wizard which provides him with simple choices for this creation process. For CSCF, these options were all left to be default.

The first server to be promoted was elisa (dc202.cscf). In this case we were creating a new forest root domain with domain name cscf.uwaterloo.ca.

The promotion process took about 5 minutes and one reboot.

Adding Redundant DCs to the CSCF Domain

glaciais and aeshena were to be added the the CSCF domain as domain controllers in a similar manner - using dcpromo.exe. However one chooses to make the server a member of an existing domain instead of creating a new domain. One is then called upon to specify the full DNS name of the domain which you wish to place your domain controller.

However, since the domain cscf.uwaterloo.ca does not actually exist in IST's DNS system, the request to join the CSCF domain was rejected because the domain "could not be found" in DNS.

Ultimately, CSCF established a private DNS server for the Active Directory with dynamic update abilities on elisa, see ADDnsConfiguration. This is easy to do as there is a native DNS server which can be installed onto any Windows 2003 server using the "Add/Remove Programs" applet in the control panel. The DNS server is a Windows component. The install files are on CSCF's Startardized Windows 2003 image.

For configuring DNS, initially a single Forward Lookup Zone called uwaterloo.ca and a Reverse Lookup Zone for the 129.97.x.x subnet were created. This setup served for the initial building of the Active Directory, however more Forward Lookup Zones would be later created as outlined in ADDnsConfiguration. elisa's IP address was set as each DCs' primary DNS server. The Register with DNS option on all the DCs.

Once this was done I could use dcpromo.exe to successfully add glaciais and tt>aeshena to the CSCF domain.

Redistribution of Operational Masters Within CSCF (and other domains)

Using the following Administrator's Tools, CSCF redistributed essential Operational Master responsibilities throughout the CSCF domain. NOTE: All Operational Master roles reside on the domain controller in the domain initially (elisa).

Active Directory Domains and Trusts (for Domain Naming Master) Active Directory Sites and Services (for the Global Catalogue) Active Directory Users and Groups (for RID and Infra Master and PDC Emul.)

Operational Masters were assigned in the following manner.

elisa: PDC Emulator, RID and Infrastructure Masters glaciais: Global Catalogue ashena: Domain Namiing Master and Redundant Global Catalogue

Schema Master is on elisa by default.

Creation of Second Tree Root Domain: CS-GENERAL (cs.uwaterloo.ca)

The first DC in this domain will be intacta. elisa is made the Primary DNS server for intacta.

Again dcpromo.exe is used, except this time we are creating a new tree root domain in an existing forest. The promotion process for intacta ran smoothly.

However, when it came time to add serverus to CS-GENERAL, I encountered the exact same DNS problem I encountered while building CSCF - the domain cs.uwaterloo.ca did not really exist. This inspite of the fact that both intacta and serverus used elisa's DNS server as their primary DNS server and were configured to register to it.

As a temporary solution, I allowed for both secure and unsecure registration with the DNS server on elisa. This is a security hole which we shall have to try to repair later.

Openning up the DNS server to non-secure registration allowed intacta and serverus to register with the DNS server. serverus was now able to join the CS-GENERAL domain.

Redistribution of Operational Masters in CS-GENERAL

intacta: PDC Emulator, RID and Infrastructure Masters serverus: Global Catalogue

NOTE: In any active directory there is only one domain name master.

User and Computer Migration Into The Active Directory

Now that a functional Active Directory has been established, it is time to populate the domains with user accounts and computers. The procedure below outlines the migration from the old NT 4 domain called MFCF to the Active Directory domain CS-GENERAL (also named cs.uwaterloo.ca in DNS), but the details are equally applicable to any such migration such as from DRAGONFLY to CS-TEACHING (named student.cs.uwaterloo.ca in DNS).

Select An AD Domain Controller to Work From

Most migration operations must be handled from a domain controller in the new AD. In the case of migration from MFCF to CS-GENERAL, this job was assigned to the DC intacta but any DC in the target domain would suffice.

On intacta the Active Directory Migration Tool must be installed. It's installation files are found on the MS Windows 2003 installation CD under \ENGLISH\WIN2003_VLP\ENT\I386\ADMT. There is also a copy of this package to the swtools folder under the core share of the csappserv1 SAMBA server.

We also have to change the Default Domain Controllers group policy. This is found by accessing the Properties of the Domain Controllers OU in the Active Directory User and Computers tool. In the Group Policy window find Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options. There are a number of Network Access containers in the list on the right. Select the one named "Network Access: Enable Let Everyone permissions apply to anonymous users". Enable this option.

Also, the Everyone group must be added to the built-in group Pre-Windows 2000 Compatibility Access. To do this enter the following at the command prompt on the designated AD domain controller for migration (intacta:

net localgroup "Pre-Windows 2000 Compatible Access" Everyone /Add

Then reboot the domain controller.

Establish Two-Way Trusts Between AD Domains and Corresponding NT Domains

Both source (NT) and target (AD) domains must trust each other in order to migrate user and computer account information. In the case of migration from MFCF to CS-GENERAL, two one-way trusts have to be established such that MFCF trusts CS-GENERAL and CS-GENERAL trusts MFCF. This will have the side effect of making CS-GENERAL visible to users in the MFCF domain as a non-default domain option at logon. Hopefully, few will notice this temporary change.

Now that the trust relationship is established, Domain Admins in the CS-GENERAL domain must be given the right to read privileged security data in the MFCF domain. Hence the CS-GENERAL\Domain Admins group must be made a member of the Administrators (local) group in the MFCF domain. Since MFCF now trusts CS-GENERAL, the CS-GENERAL\Domain Admin group can be used in the MFCF domain. The MFCF domain must then synchronize (about 15 minutes).

It is also helpful to add MFCF\Domain Admins group to the local Administrators group in the CS-GENERAL domain. This can be done at this point because the CS-GENERAL now trusts MFCF.

Create A Password Server In The Source Domain

Next step is to create a password server in the MFCF NT (source) domain which will allow for the copying of account passwords with their migrating MFCF accounts to CS-GENERAL. The documentation recommends using an acting BDC in the source domain (MFCF) for this purpose. The Password Export server requires Windows NT 4.0 with Service Pack 5, or Windows 2000 with the 128-bit high-encryption pack installed.

sturgeon.math was selected in the case of migration from MFCF to CS-GENERAL.

Once the source domain Password Export server is selected, it is helpful to add an entry for this computer (sturgeon) in the lmhosts file of the computer that was selected to execute the migration operations (intacta in this case).

In the target domain (CS-GENERAL), save what is called a password file. At the command prompt on intacta, change to the drive on which ADMT is locally installed (C:). Change directories to the path on which ADMT is locally installed. Enter a command that uses the following syntax:

admt MFCF A: *

Where MFCF is the source domain name and A: implies storing the password file to a floppy disk. Although the password file can be saved to any drive, it is recommended that it be saved to a floppy disk for better security. You may substitute an actual password for the asterisk (*), using the asterisk will cause the admt to prompt for a password.

In the source domain (MFCF) on sturgeon.math, we load the password file floppy into the A: drive and run the Pwdmig.exe utility. This executable is found on the Microsoft Windows Server 2003 family CD, in the \i386\Admt directory. A copy of it is also stored on the core share of csappserv1 SAMBA server. When Pwdmig.exe is run, supply the password file password when prompted.

Now to activate the Password Export Server on sturgeon.math: In sturgeon's registry the Password Export server control is under the key, HKLM/System/CurrentControlSet/Control/Lsa. Change AllowPasswordExport:REG_DWORD entry from 0 to 1.

Reboot sturgeon.

Passwords cannot be copied with their corresponding accounts from MFCF to CS-GENERAL.

User Account Migration

The outlined process is geared to be an account copying procedure from source domain (MFCF) to target domain (CS-GENERAL). Since the target domain is not as yet in production, should anything go wrong, then all migrated (copied) accounts in the target domain (CS-GENERAL) can be simply deleted in order to attempt migration a second time.

Run the Active Directory Migration Tool in the Administrative Tools group which was installed earlier on the AD domain controller selected to handle migration (intacta in our case). Under Action menu, select User Account Migration Wizard. Following the wizard...

• Select Migrate Now.
• Specify the user account(s) you wish to migrate.
• Select the local OU where these account object are going to be placed.
  • Preferably an empty OU so as to not confuse newly migrated accounts with pre-existing accounts.
• Select Migrate Passwords and specify STURGEON as the password source domain controller.
• Make sure the Enable Target Account is selected as well as Migrate User SIDs.
  • DO NOT disable source accounts. People are still using them!
• When prompted, provide the username and password of a domain administrator in MFCF domain.
• DO NOT rename accounts and ensure group membership is fixed.
• Select Ignore Conflicting Accounts and Do Not Migrate.
• Click Finish to start migration. This process takes about 30 seconds per account.
• Migrate Now.

Computer Migration

This turns out to be a two-step process. First we use the wizard in the Active Directory Migration Tool to copy the computers' accounts to the target domain (CS-GENERAL) in much the same way user accounts are copied. This achieves computer account migration. But each individual computer still considers itself a member of the old source domain (MFCF). Therefore we must use a utility called NETDOM.EXE to remotely change a computer's domain membership from source (MFCF) to target (CS-GENERAL) domain.

NETDOM.EXE is downloadable from Microsoft at... http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE

Run the Active Directory Migration Tool in the Administrative Tools group on intacta. Under Action menu select Computer Migration Wizard. Following the wizard.

• Select Migrate Now.
• Accept default source and target domains.
• Specify the computers in source domain (MFCF) you wish to migrate.
• Select the local OU where these computer objects are going to be placed.
  • Preferably an empty OU so as to not confuse newly migrated computers with pre-existing computers.
• Do not specify any objects to translate.
• Select: Do not rename the computers.
• Select: gnore conflicting accounts and don't migrate.
• Click Finish to start migration. This process takes about 30 seconds per computer.

The copying of computer accounts will succeed but the attempts to change the computers' domain memberships will actually (or most likely) fail.

This brings us to the second part of the computer migration process. We will now use the NETDOM.EXE utility to change computer domain membership. Although computer accounts may be copied at any time, a computer must be online in order to change its domain membership. Also, since this process involves an automatic computer reboot, one should ensure the computer in question is not in use. In the source domain (MFCF), logged in as a domain administrator enter the following command.

netdom move COMPUTER_NAME /domain:CS-GENERAL /UserD:CS-GENERAL\Administrator /PasswordD:*

CS-GENERAL\Administrator is a domain administrator in the target domain. You are prompted for a password for this account. NETDOME.EXE will then proceed with switching the domain membership of the specified computer and start a countdown for the specified computer to reboot. After restart, the computer will be member of the target domain (CS-GENERAL).

Clean Up

Once migration of users and computers is complete, it is a good idea to complete the following clean-up steps.

• Terminate the two one-way trusts between the source and target domains.
• Shut down the Password Export server on sturgeon.math
  • In sturgeon's registry, reset the Password Export server key: HKLM/System/CurrentControlSet/Control/Lsa. Change AllowPasswordExport:REG_DWORD entry from 1 to 0.
  • Reboot sturgeon.math