Determining Domain Migration Strategies
Determining Domain Migration Strategies |
|
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:
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.
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 Corporation uses a Windows NT financial application that runs on a number of Windows NT servers in a resource domain
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
The implications of moving security principals can be seen by tracing what would happen if
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.
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.
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
Since security principals can be moved in Windows 2000,
If
Note that this is what would occur when SIDhistory is unavailable. SIDhistory is explained later in this chapter.
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
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.
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.
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.
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:
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.
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:
When moving global groups, this method is likely to be a large undertaking in the following instances:
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.
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.
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.
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.
