Determining Domain Migration Strategies

Previous Topic Next Topic

Examining the Implications of Restructuring Domains

After you have determined why and when you need to restructure domains, you need to examine the implications of such a restructure. The following sections describe:

Moving Security Principals

What makes domain restructure fundamentally possible is the ability to move security principals and domain controllers between domains in Windows 2000. This has a number of important implications on how security principals are identified by the system, and how access to resources is maintained. Such implications could affect your preferred approach to domain restructure.

Effect on SIDs

The domain-relative nature of SIDs has the following consequence: when you move a security principal such as a user or a group between domains, the security principal must be issued a new SID for the account in the new domain.

In the Windows NT security model, access to resources is affected by the way the operating system looks at the user access token and compares the primary SID of the user — as well as the SIDs of any groups the user is a member of — to the ACL on the resource security descriptor. Because the lists of SIDs contained in the ACL have information that can cause access to be granted or denied to the security principals identified by the SIDs, changing the SID has far-reaching implications.

The implications of changing the SID are illustrated in the following example and in Figure 10.7. Bob is an employee of Reskit Corporation and has an account in the Windows NT account domain Reskit-Acct. Bob is a member of the global group "Finance Analysts" in the same domain.

Reskit Corporation uses a Windows NT financial application that runs on a number of Windows NT servers in a resource domain Reskit-Res1. Because local groups created on the PDC are shared among all domain controllers in the domain, the servers running the application are also set up as BDCs for the domain. A shared local group "Financial Resources" has been created on the PDC and is used on the ACLs of the files used by the application. The global group "Reskit-Acct\Finance Analysts" is a member of "Reskit-Res1\Financial Resources."

Figure 10.7    Resource Access Example
Enlarge figure

Figure 10.7 Resource Access Example

Bob also has access to a file server, Fin_Files1 in the resource domain. Fin_Files1 is a Windows NT server set up as a member server. Fin_Files1 uses a local group "Finance Files" on the ACLs of files relating to Reskit-Acct\Finance Analysts, which is a member of Fin_Files1\Finance Files. Bob works on some private projects and has a directory on Fin_Files1 that is protected so that only he can access the files in that directory. This directory has an ACL that contains a single entry allowing Bob full control of the directory.

The implications of moving security principals can be seen by tracing what would happen if Reskit-Acct\Bob were moved to another domain as part of a migration involving domain restructure. In this example, Reskit-Acct has been upgraded to Windows 2000, and has joined the Windows 2000 forest as a child of the root domain reskit.com. The domain Reskit-Acct has been switched to native mode, but is restructured and its members moved to a Windows 2000 domain, called Reskit-Acct2, in another part of the forest.


note-icon

Note

This example illustrates what happens when the Windows 2000 feature known as "SIDhistory" is not available. It is important that you understand how to handle such a situation if it arises during your restructure. Note that SIDhistory is discussed later in this chapter.

Effect on Global Group Membership

Reskit-Acct\Bob is a member of the global group Reskit-Acct\Finance Analysts. Because a global group can only contain members from its own domain, moving Bob to the new domain would cause his new account to be excluded from Reskit-Acct\Finance Analysts. Bob would then lose access to valuable resources available to Reskit-Acct\Finance Analysts.

Assuming sufficient trust exists between the new domain and the resource domain, it would seem that this situation could be fixed in a number of ways.

Adding the new SID to resource ACLs

Access to resources could be maintained by adding the new SID for Bob to the ACLs on all the resources he formerly had access to as a member of Reskit-Acct\Finance Analysts. This fix would be time consuming and complicated for the following reasons:

Moving the group

Since security principals can be moved in Windows 2000, Reskit-Acct\Finance Analysts could be moved to the new domain. However, the ACLs referencing the group also reference the group SID, so the resources would have to be repermissioned to refer to the new SID.

Creating a "parallel" group in the target domain

If Reskit-Acct\Finance Analysts is moved to another domain, a problem would occur if all the group members are not moved in one transaction. This would mean that the group would have to be maintained in the old domain, and a new "parallel" group created in the new domain. Resource access would be maintained for the original group and its members, but resources would need to be repermissioned to grant access to the new group. Again, repermissioning would have to continue while the groups existed in both domains.

Note that this is what would occur when SIDhistory is unavailable. SIDhistory is explained later in this chapter.

Effect on ACLs Directly Referencing the User

Reskit-Acct\Bob is also granted direct access to some resources on the member server Fin_Files, because his SID appears on ACLs on that server. It is perfectly legitimate to add users to ACLs on resources, but moving Reskit-Acct\Bob would require repermissioning resources on that server. This would add the new domain SID to Bob's account.

SIDhistory

In many instances, the activities in the Reskit Corporation example have become unnecessary due to a Windows 2000 feature called SIDhistory. SIDhistory is an attribute of Active Directory security principals, and is used to store the former SIDs of moved objects such as users and security groups.

When a user is moved using Windows 2000 utilities provided by Microsoft, the SIDhistory attribute of the user object in Active Directory is updated with the former SID. When the user then logs onto the system, the system retrieves the entries in the user SIDhistory and adds them to the user access token. Because groups can be moved, the system also retrieves the SIDhistory attributes of all the groups the user is a member of and adds these to the user access token.

The SIDhistory entries in the token appear to the system like normal group memberships during authorization checks, and can grant appropriate access even on pre–Windows 2000 systems that know nothing about Windows 2000 or Active Directory. Figure 10.8 shows how resource access is granted using SIDhistory.

Figure 10.8    Resource Access Granted Through SIDhistory
Enlarge figure

