As you've seen, you can move users and groups from one domain to another in the same forest. This move is sometimes referred to as a cut-and-paste operation because the source object is totally destroyed once the move operation has taken place. In this lesson, you'll examine the requirements for an intra-forest restructure and its associated challenges.
After this lesson, you will be able to
Estimated lesson time: 30 minutes
If you've upgraded all your domains into the same forest as a precursor to a restructure, you'll need to use an intra-forest move. On the other hand, if you upgrade all your domains into different forests, you'll be able to take advantage of cloning techniques but will lose the benefits of having all the systems in the same forest during the migration period.
An intra-forest restructure will also preserve a user's password and all objects' globally unique identifiers (GUIDs). This preservation will minimize help-desk calls relating to password problems and any applications that are GUID-dependent (very unlikely at this moment). In contrast, an inter-forest clone creates a new GUID for each cloned object.
Because of closed set issues, which will be discussed later in this lesson, an intra-forest move is generally considered only when there's no other way for the migration to proceed.
Prior to beginning an intra-forest restructure, you'll need to ensure that certain prerequisites are met in the source and destination domains.
The requirements for the source domains are as follows:
Name: Hkey_Local_Machine\System\CurrentControlSet\Control\Lsa\ TcpipClientSupport Type: REG_DWORD Value: 0x1
If you need to add this setting, remember to reboot.
The requirements for the destination domain are the following:
The intra-forest migration tools can be run on the source or destination domain controllers.
When using an intra-forest restructure, you should be aware of the potential problems described in the following sections.
When moving an object, for example, a user object, the group membership of a user isn't maintained when it is moved. If the lack of retention of group membership is a problem (for example, for resource access), you'll need to tell the migration utility to move any global groups to which the user belongs, along with all the members of those groups. If any member of those groups also exists in other groups, these need to be moved also until there are no further relationships with any other objects. This entire group is what is referred to as a closed set.
Essentially, the implication is that you will often be moving large numbers of users and groups. The smallest closed set might be the entire domain. Hence, you might want to gain experience from an intra-forest restructure on a small domain prior to tackling some of the larger ones.
When using intra-forest operations, the source object is deleted. Hence, without appropriate backup measures, an intra-forest operation move is a one-way operation. Should anything go wrong during the process, and, depending on the size of the migrations, there might be a substantial amount of delay to business continuity because of disaster recovery procedures.
A global group can hold members only from its own domain. In other words, when a user is moved from one domain to another in an intra-forest restructure, the new user isn't able to be a member of the original global group in the source domain. When a user is moved into a new domain, all the global groups of which the user is a member will need to be moved with it.
Moving groups via an intra-forest restructure will also preserve access because each group will have a SIDhistory attribute when moved into Windows 2000. As in the inter-forest restructure, SIDhistory will provide the original SID value for the ACLs on the resources in the source domain. A corollary is that if a global group is moved, all its members must be migrated with it.
A closed set of users and groups holds all the groups for a given user, along with all the members of those groups. In the worst case, a closed set for a given domain will be all the user accounts and global groups in the domain. A closed set represents the smallest unit that can be migrated from a domain.
Windows 2000 allows the nesting of global groups inside other global groups. If one of the groups in a closed set contains a nested group, the closed set contains all the members of the nested group as well. If the nested group contains other nested groups, these are also included in the closed set.
When considering the migration of accounts into another domain, the closed sets should be identified so that each closed set can be migrated individually. To identify a closed set containing a particular user
The exception is that the built-in groups will be exempt because they all have well-known SIDs.
In this practice, you'll examine closed sets. Look at the diagram in Figure 8.12, which lists several users and groups in the consultancy.trainkit.microsoft domain.
Figure 8.12 Users and groups in the consultancy.trainkit.microsoft.com domain
The following table summarizes the users and the groups to which they belong.
|User||Is a member of|
|BenW||Consultants and Press|
|RimaC||Authors and Developers|
|RobM||Authors and Press|
Using the information in the figure and the table, answer the following questions.
As you saw in the previous lesson, a domain local group operates only within the confines of the domain in which it is created. A standard procedure when using domain local groups is to
Moved users or global groups still retain access to a resource from the source domain because of SIDhistory and the transitive trust relationships that exist by default between Windows 2000 domains in the same forest. However, if you want to move a domain local group outside its domain, any references to the group in the DACLs on the resources will also be destroyed. As a result, any migrated users that required access to these resources via the domain local group will be denied access. To maintain access to resources, you're allowed to move domain local groups only in a closed set that's made up of the following:
An alternative is to re-ACL resources with the new SIDs.
As you can see, the term closed set has a slightly different meaning with respect to computers. A closed set of computers and shared or domain local groups is the set of computers and groups listed in all the DACLs on them. To identify a closed set containing a particular computer
Using a closed set makes it possible to migrate a set of Windows NT resource domains to an OU hierarchy in a single Windows 2000 domain.
The inclusive nature of the closed sets means that it might be difficult to identify closed sets that are smaller than your entire domain. It might be necessary to move users in and out of groups to create smaller closed sets that can then be migrated. There are two techniques you can use to ease the problem, described in the following two sections.
One way to circumvent the migration of an entire domain because of the closed set nature of the intra-forest move is to create parallel groups in the target domain that match the ones in the source. After creating the parallel groups, you can then modify the DACLs (re-ACL) on the destination and source resources to allow access to members of the new parallel groups. Re-ACLing is required, as there will be no entries in the SIDhistory attribute because you're creating the groups new.
This technique has the advantage that it can be performed and tested before the accounts are migrated, but it might be onerous to implement unless you're able to create a security template and use it with a utility such as the Microsoft Security Configuration Editor that was discussed in Lesson 3, "Security Assessment," of Chapter 3, or by using a third-party migration tool.
If the source domain is in native mode, you can use universal groups to provide access to resources across an entire forest. A universal group is visible to all the domains in a Windows 2000 forest. By converting a global group into a universal group, you can then move it into another domain without affecting its access to resources.
This technique has the advantage of being comparatively easy to implement, particularly if you're restructuring a domain that has been upgraded to Windows 2000. Once migrated, you can reconvert the universal group back to a global group.
If you use this method, be aware that the universal group's membership is held in the global catalog. Any addition or changes to the universal group will cause the global catalog to replicate the information to all the other global catalogs in the forest. If you have a global group that contains a lot of users and convert it to a universal group, the entire amount of data will be replicated to all the global catalogs throughout the forest. Any further changes made to this universal group will cause the entire group membership to once again be replicated instead of just the changes.
Therefore, the best time to use this method is in the following situations:
Tools that are useful for intra-forest restructures include ADMT, Netdom, and MoveTree. You'll be using these tools in the next chapter.
In this lesson, you learned the following: