Get started Bring yourself up to speed with our introductory content.

SIDs versus GUIDs

This excerpt from "The definitive guide to Windows 2000 security" explains the difference between a globally unique identifier (GUID) and a security identifier (SID).

 Get a glimpse inside Paul Cooke's e-book "The definitive guide to Windows 2000 security" with this series of book excerpts, courtesy of Realtimepublishers.com. This excerpt is from Chapter 5, "Configuring access control." Click for the book excerpt series or get the full e-book.


SIDs versus GUIDs

So far, I've talked a lot about the uniqueness of a SID. A globally unique identifier (GUID) might seem to be the same thing. In a sense it is the same thing, all in the name of backward compatibility. Of course, the details behind this simple explanation are a little more complicated.

As I just mentioned, when a domain account or security group is created, Windows 2000 generates a SID and stores it in an attribute of the new object. In addition to the SID, another type of attribute is set for the object -- its GUID.

A GUID is a 128-bit identifier that is unique to a particular object and is generated from a unique identifier on a device, the current date and time, and a sequence number. The GUID lets any object be uniquely identified because once Windows 2000 issues a GUID, the GUID never changes, even when the object is renamed or moved. As a result, every object stored in AD is assigned a GUID. So while other attributes can change throughout the lifetime of an object, the GUID always stays the same.

However, the SID is one of those object attributes that can sometimes change. For example, let's say that you work for a large international company that has Windows 2000 domains for all of North America and another Windows 2000 domain for the Pacific Rim. After years of dedicated service and hard work, you get your dream transfer from Smallville, USA, to Hong Kong. Instead of being replaced by an all-new account, your account can simply be moved from the NorthAmerica domain into the PacificRim domain. When your account moves into a new domain, it receives a new SID. The rationale for the new SID will make sense when I talk about the structure of a SID in the next section, but for now, just keep in mind that when you move domains, you get a new SID.

After you have a new SID, you need a mechanism to access all the resources that you used to access with your old SID. The mechanism is a SID-History attribute. When your account is moved, Windows 2000 makes a copy of your old SID and stores it in another attribute of your user object before it generates your new SID. In fact, the SID-History attribute can hold multiple values so that no matter how many times your account is moved among domains, your user account object will contain all your old SIDs. Whenever you log on, your access token will hold not only your current SID and the SIDs for all the groups you're a member of but also all your old SIDs. When you access a resource, Windows 2000 will use all of these SIDs to make the necessary access control decision.

Be sure you understand the implications of the SID-History attribute and how it affects the way you grant access to users in your environment. If you directly grant a user access to an object, rather than grant access to a security group to which that user is a member, you may introduce some security issues when you move a user from one Windows 2000 domain to another in the same forest. For example, when you move the user to the new domain, you may not want them to retain access to objects in their original domain. If you routinely granted access to the user explicitly, you'd have to search every resource of the original domain for instances where the user is explicitly used in ACLs. This process is probably not something you'd ever want to do, so be safe and always use security groups for access control, not individual user accounts.

To summarize, I'll relate all of this back to SIDs versus GUIDs. NT 4.0 and earlier use SIDs to uniquely identify accounts and security groups, not GUIDs. So although SIDs seem to be a pain because they can change over time, you shouldn't abandon using them just because GUIDs appear to be (and are) superior. If you abandoned SIDs in Windows 2000 in favor of GUIDs to make access control decisions, you'd be forced to modify all the ACLs on all the resources throughout your entire enterprise! That process would be reason enough to not upgrade to Windows 2000. Thus, although GUIDs would be preferable to SIDs when making access control decisions and would eliminate the concept of SID-History, don't expect Microsoft to make that mistake anytime soon.

Click for the next excerpt in this series: Where Windows 2000 uses SIDs

Click for the book excerpt series or get the full e-book.

 

This was last published in November 2004

Dig Deeper on Windows Server storage management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close