Lesson 5: Intra-Forest Restructure

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

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

Estimated lesson time: 30 minutes


When to Use an Intra-Forest Restructure

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.

Intra-Forest Restructure Prerequisites

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

Source Domain Requirements

The requirements for the source domains are as follows:

  • Source domains must be in the same Active Directory forest as the destination domain but not in the same domain.
  • Source domains must contain an empty local group that will be used for auditing purposes. The group should be named sourcedomainname$$$.
  • 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 success and failure Group Management auditing enabled on the source PDC.
  • 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.

  • Source objects must be users or security-enabled groups, computers, or OUs.
  • SIDs of the source objects must not be well-known SIDs.
  • The person performing the cloning process must have administrative privileges in the source domain.

Destination Domain Requirements

The requirements for the destination domain are the following:

  • 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.

The intra-forest migration tools can be run on the source or destination domain controllers.

Challenges of an Intra-Forest Migration

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

Objects Must Be Moved in Closed Sets

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.

Greater Associated Risk with One-Way Moves

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.

Closed Sets of Users and Global Groups

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

  1. Start with the user.
  2. The closed set contains the user, along with all the groups the user is a member of, and all the users that are members of all those groups.
  3. If users in the groups are members of other groups, or if groups contain other groups (groups can be nested only in a native-mode domain), these must be added to the closed set also.

NOTE


The exception is that the built-in groups will be exempt because they all have well-known SIDs.

Practice: Examining Closed Sets

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.

click to view at full size.

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
JessicaR Marketing
MaryM Marketing
NathanB Finance
RimaC Authors and Developers
RobM Authors and Press
WayneS Developers

Using the information in the figure and the table, answer the following questions.

  1. You would like to move BenW to another Windows 2000 domain. What else would you have to move to ensure a closed set?


  2. How many closed sets are there?


  3. List the members of the smallest closed set.


  4. List the members of the largest closed set.


  5. How would your answers to Questions 1 through 4 be affected if the global Finance group also contained the global Marketing group and WayneS?


Answers

Closed Sets and Domain Local Groups

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

  • Give the domain local groups access to resources on the domain controllers.
  • Place users and global groups from the current and trusted domains in the local groups.

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:

  • Domain controllers that have the domain local group listed as an ACL in a DACL on any resource on that domain controller
  • Other domain local groups that are listed in ACEs on the domain controllers containing the original domain local group

NOTE


An alternative is to re-ACL resources with the new SIDs.

Moving Closed Sets of Resources and Computers

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

  1. Start with the domain controller.
  2. The set contains the domain controller, along with all the domain local groups used in DACLs on the computer, and all the domain controllers that also use these groups.
  3. If the domain controllers contain DACLs listing other domain local groups, these must be added as well.

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.

Closed Sets and Migration Planning

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.

Duplicate the Source Group Structure

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.

Use Universal Groups

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:

  • Your network contains high-speed, high-bandwidth network links.
  • Your global groups contain small numbers of users and groups.
  • Network traffic won't be an issue.

Tools for Intra-Forest Migration

Tools that are useful for intra-forest restructures include ADMT, Netdom, and MoveTree. You'll be using these tools in the next chapter.

Lesson Summary

In this lesson, you learned the following:

  • The prerequisites for an intra-forest restructure.
  • When using a move operation, you need to consider the impact of moving other security principals in a closed set operation.
  • How to use parallel groups or leverage universal groups as an alternative to using an intra-forest move. Each of these has advantages and limitations that need to be carefully considered.


MCSE Training Kit (Exam 70-222. Migrating from Microsoft Windows NT 4. 0 to Microsoft Windows 2000)
MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)
ISBN: 0735612390
EAN: 2147483647
Year: 2001
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net