Lesson 3: Types of Restructure | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

Once you've planned your pristine environment, you will need to determine how you'll restructure your domain. In this lesson, you'll look at two methods for restructuring and the role of a Windows 2000 attribute called SIDhistory.

After this lesson, you will be able to

Understand the differences between an inter-forest and an intra-forest restructure.
Know how access to resources can be maintained during and after the upgrade by using inter-forest copies, intra-forest moves, and the SIDhistory attribute.

Estimated lesson time: 20 minutes

Inter- and Intra-Forest Restructures

Once you've built your pristine environment, you're ready to migrate from either an upgraded Windows 2000 domain or from an existing Windows NT domain (or both!). Windows 2000 doesn't support the ability to move a domain from one point in the forest to another. Instead, objects from one domain are copied (in an inter-forest restructure) or moved (in an intra-forest restructure) into another.

Inter-Forest Restructure

The basis of inter-forest restructuring is copying security principals from a source domain into a target domain in another forest. The source domain can either be a Windows NT 4.0 domain or a Windows 2000 forest. The original object remains unchanged and functional in the source domain. When an inter-forest restructure takes place, it's possible for the new users to use the new and the old objects during and potentially after the migration, depending on the settings used on your migration tool.

Intra-Forest Restructure

In an intra-forest restructure, objects are moved from one domain in a forest into another domain in the same forest. The source object doesn't remain in place; instead, it's moved to a new location in the forest. An intra-forest move is possible only between two Windows 2000 domains in the same forest; the target domain must be running in native mode while the source can be running in either mixed or native mode. The intra-forest restructure is most frequently performed during the later stages of a migration, to finalize a target configuration.

Here's a snapshot of how you can move users into a Windows 2000 infrastructure:

In-place upgrade of the domain. All users and resources in a domain are upgraded when the Windows NT PDC is upgraded to Windows 2000.
Inter-forest copy. The users are cloned (copied) from a source environment into a Windows 2000 native mode forest. The source can be a Windows NT domain or a Windows 2000 native or mixed-mode domain. But the Windows 2000 domain must exist in an entirely different forest from the target domain, as shown in Figure 8.9.
Intra-forest move. The users are moved from one Windows 2000 domain to another Windows 2000 domain in the same Active Directory forest, as shown in Figure 8.10.

click to view at full size.

Figure 8.9 Example of an inter-forest copy

click to view at full size.

Figure 8.10 Example of an intra-forest move

SIDhistory Property in Windows 2000

Before proceeding further on the differences between intra- and inter-forest operations, you need to learn about a special feature in Windows 2000: the SIDhistory property. As you've seen, users and groups are also known as security principal objects. Security principal objects (or security principals) are objects within Windows 2000 that can be granted or denied access to resources on a network. A given security principal has a security ID (SID) that is unique within a particular security environment. In Windows NT, a security environment operates at the domain level. In Windows 2000, the security environment operates at the forest level.

When you move or clone a Windows NT security principal, it is given a new SID that applies in the destination domain. This would mean that the security principal in the pristine Windows 2000 domain is no longer able to access resources where access control entries have the old SID value, as, for example, a user's data created by the user in his or her home folder. To resolve this problem, Windows 2000 provides a feature known as the SIDhistory property. The SIDhistory property holds the set of previous SID values held by a security principal, as shown in Figure 8.11.

click to view at full size.

Figure 8.11 Example of the SIDhistory property

Hence, when a user logs on from a Windows NT 4.0 or Windows 2000 workstation in the target domain, the created access token will hold all the user's SID values from the new domain together with the SID values from the previous domain. This token can then be used to gain access to resources that the user owned in his or her old domains as well as those in the new domain.

NOTE
In Chapters 6 and 7, you saw that an upgrade of a domain doesn't have any impact on the users or resource protection in a Windows NT environment; all the existing relationships are simply transferred into an Active Directory environment.

