Machine SIDs and Domain SIDs

Microsoft Technical Fellow Mark Russinovich’s recent post “The Machine SID Duplication Myth” confused many readers who didn’t understand the distinction between the two independent SIDs that belong to a domain-joined computer.  I’ll take a crack at trying to clarify that.

Machine and domain SIDs consist of a base SID and a Relative ID (RID) that is appended to the base SID.  Think of the base SID by itself as identifying an authority within which accounts and groups can be defined.  A computer is an authority within which local accounts and groups are defined.  The computer has a machine SID, and the local accounts and groups have SIDs consisting of that machine SID plus a RID.  For example:

SIDs (not names) are what are stored in access tokens associated with running code and in security descriptors associated with securable objects, and are what are compared by the security subsystem when performing access checks.

On a workgroup system, local accounts and groups are all there are.  Mark’s assertion is that authentication to a remote system using a local account requires a user name and password known to the remote system, and that SIDs are not used.  The only way anything resembling single sign on happens with local accounts is that if the remote system has the same user name and password that the caller is using.  SIDs are not transmitted and are not used for remote authentication.

If the computer is joined to a domain, then another SID comes into play.  The computer still has its own machine SID and its own local accounts and groups.  But it is also a member of a domain, and so it has a SID representing its computer account within that domain.  The domain is an authority within which accounts and groups (and other entities) can be defined – including computer accounts:

DEMOSYSTEM now has two separate SIDs:

• the machine SID which identifies it (locally) as an authority within which accounts and groups are defined (first row in the first table above); and
• the computer account SID within the BIGDOMAIN domain (second row in the second table).

You can see the machine SID on your computer by running Sysinternals PsGetSid with no parameters.  You can see the second SID on a domain-joined system by passing PsGetSid the computer name followed by a $:  psgetsid %COMPUTERNAME%$

Mark’s point is that SIDs must be unique within the authority in which they are used.  So while DEMOSYSTEM must have only one local account with the SID S-1-5-21-3419697060-3810377854-678604692-1000, it doesn’t matter if another computer uses the same SID to refer to a local account of its own.  However, within the BIGDOMAIN domain, there must be only one computer account with the SID S-1-5-21-124525095-708259637-1543119021-937822.  If multiple computers in the domain try to share that computer SID within the domain, problems will occur.  So while it’s OK to clone a system before it joins a domain, doing so after it joins a domain (and is assigned a domain computer account and a corresponding domain SID) will cause problems.

Aug 6 2012: Late edit, but here's another related post on this subject, authored by Michael Murgolo: Sysprep, Machine SIDs and Other Myths.

Hope this helps!

Comments

• Anonymous
  November 04, 2009
  Nice job. I think I was already understanding the distinction, but your post confirms that understanding.

• Anonymous
  November 05, 2009
  "SIDs must be unique within the authority in which they are used" Explains it beautifully :-)

• Anonymous
  November 05, 2009
  "So while it’s OK to clone a system before it joins a domain, doing so after it joins a domain (and is assigned a domain computer account and a corresponding domain SID) will cause problems." so...its almost like the resource kit recommendation for using sysprep when deploying an OS is to make sure the possible problems wont occur? I just read chapter 3 of the windows 7 resource kit... I hv been using sysprep, ghostwalker and newsid for years now...because i didnt really question why it was needed. The explanation about the SID is excellent tho...

• Anonymous
  November 05, 2009
  Great explanation, Aaron. I think where most people struggle is in understanding that the OS and domain infrastructure itself do not require that the machine SID be unique across the infrastructure in order to maintain security and base functionality. It has been reported that many non-OS applications expect the SID to be unique like Terminal Server Licensing, MS SCCM, Symantec Antivirus, etc. This issue also becomes muddier by cloning and the duplication of other 'unique ids' like the SUSClientId and GUID used by network hardware, etc. It is very important that people understand the full (and quite specific) scope of what Mark is trying to point out. It is still best practice to use Sysprep when imaging machines as it solves the problems mentioned above: SUSClientID, Plug and Play hardware GUIDs, machine SID, domain SID, etc. Thanks again for putting this out there.

• Anonymous
  November 27, 2009
  The comment has been removed

• Anonymous
  January 07, 2010
  "OK to clone a system before it joins a domain, doing so after it joins a domain (and is assigned a domain computer account and a corresponding domain SID) will cause problems." I disagree. You can clone domain computer by this step:

1. Clone domain joined computer
2. Start cloned computer without network
3. Remove it from domain (make more clones if needed)
4. Restart, rename
5. Join domain

• Anonymous
  April 15, 2010
  Great explanation, but I would hope that any IT Pro knows that you don't take an image of a domain joined PC :-)

• Anonymous
  December 06, 2010
  Something to watch out for.... blog.schertz.name/.../dont-give-up-on-sysprep-yet

• Anonymous
  November 06, 2014
  With Meitzi's method, the sid will still be the same once deployed.

• Anonymous
  March 24, 2015
  The machine's local SID is still important, when you promoting a computer as a DC. So unless it's unique, you may end up having several DCs with the same SID

• Anonymous
  April 07, 2017
  Just read this article after reading Mark's page on this. Can I ask a favour of you? Can I send you my SysInternals books by Mark, and have you make comments after every page so that I can understand what he's talking about? :)[Aaron Margosis] LOL!