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:

Machine SID for computer DEMOSYSTEM S-1-5-21-3419697060-3810377854-678604692
DEMOSYSTEM\Administrator S-1-5-21-3419697060-3810377854-678604692-500
DEMOSYSTEM\Guest S-1-5-21-3419697060-3810377854-678604692-501
DEMOSYSTEM\CustomAccount1 S-1-5-21-3419697060-3810377854-678604692-1000
DEMOSYSTEM\CustomAccount2 S-1-5-21-3419697060-3810377854-678604692-1001

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:

SID for domain BIGDOMAIN S-1-5-21-124525095-708259637-1543119021
BIGDOMAIN\DEMOSYSTEM$ (computer account) S-1-5-21-124525095-708259637-1543119021-937822
BIGDOMAIN\JOHNSMITH  (user account) S-1-5-21-124525095-708259637-1543119021-20937

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 (10)

  1. brantgurga says:

    Nice job. I think I was already understanding the distinction, but your post confirms that understanding.

  2. David Peel says:

    "SIDs must be unique within the authority in which they are used"

    Explains it beautifully πŸ™‚

  3. Humphrey says:

    "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…

  4. Joe Tinney says:

    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.

  5. Jon Mennell says:

    Nice Explanation,

    Simple, neat, clear.

    I think general confusion occurs ragarding apps and the way they identify their clients (Nothing to do with the way Windows uses the SIDs).

    Apps likes SMS, WSUS, etc use an ID to uniquely identify clients. It is these IDs that when cloned cause problems, nothing much to do with the SID… If the SID is used as source for these IDs (as a factor, or as a whole), then changing the SID could automatically lead to a ID regeneration, and therefore problem solved, even if it isn’t a real SID problem.

    When imaging systems, even with Sysprep, Unique identifiers still have to be thouroughly inspected. Each app needing its own regisrty tweaks or file deletions (LanDesk needing the deletion of its GUID from the registry, for example, same thing with the SMS 2.0 GUID, etc). There is a greater chance that if it is a Microsoft app, sysprep will do it for you…

    Many reactions to Mark’s great can of worms post are more deployment issues relating to duplicate IDs, not SIDs…

    The real question, therefore, is how do I generate an ID for my client ? Well, the SID is supposed to be unique – huh, well I’ll use that !! It’s not an SID issue as such but when AppID=SID, then things go horribly wrong in my app…

    So the bottom line is most likely : to be safe, follow best practises & Sysprep. Also, know your apps !!!

    Thnaks for your neat post !


    IT Trainer

  6. Meitzi says:

    "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

  7. Alex says:

    Great explanation, but I would hope that any IT Pro knows that you don’t take an image of a domain joined PC πŸ™‚

  8. Exchange Issue says:

    Something to watch out for….…/dont-give-up-on-sysprep-yet

  9. R-Day5 says:

    With Meitzi's method, the sid will still be the same once deployed.

  10. Ivan says:

    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