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.
Hope this helps!
