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
Estimated lesson time: 30 minutes
You should use inter-forest copying when
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.
Prior to beginning an inter-forest restructure, you'll need to ensure that certain prerequisites are met in the source and destination domains.
The prerequisites for the source domains are the following:
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.
The prerequisites for the destination domain are as follows:
When using an inter-forest restructure, you should be aware of the potential problems described in the following sections.
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.
Some third-party migration tools will clone the password.
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:
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.
You can use cloning to combine multiple source groups into a single large group for consolidation purposes if required.
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.
In this lesson, you learned the following: