In my last column, I talked about strategies for performing domain reconstruction and consolidation as part of your a Windows 2000 migration and recommended inter-forest reconstruction. I ended the article promising to write about the tools that Microsoft provides to help with these consolidation efforts but, after reading your feedback, I have decided to postpone that discussion until next week. Instead, I'll talk about more of the important issues surrounding domain reconstruction.
During inter-forest reconstruction, you copy or move user, group, and computer accounts from an existing Windows NT 4.0 domain structure to a new, pristine Win2K forest. The additional hardware required in an inter-forest reconstruction adds to a migration's expense, but it ensures that you can recover from problems that can arise during the migration because the accounts in your NT 4.0 domains remain unchanged and in place. Your current NT 4.0 environment sits unaffected while you populate your Active Directory (AD), so you have ample time to test and fine-tune your Win2K implementation before decommissioning your NT domains.
SIDs, Access Tokens, and DACLs
To understand the process and challenges of moving security principals from the NT 4.0 source domains to the Win2K target domain, it's important to understand how security works in both Win2K and NT. When a Win2K or NT system creates directory objects, including users, computers, and groups, it assigns a SID to each. As part of the authentication process, the system grants access tokens to users when they log on. An access token contains the SID for a user account and the SID for all the groups that the user belongs to. When a user attempts to access a network resource, the system checks the access token against the resource’s Discretionary Access Control List (DACL), a list of SIDs that the system has granted or denied access to for the resource. For users to successfully access a network resource, their SID or the SID of the group that they're a member of must appear on the DACL.
Understanding this process is important when planning domain reconstruction because an object’s SID is specific to its domain. A SID serves as two separate IDs: a domain ID that's the same for every object in that domain and a unique ID that's specific to that object. Therefore, if you move or copy a security principal from an NT domain to a Win2K domain, its SID changes because its domain membership changes. Based on what we know about NT’s security, the object you move or copy can't access network resources that it had permission to access with its previous SID. Before Win2K, this limitation meant that moving or coping a user or group between domains involved searching the source domain and all trusting domains for references to the object's old SID and updating the DACL with the object's new SID—an impractical solution.
The Wonderful sIDHistory Attribute
Win2K security principals have an additional attribute called sIDHistory that can help you overcome the challenge of reassigning SIDs. sIDHistory stores an object's previous SID, so when users log on to a Win2K domain, the sIDHistory attribute appends to their access tokens along with new SIDs. Because group objects in Win2K also include the sIDHistory attribute, both old and new group SIDs append to the access tokens as well. Because the access tokens contain both SIDs, access is unaffected for users you move or copy when the system checks them against a resource’s DACL. You can populate the sIDHistory attribute value in Native Mode Win2K domains only, which in effect requires that all target domains be Win2K Native Mode domains. Also, the use of sIDHistory in effect doubles the number of SID entries that appear on a access token. SID entries are limited to 1023.
Next week, I'll get to the tools that Microsoft provides to help you move and copy NT 4.0 accounts to a Win2K forest while migrating and maintaining the sIDHistory attribute. Understanding these principles and processes will help you know how these tools work and grasp some important post-reconstruction tasks that we will discuss in a future article. Again, if you're planning or have begun your Win2K migration, feel free to post any questions or discoveries as responses to this article. We're still early on in the move to Win2K, and we all can learn from each others' experiences.