Figure 10.8 Resource Access Granted Through SIDhistory

Windows NT 3.51 and SIDhistory

There is an issue concerning group membership and the use of Windows NT 3.51 systems in Windows 2000 domains. The issue involves the way Windows NT 3.51 receives group membership SIDs from the domain controller and builds a security access token. When a user is authenticated, the Windows NT 3.51 access token is built using only SIDs relative to the user account domain and the local groups from the server or client where authentication takes place. The result is that Windows NT 3.51 systems cannot recognize universal groups from outside the account domain, or domain local groups from the resource domain.

Since entries from the SIDhistory of the user or any universal groups of which the user is a member are from domains other than the account domain, these entries are excluded from the token. The implication is that with Windows NT 3.51, group membership SIDs from domains other than the account domain of the user logging on are ignored when evaluated for access control. In most cases, access is denied, though this might not be the desired result.

Moving Users and Global Groups

Because a global group can only contain members from its own domain, when a user moves between domains, any global groups of which the user is a member must also be moved. This must occur to maintain access to resources protected by ACLs that refer to global groups. A corollary of this is that if a global group is moved, its members must also be moved.

In this instance, a closed set of users and global groups is a set in which the following is true:

If the source domain is a native mode domain, global groups can also contain other global groups. This means all of the members of each nested group and all of the global groups that have members in that nested group must be moved.

Moving Profiles and SIDhistory

When formulating your domain restructure plan, you must be aware that migrated users receive new SIDs and this can affect their profile use. Users logging onto their computers after migration could lose access to their logon profiles, because their primary SIDs will have changed while their old profiles might still be stored under their old primary SIDs. This could occur under the following circumstances:

If users lose access to their logon profiles, you have two options for making a profile available to a migrated user: copying profiles or sharing profiles. The preferred method is to copy the profiles.

Copying Profiles

The first option is to copy the original profile from its current location under the key named after the user's original SID to a key named after the user's new SID. Each account is associated with its own separate copy of the profile. Updates to one are not reflected in the other.

The advantage of using this method is that the behavior of Windows 2000 is more predictable. Because data is not shared between the profiles, there is no chance of one profile accessing an account with data appropriate only for another account in another domain or forest.

The disadvantages of using this method include that it:

Sharing Profiles

This option make the same profile available to both the user's original account and the new account. Under these circumstances, one copy of the profile is accessed and updated by both accounts. The advantages of using this method include:

The disadvantage of using this method is that there are unknown variables that could impact its use. For example, if you create a new Windows 2000 account profile that contains Group Policy references, you will need to test the impact of falling back to a source account where Group Policy is different or has not been used.

Moving Computers

Because shared local groups and domain local groups only have scope within the domain in which they were created, moving such a group would leave unresolvable any references to the group in the source domain ACLs.

In this instance a closed set of computers and shared or domain local groups is a set in which the following exists:

Restrictions on moving populated global groups and closed sets are particularly strict. Depopulating and repopulating large global groups can be time consuming. In some cases, the smallest closed set that can be achieved is the entire source domain. Three possible ways to solve this problem include:

  1. Creating parallel global groups in the target domain for each group to be moved, then finding all resources in the enterprise containing ACLs referencing the original group and repermissioning them to include reference to the parallel group.

    When moving global groups, this method is likely to be a large undertaking in the following instances:

  2. Switching the source domain to native mode, then changing the group type of the groups to be moved to universal. Because universal groups have scope across the entire forest, changing the groups to universal groups means that they can be moved safely while still maintaining access to resources left behind.

    Be careful when using this method, because universal group membership is stored in the GC, which has implications for GC replication traffic. For this reason, you might want to use this method strictly as a transitional strategy while users and groups are being migrated to the new domain. After migration is complete, you can change the groups back to their original types.

  3. Cloning groups from the source domain into the target domain while retaining their SIDhistory. This technique has some constraints, and is described in "Cloning Security Principals" later in this chapter.

Moving Member Servers

In the example, Bob has access to some resources on the member server Fin_Files1 through ACLs referencing a computer local group Fin_Files1\Finance Files, and referencing his domain account directly.

The implications of moving domain controllers, including the need to ensure that shared local groups and domain local groups are maintained, have been described earlier in this chapter. However, those implications are different from the ones involved in moving a member server such as Fin_Files or a client.

Assuming the member server is moved to a domain with trust to the new account domain for Bob, SIDhistory would ensure that Bob could access resources with ACLs referencing him directly. ACLs referencing the computer local group would also continue to function because the group exists in the account database of the local computer. This means that the group is unaffected by the move, so its SID would not need to be changed.

Establishing Trusts

During domain upgrade it is assumed that sufficient trust existed from the target domain to any relevant resource domains, so that access to resources is maintained. However, such trusts must first be established in any domain restructure scenario.

Netdom is a tool used to carry out such tasks as enumerating domain trusts and establishing new trusts. This tool is also useful for creating computer accounts and updating the domain membership of a client or server.

Cloning Security Principals

Up to this point, restructure has been involved with moving security principals. Moving security principals creates a new identical account in a destination domain and removes the account from the source domain. The move operation does not allow a return to the old account status if there are problems with the migration.

To ensure that you can recover from problems during the pilot project or production migration, it is recommended that you migrate users incrementally to a Windows 2000 domain while maintaining the old accounts in the source domain. This is possible through cloning, which is creating a duplicate user or group through the use of the ClonePrincipal utility, which contains a set of Microsoft® Visual Basic® (VB) scripts that perform tasks such as cloning global groups and cloning users.

© 1985-2000 Microsoft Corporation. All rights reserved.