Lesson 4: Inter-Forest Restructure

The cloning process copies users or groups from one domain to another. Cloning can be referred to as a copy-and-paste operation because the original object remains in the source domain. In this lesson, you'll look at the requirements for an inter-forest restructure and learn how to plan for such a restructure.

---

After this lesson, you will be able to

• Plan the inter-forest restructure for your migration.
• Ensure that a set of conditions is met prior to an inter-forest restructure.

Estimated lesson time: 30 minutes

---

When to Use an Inter-Forest Restructure

You should use inter-forest copying when

• A restructure directly from a Windows NT environment is planned.
• You need to have a fallback parallel system in place in case of any failures.
• It's vital that business processes are working 24x7 and you require minimum disruption to your environment.
• A merger is taking place and you want to migrate user accounts into a single forest in readiness for when the new corporation's users will be working in the merged company environment.

An inter-forest restructure is generally preferred to an intra-forest restructure because of the complexity of the intra-forest process and the lack of fallback in case of trouble. Hence, in a two-phased approach in which an upgrade is followed by an inter-forest restructure, you'll need to perform the upgrade of Windows NT domains into different forests, and then follow up with an inter-forest restructure of the temporary forests into the target forest. You'll need to think through this strategy carefully.

Inter-Forest Restructure Prerequisites

Prior to beginning an inter-forest restructure, you'll need to ensure that certain prerequisites are met in the source and destination domains.

Source Domain Requirements

The prerequisites for the source domains are the following:

• Source domains must be Windows NT domains or Windows 2000 domains in a different forest from the destination (target) domain.
• Source domains must contain an empty local group that will be used for auditing purposes. The group should be called sourcedomainname$$$.(For example, if your domain is called migrate, the local group would be migrate$$$ and wouldn't contain any users or groups.)
• Source domains must have auditing enabled because this process can be used to bypass security in the destination domain. If the source is a Windows 2000 PDC emulator, Audit Account Management success and failure must be enabled. If it's a Windows NT domain, you'll need to enable success and failure Group Management on the PDC.
• Source domain controllers being migrated must be Windows 2000 PDC emulators in a Windows 2000 mixed-mode or native domain or must be the PDC of a Windows NT 4.0 domain, because these domain controllers will contain the latest information for the accounts.
• Source domain controllers must have the following registry entry:

   Name: Hkey_Local_Machine\System\CurrentControlSet\Control\Lsa\TcpipClientSupport Type:  REG_DWORD Value: 0x1 

  If you need to add this setting, remember to reboot afterward.

• Source objects must be users or security-enabled groups.
• SIDs of the source objects must not be well-known SIDs. For example, all the built-in groups have well-known SIDS. (For instance, the SID S-1-2-32-544 is a well-known SID for the Administrators group.)
• The person performing the cloning process must have administrative privileges in the source domain.

Destination Domain Requirements

The prerequisites for the destination domain are as follows:

• The destination domain must be in native mode.
• The SID of the source object must not already exist in the destination domain, either as a primary SID or in the SIDhistory of an existing object in the destination domain.
• Auditing must be enabled.
• The person performing the copy process must have administrative privileges in the destination domain.
• Appropriate trust relationships with domains in the source Windows NT domain or Windows 2000 forest will need to be established if old resources are to be accessed by the cloned account.
• Migration tools must be run on the target domain controller.

Challenges of Inter-Forest Restructure

When using an inter-forest restructure, you should be aware of the potential problems described in the following sections.

All Passwords Are Reset

When using Microsoft-based tools to copy user objects from one forest to another, all passwords are reset to a blank password or an Administrator-designated password. One of the implications is that you'll need to communicate the password change to your users. If there is no communication, the help desk will be overloaded by calling to let you know that users can't log on. Hence, you might want to gain experience from a small domain inter-forest clone prior to tackling the larger ones.

NOTE

---

Some third-party migration tools will clone the password.

Resource Access with SIDhistory

When cloning a user, it is theoretically possible for the person in charge of the migration to take advantage of the fact that SIDhistory allows two different accounts to access resources in the source domain (in other words, via the user's old account and by using the SIDhistory of the new account). A few options exist that minimize this potential security breach:

• Migrate the resources in parallel with the users and delete the user accounts in the source domain immediately after resource and network access has been verified.
• As soon as the user is cloned, automate the resetting of ACLs (re-ACLing) on the resources to use the new SIDs for the migrated users. Once object access has been verified, remove the SIDhistory entries.

Inter-Forest Cloning

Using Microsoft tools such as ClonePrincipal and the Active Directory Migration Tool (ADMT), inter-forest cloning can be used only with users, global universal groups, and shared local groups. You're also given the opportunity to use the SIDhistory attribute on the users and groups if access to resources in the source domain is required.

When a user account is cloned, it's automatically made a member of the Domain Users group in the destination domain. If you clone a user's global or universal groups prior to cloning the user, the user will also be made a member of these groups. If you clone one of these groups after copying the user, the cloned user (and any other group members such as other user accounts and groups) will automatically be reinstated to the cloned version of the group, providing the user existed in the groups in the original source domain.

NOTE

---

You can use cloning to combine multiple source groups into a single large group for consolidation purposes if required.

Shared Local Groups

In a Windows NT domain, there are two types of local groups to consider: local groups on workstations or member servers, and local groups on domain controllers. You can't clone local groups on workstations and member servers. (Migrating them in a restructure is covered in Lesson 6 of this chapter.) You can, however, clone local groups on domain controllers. These are known as shared local groups because they're shared between the Windows NT PDC and all BDCs in the domain.

Cloning a shared local group works exactly like cloning global and universal groups in that the SIDhistory is retained. Once cloned into the native-mode Windows 2000 domain, they become domain local groups. However, retaining group membership is slightly more complex. One of the problems is that shared local groups are known only to the domain they reside on but can contain members from trusted domains. If you require members from trusted domains to be retained, you'll need to ensure that the destination domain has duplicated all the trust relationships connected with the source domain.

It is recommended that you use the ADMT tool initially for cloning of the shared local groups. By cloning the groups first, you'll ensure that the groups are automatically populated with members.

Lesson Summary

In this lesson, you learned the following:

• The prerequisites for an inter-forest restructure.
• All passwords are reset when cloning, and there's a potential security loophole because two different accounts will have the same access to resources in the source domain.
• You can clone only users and groups but not local groups on workstations or member servers.
• When cloning a shared local group, you might need to have the appropriate trust relationships set up in the destination domain to accommodate any trusted group members.