When a new domainuser or group account is created, Active Directory stores the account's SID inthe Object-SID (objectSID) property of a User or Group object. It also assignsthe new object a globally unique identifier (GUID), which is a 128-bit valuethat is unique not only in the enterprise but also across the world. GUIDs areassigned to every object created by Active Directory, not just User and Groupobjects. Each object's GUID is stored in its Object-GUID (objectGUID) property.

ActiveDirectory uses GUIDs internally to identify objects. For example, the GUID isone of an object's properties that is published in the global catalog.Searching the global catalog for a User object's GUID will yield results if theuser has an account somewhere in the enterprise. In fact, searching for anyobject by Object-GUID might be the most reliable way of finding the object youwant to find. The values of other object properties can change, but theObject-GUID never changes. When an object is assigned a GUID, it keeps thatvalue for life.

However, SIDscan sometimes change. The SID for a Group object won't change. Groups stay inthe domain where they were created. But people move and when they do, theiraccounts can move with them. If Alice moves from North America to Europe, but staysin the same company, her account can be transferred with her. An administratorfor the enterprise can simply move her User object from, say, Reskit\Noam toReskit\Euro. If he does, the User object for Alice's account needs a new SID.The domain identifier portion of a SID issued in Noam is unique to Noam, so theSID for Alice's account in Euro has a different domain identifier. The relativeidentifier portion of a SID is unique relative to the domain, so if the domainchanges, the relative identifier also changes.

Thus when aUser object moves from one domain to another, a new SID must be generated forthe user account and stored in the Object-SID property. Before the new value iswritten to the property, the previous value is copied to another property of aUser object, SID-History (sIDHistory). This property can hold multiple values.Each time a User object moves to another domain, a new SID is generated andstored in the Object-SID property and another value is added to the list of oldSIDs in SID-History. When a user logs on and is successfully authenticated, thedomain authentication service queries Active Directory for the all of the SIDsassociated with the user—the user's current SID, the user's old SIDs, and theSIDs for the user's groups. All of these SIDs are returned to theauthentication client and are included in the user's access token. When theuser tries to gain access to a resource, any one of the SIDs in the accesstoken, including one of the SIDs in SID-History, could allow or deny the useraccess.

The reason formaintaining a SID history is obvious. If you allow or deny users access to aresource by virtue of their jobs, you should allow or deny access to a group,not an individual. This way, when users change jobs or move to other departments,you can easily adjust their access by removing them from certain groups andadding them to others. However, if you allow or deny an individual user accessto resources, you probably want that user's access to remain the same no matterhow many times the user's account domain changes. The SID-History propertymakes this possible. When a user changes domains, there is no need to changethe access control list (ACL) on any resource. If an ACL has the user's old SIDbut not the new one, the old SID is still in the user's access token, listedamong the SIDs for the user's groups, and the user will be granted or deniedaccess based on the old SID.

The reason forusing SIDs at all, and not GUIDs, is for backward compatibility.Windows NT uses SIDs to identify users and groups in ACLs on resources.You shouldn't have to change ACLs on all your resources when you upgrade,simply because someone came up with a better scheme. So, in Windows 2000,ACLs continue to identify users and groups by SID, not GIUD—even ACLs onresources in Active Directory. A user gains access to, say, a Group Policyobject, based on one of the user's SIDs, not on the GUID for the User object.

From: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsce_ctl_yicc.mspx?mfr=true