1.在AD里面创建一个用户或者组都会为其分配一个SID,同时也会为这些对象分配一个GUID,GUID是一个128位的字符串,一个标识符,GUID不仅在整个域里面是唯一的,并且在全世界的范围内都是唯一的,独一无二的,换句话说你找遍整个世界都找不到一模一样的两个GUID值。另外,不仅用户和组这些安全主体会被分配一个GUID,整个域内的所有对象都会被分配一个GUID,比如域控制器等。而且一旦对象被分配了GUID那么这个GUID将伴随这个对象一直到它被删掉。
 
2.SID可以被更改(一般组的SID不会更改),GUID不能被更改,对象的任何属性都可以改变,但唯独GUID不能被改变。
 
3.SID的作用主要是为对象和资源做权限控制用的。
   GUID的作用主要是为了确定对象是谁,对象在那里。GUID一般都被复制到全局编录里面。比如我们平时在AD里面查找对象的时候,实际上查的是它的GUID。
 
微软technet 原文SID VS GUID如下
SID vs. GUID
When a new domain user or group account is created, Active Directory stores the account's SID in the Object-SID (objectSID) property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that is unique not only in the enterprise but also across the world. GUIDs are assigned to every object created by Active Directory, not just User and Group objects. Each object's GUID is stored in its Object-GUID (objectGUID) property.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one 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 the user has an account somewhere in the enterprise. In fact, searching for any object by Object-GUID might be the most reliable way of finding the object you want to find. The values of other object properties can change, but the Object-GUID never changes. When an object is assigned a GUID, it keeps that value for life.
However, SIDs can sometimes change. The SID for a Group object won't change. Groups stay in the domain where they were created. But people move and when they do, their accounts can move with them. If Alice moves from North America to Europe, but stays in the same company, her account can be transferred with her. An administrator for the enterprise can simply move her User object from, say, Reskit\Noam to Reskit\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 the SID for Alice's account in Euro has a different domain identifier. The relative identifier portion of a SID is unique relative to the domain, so if the domain changes, the relative identifier also changes.
Thus when a User object moves from one domain to another, a new SID must be generated for the user account and stored in the Object-SID property. Before the new value is written to the property, the previous value is copied to another property of a User object, SID-History (sIDHistory). This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the Object-SID property and another value is added to the list of old SIDs in SID-History. When a user logs on and is successfully authenticated, the domain authentication service queries Active Directory for the all of the SIDs associated with the user—the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All of these SIDs are returned to the authentication client and are included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token, including one of the SIDs in SID-History, could allow or deny the user access.
The reason for maintaining a SID history is obvious. If you allow or deny users access to a resource 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 and adding them to others. However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter how many times the user's account domain changes. The SID-History property makes this possible. When a user changes domains, there is no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID but not the new one, the old SID is still in the user's access token, listed among the SIDs for the user's groups, and the user will be granted or denied access based on the old SID.
The reason for using 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 on resources in Active Directory. A user gains access to, say, a Group Policy object, based on one of the user's SIDs, not on the GUID for the User object.