Using SID History to Preserve Resource Access

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The best practice for granting access to resources is to use global groups to group users, and local groups to protect resources. Place global groups into a local group to grant the members of the global group access to the resource. A global group can only contain members from its own domain. When a user is migrated between domains, any global groups to which the user belongs must also be migrated in order for users to continue to have access to resources protected by discretionary access control lists (DACLs) referring to global groups. After migrating an account and maintaining the SID history of the source domain account, when a user logs on to the target domain, both the new SID and the original SID from the SID history attribute are added to the access token of the user and determine the local group memberships of the user. The SIDs of the groups in which the user is a member are then added to the access token, together with the SID history of those groups.

Resources within the source and target domains resolve their ACLs to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL. If the resource is in the source domain and you have not run security translation, it uses the SID history of the user account to grant access.

You can also preserve the original SID for global groups and universal groups in the SID history of the global group or universal group in the target domain. Because local group memberships are based on SIDs, when you migrate the SID to the SID history of the global group or universal group in the target domain, the local group memberships of the global group or universal group are preserved automatically.

SID history is used for roaming user profile access, certification authority access, and software installation access, as well as resource access. If you are not using SID history for resource access, you still need to migrate SID history to facilitate access to those items.