In the example in Figure 8.11, consider a user named Ben who is initially created in the Consultants OU in the consultancy.trainkit.microsoft.com domain and is a member of the consultants (S-1-5-21-1992757321-426260085-96743709-2506) and the architects (S-1-5-21-1992757321-426260085-96743709-1963) groups. During a restructure, the users in this domain are moved into the Press OU in the trainkit.microsoft.com domain.

The security principal object that represents the user Ben is moved into the trainkit.microsoft.com domain and given a new user SID (S-1-5-21-1185557641-648117622-903097961-1991), as shown in Figure 8.11, and group SIDs for that domain. The SIDhistory object for Ben is updated to contain the SIDs that Ben held in the consultancy.trainkit.microsoft.com domain (in other words, for the consultants and the architects), so Ben is still able to access resources in consultancy.trainkit.microsoft.com.

If Ben is subsequently copied into the migrate.microsoft.com domain, another new user SID will be created, and the SIDhistory item for Ben will now contain the following:

The user and group SID values assigned from consultancy.trainkit.microsoft.com
The user and group SID values assigned from trainkit.microsoft.com
The user and group SID values assigned from migrate.microsoft.com

SIDhistory and Windows NT 3.51

There are fundamental differences in the way Windows NT 3.51 and Windows NT 4 workstations and servers build access tokens. While Windows NT 3.51 only uses RIDs (Relative Identifiers) together with the domain SID (security identifier) of the user's logon domain, Windows NT 4 uses the full SIDs (RIDs plus domain identifiers) of all groups which the user is a member of, independent of where the group had been migrated. Since Windows NT 3.51 uses only RIDs, SIDs taken from the SIDhistory of a user are meaningless. This affects the access token built on workstations for interactive logons as well as access tokens built on a server during a network logon.

In other words, SIDhistory is not supported when you log on via a Windows NT 3.51 workstation to a Windows 2000 domain controller. As a result any users cloned from Windows NT 3.51 must log on at Windows 2000 or Windows NT 4.0 workstations if they require access to previously held resources. The matter is further complicated when you have any Windows NT 3.51 servers which need to use pass-through authentication to a Windows 2000 domain. Windows NT 3.51 servers also do not understand SIDhistory and will be unable to build the access token with the relevant SIDs for any client logging on via the Windows NT 3.51 server. The result is that unless all resources are re-ACLed, users might not be able to obtain access to their original files and folders. The only way to get around this problem would be to reset the permissions on all objects using the new group SIDS and cloned user account in the Windows 2000 domain or to upgrade all Windows NT 3.51 systems immediately afterwards.

Restructure Tools

Before proceeding with the restructure, make a list comparing the benefits and weaknesses of inter-forest vs. intra-forest migrations for your specific corporate network. In general, the inter-forest restructure is used when a parallel system is required to minimize impact on business operations and to be able to immediately switch back to the old system should anything go awry. Intra-forest restructures are generally used for post-migration work when a user might be moving from one division to another and his or her user principal is held in a different domain.

You can find several migration tools in the Microsoft Windows 2000 Server Resource Kit or download them from the Microsoft Web site. New tools are constantly being written and existing ones updated, so you should regularly connect to the Microsoft Web site to check for the latest information. You'll be using several such tools in many of the lessons in Chapter 9.

Lesson Summary

In this lesson, you learned that you can clone users from a forest to a different Windows 2000 forest by a procedure known as an inter-forest copy. The main advantage to this type of restructure is that there is minimum disruption to the existing business, and you'll have a fallback system should any major problems occur. You also learned you can move users from one domain in a forest to another domain in the same forest via a procedure known as an intra-forest move. Its main advantage is that passwords are preserved and it enables restructuring within a forest. Finally you learned that security principal objects such as users and groups have a specific SID that's used to determine the level of permission on resource objects. When a security principal is migrated to another domain, it is given a new SID. To allow access to previous resources, Active Directory maintains a SIDhistory attribute, which contains any previous SID values that the user object might have held. These are then added to the access token when it's created during logon at a Windows 2000 forest.