One of the most critical aspects of a migration is how to move security principals (such as users, groups, and computers) from one domain to another. This can get somewhat complicated in that part of the SID for each security principal is a domain SID, which of course must be changed when moved to the new domain.

When you consider that the SIDs are used to regulate user access to resources on the network, migration must accomplish moving the users' information to the new domain while retaining their existing access to resources.

In Windows networks, user access to network resources is managed by the use of access control lists (ACLs) that specify SIDs of users and groups allowed to access the resource. For each resource (such as network shares, folders, files, printers), SIDs are applied, delineating not only which users and groups can access the resource but also the type of access that they will have, such as Read-Only permissions, Read/Write permissions, and so on.

An access token, which contains not only the user's SIDs, but also the SIDs of every group to which the user belongs, is assigned to a user at the point of logon to the network. In the process of accessing a resource, the user's SIDs are compared to the SIDs assigned to the network resource. If the ACL on the network resource indicates that the user should have the type of access requested (such as Read access), the access is granted.

By default, when you migrate a security principal from a source domain to the destination domain, the destination domain's SID becomes part of the user's SIDs; thus, although the user name remains the same, the underlying SID is different, reflecting the new domain to which the user is assigned.

Yet, in performing a migration, part of the objective is to maintain the users' existing access to network resources. To accomplish this, a history of the SIDs associated with a security principal is created (the SID history), which maintains the SIDs from the previous domain that were associated with the security principal. During network logon, in addition to the new SIDs associated with the new domain, the historic SIDs associated with the previous domain are also appended to the access token created for that user.

Inside Out: Use of SID history

Because the ACLs on network resources reference SIDs to control access, once the source accounts are no longer available because the domain is being decommissioned, the applied (source domain) SIDs in the ACLs will no longer be resolvable. Access to resources continues to work, however, because Windows Server 2003 accesses the SID history and provides name resolution. You can progressively assign the security principals defined in your new domain to these resources and clean up the SID history.