Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
On November 3 2009, Sysinternals retired NewSID, a utility that changes a computers machine Security Identifier (machine SID). I wrote NewSID in 1997 (its original name was NTSID) because the only tool available at the time for changing machine SIDs was the Microsoft Sysprep tool, and Sysprep doesn’t support changing the SIDs of computers that have applications installed. A machine SID is a unique identifier generated by Windows Setup that Windows uses as the basis for the SIDs for administrator-defined local accounts and groups. After a user logs on to a system, they are represented by their account and group SIDs with respect to object authorization (permissions checks). If two machines have the same machine SID, then accounts or groups on those systems might have the same SID. It’s therefore obvious that having multiple computers with the same machine SID on a network poses a security risk, right? At least that’s been the conventional wisdom.
The reason that I began considering NewSID for retirement is that, although people generally reported success with it on Windows Vista, I hadn’t fully tested it myself and I got occasional reports that some Windows component would fail after NewSID was used. When I set out to look into the reports I took a step back to understand how duplicate SIDs could cause problems, a belief that I had taken on faith like everyone else. The more I thought about it, the more I became convinced that machine SID duplication – having multiple computers with the same machine SID – doesn’t pose any problem, security or otherwise. I took my conclusion to the Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue. At that point the decision to retire NewSID became obvious.
I realize that the news that it’s okay to have duplicate machine SIDs comes as a surprise to many, especially since changing SIDs on imaged systems has been a fundamental principle of image deployment since Windows NT’s inception. This blog post debunks the myth with facts by first describing the machine SID, explaining how Windows uses SIDs, and then showing that - with one exception - Windows never exposes a machine SID outside its computer, proving that it’s okay to have systems with the same machine SID. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so MIcrosoft's support policy will still require cloned systems to be made unique with Sysprep.
Windows uses SIDs to represent not just machines, but all security principals. Security principals include machines, domain computer accounts, users and security groups. Names are simply user-friendly representations for SIDs, allowing you to rename an account and not have to update access control lists (ACLs) that reference the account to reflect the change. A SID is a variable-length numeric value that consists of a structure revision number, a 48-bit identifier authority value, and a variable number of 32-bit subauthority or relative identifier (RID) values. The authority value identifies the agent that issued the SID, and this agent is typically a Windows local system or a domain. Subauthority values identify trustees relative to the issuing authority, and RIDs are simply a way for Windows to create unique SIDs based on a common base SID.
You can use the Sysinternals PsGetSid tool to view a machine’s SID by running it with no command-line arguments:
Here, the revision number is 1, the authority is 5, and there are four subauthority values. At one point during the design of Windows NT, the machine SID might have been used for network identification, so in order to assure uniqueness, the SID that Setup generates has one fixed subauthority value (21) and three randomly-generated subauthority values (the numbers following “S-1-5-21” in the output).
Even before you create the first user account on a system, Windows defines several built-in users and groups, including the Administrator and Guest accounts. Instead of generating new random SIDs for these accounts, Windows ensures their uniqueness by simply appending a per-account unique number, called a Relative Identifier (RID), to the machine SID. The RIDs for these initial accounts are predefined, so the Administrator user always has a RID of 500:
After installation, Windows assigns new local user and group accounts with RIDs starting at 1000. You can use PsGetSid to view the name of the account for a specified SID, and here you can see that the local SID that has a RID of 1000 is for the Abby account, the name of the administrator account Windows prompted me to name during setup:
In addition to these dynamically created SIDs, Windows defines a number of accounts that always have predefined SIDs, not just RIDs. One example is the Everyone group, which has the SID S-1-1-0 on every Windows system:
Another example, is the Local System account (System), which is the account in which several system processes like Session Manager (Smss.exe), the Service Control Manager (Services.exe) and Winlogon (Winlogon.exe) run:
When an account logs on to a Windows system, the Local Security Authority Subsystem (LSASS -Lsass.exe) creates a logon session and a token for the session. A token is a data structure the Windows kernel defines to represent the account and it contains the account’s SID, the SIDs of the groups that the account belongs to at the time it authenticated, and the security privileges assigned to the account and the groups. When the last token that references a logon session is deleted, LSASS deletes the logon session and the user is considered logged off. Here you can see my interactive logon session, displayed with the Sysinternals LogonSessions utility:
And here you can see a token Lsass has created for the session in Process Explorer’s handle view. Note that number following the account name, 7fdee, matches the logon session ID shown by LogonSessions:
By default, processes inherit a copy of their parent process’s token. Every process running in my interactive session, for example, has a copy of the token that they inherited originally from the Userinit.exe process, the process Winlogon creates as the first of any interactive logon. You can view the contents of a process’s token by double-clicking on the process in Process Explorer and switching to the Security page of the process properties dialog:
When one of my processes opens an operating system object, like a file or registry key, the security subsystem executes a permission check that evaluates entries in the object’s access control list (ACL) that reference a SID included in the process’s token.
A similar check happens for remote logon sessions, which are the kind created by a “net use” of a remote computer’s share. To successfully connect to a share you must authenticate to the remote system with an account known to that system. If the computer is part of a Workgroup, then the credentials you specify must be for a local account on the remote system; for a Domain-joined system, the credentials can be for a remote system’s local account or a Domain account. When you access a file on the share, the file server driver on that system uses the token from the logon session for the permission check, leveraging a mechanism called impersonation.
The Microsoft-supported way to create a Windows installation that’s ready for deployment to a group of computers is to install Windows on a reference computer and prepare the system for cloning by running the Sysprep tool. This is called generalizing the image, because when you boot an image created using this process, Sysprep specializes the installation by generating a new machine SID, triggering plug-and-play hardware detection, resetting the product activation clock, and setting other configuration data like the new computer name.
However, some IT administrators install Windows on one of their systems, install and configure applications, then use deployment tools that don’t reset the SIDs of the copies of the Windows installations. The best practice up to now has been to run a SID-resetting utility like NewSID to change SIDs. These utilities generate a new machine SID, try to find all the locations on a system, including all the file system and registry ACLs, that contain copies of the machine SID, and update them to the new SID. The reason that Microsoft doesn’t support systems modified in this way is that, unlike Sysprep, these tools don’t necessarily know about all the places where Windows stashes away references to the machine SID. The reliability and security of a system that has a mix of the old and new machine SID can’t be guaranteed.
So is having multiple computers with the same machine SID a problem? The only way it would be is if Windows ever references the machine SIDs of other computers. For example, if when you connected to a remote system, the local machine SID was transmitted to the remote one and used in permissions checks, duplicate SIDs would pose a security problem because the remote system wouldn’t be able to distinguish the SID of the inbound remote account from a local account with the same SID (where the SIDs of both accounts have the same machine SID as their base and the same RID). However as we reviewed, Windows doesn’t allow you to authenticate to another computer using an account known only to the local computer. Instead, you have to specify credentials for either an account local to the remote system or to a Domain account for a Domain the remote computer trusts. The remote computer retrieves the SIDs for a local account from its own Security Accounts Database (SAM) and for a Domain account from the Active Directory database on a Domain Controller (DC). The remote computer never references the machine SID of the connecting computer.
In other words, it’s not the SID that ultimately gates access to a computer, but an account’s user name and password: simply knowing the SID of an account on a remote system doesn’t allow you access to the computer or any resources on it. As further evidence that a SID isn’t sufficient, remember that built-in accounts like the Local System account have the same SID on every computer, something that would be a major security hole if it was.
As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.
Some articles on SID duplication, including this KB article, warn that if multiple computers have the same SID, that resources on removable media like an NTFS-formatted firewire disk can’t be secured to a local account. What they fail to mention is that permissions on removable media provide no security regardless, because a user can connect them to computers running operating systems that don’t honor NTFS permissions. Moreover, removable media tend to have default permissions that grant access to well-known SIDs, such as to the Administrators group, which are the same on all systems. That’s the fundamental rule of physical security and why Windows 7 introduced Bitlocker-to-Go, which enables you to encrypt removable storage.
The final case where SID duplication would be an issue is if a distributed application used machine SIDs to uniquely identify computers. No Microsoft software does so and using the machine SID in that way doesn’t work just for the fact that all DC’s have the same machine SID. Software that relies on unique computer identities either uses computer names or computer Domain SIDs (the SID of the computer accounts in the Domain).
It’s a little surprising that the SID duplication issue has gone unquestioned for so long, but everyone has assumed that someone else knew exactly why it was a problem. To my chagrin, NewSID has never really done anything useful and there’s no reason to miss it now that it’s retired. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep
I didn't see you respond to the WSUS issue. If machines have the same SID sometimes they will not show up in the WSUS console. Thoughts? Thanks.
WSUS is definitely confused when machines have duplicate Sids. We had a large number of pc's that were imaged without sysprep being run on the reference machine. PC1 would register with WSUS, when PC2 came up it would register it's name replacing PC1... PC3 would take the place of PC2 etc...
Running Newsid against all of the machines involved enabled them to all uniquely register and recieve updates. It sure came in handy that time.
Excellent post, Mark. Your research has answered some questions I didn't even realize I had.
@Chris: the article talks about network adapter GUIDs, not machine SIDs.
@Timothy: you're correct, I'm not suggesting not sysprepping, because there is other machine-specific state that it resets, just that the SID changing step would be optional - the only reason you might want it is to reset the machine SID on a system you plan on using to as the first DC in a new Domain.
@lyle: Again, this is a case of other unique per-machine state, not the machine SID, causing a problem - state that Sysprep resets:
Here's an (admittedly esoteric and hypothetical) scenario I'd like you to consider:
Say I create cluster with a shared storage device. I create accounts on each cluster's local SAM with access to the shared storage.
I make a couple of admin-level accounts:
....with full access to the shared storage.
Then I go and make a few service accounts with limited access to a few directories:
To set the file-permissions, I briefly activate each node and run CACLs, or whatever.
Now assume the two nodes have identical machine SIDs. Further assume that the SID for NODE1\diskadmin matches NODE2\limitedaccount.
One day, while NODE1 is active, something maps a share as CLUSTER\limiteduser. Does it get all of NODE1\adminaccess's file permissions? If so, would MS consider this a vulnerability?
Crap. MS so well sold my employer on the duplicate SID "problem," that it became company policy -- punishable if violated -- that machines will not be imaged. All the concern was supposedly based on duplicate machine SIDs causing SMS or SCCM issues.
MS, please get this word out. Maybe some of us can get part of our lives back and begin imaging systems again.
A very interesting and also very inflammatory piece of research. Whilst I agree with your premise, I think you should pause and reflect on the comments being made here. There are a lot of very intelligent and experienced people who have had different experiences based around the requirement of a unique machine SID and issues caused when unique SIDs are not used. I think Microsoft should be very careful about changing such a deeply ingrained best practice that has essentially become an industry wide best practice over the years.
Judging by what others are saying, while Windows does not seem to require a unique SID, other software depends on this uniqueness, and what is Windows without other vendor software.
I personally have not come across issues with Windows failing without needing a unique SID, but many of the Engineers I work with have and whilst your article may (and should!) potentially reign in a new era of thinking about machine SIDs, for now I would be cautious about making arbitrary changes to such deeply entrenched best practices.
Cheers, and thanks for the interesting read!
I also have to question this.
I've commonly seen an issue with a scenario where hundreds of vmware images are created from a template, this means the SID replicates with the images.
We commonly receive errors that the the computer can't communicate with the DC, the only way to fix this is to drop the computer from the domain and rejoin the image to the domain. I can't see what else would cause this aside from a SID duplication issue.
Is any regression testing going to be done and reported? Thanks for the informative article!
This is a very interesting read, thank you for the note. However, my question to you is this:
If it doesn't hurt anything to have the SID regenerated via sysprep; and from what others are saying it might pose problems with other software; is it best to recommend not doing so?
I'm working on a huge deployment and this particular piece of information will be vital in my cause to push for using sysprep. The biggest case I've been making so far has been sid generation since others in my company feel application install and everything else can be handled manually by hand (nevermind the benefits of sysprepping, nobody in the organization has ever sysprepped because A) it takes too much time, B) it requires actually knowing how Windows, drivers, and applications work and where they stand in the installation process, and C) the utilities and tools that MS provides for deployment are extremely draconian, and the documentation spotty at best).
I'm currently wading through the metric ton of information on deployment with Windows 7, MDT 2010, and AIK 2.0.
I have found if I don't sysprep or newsid to generate new SIDS for computers when imaging them, once I join these computers to the domain, after logging into the second one the first is no longer able to be logged in, then I join the first back to domain again, the second has issues logging in, not until I had ran newsid where they both usable.
I think I'll continue using sysprep and newsid.
I do not agree that is it not an issue. Years ago when I worked at Compaq, I had to work the cases that came in regarding security issues on Commercial Desktops that had been cloned without having the SIDs regenerated..
Granted I have not tested again in many years, but here is the test I used to give customers to show the security vulnerability. (The results of which may have changed over the years.)
1. Build a machine from standard OS media.
2. Set the password for the Administrator account to something simple like “123”. (On newer Operating Systems you will have to enable the account.)
3. You will need to make sure that you have network share access set to “classic authentication” and not “guest only” for network test later on.
4. Clone (image) the system without using any SID regeneration tools such as Sysprep. Load the image onto another machine to create an effective duplicate. (You should change the machine name so there will not be a name duplicate error in the workgroup.)
5. Set up both machines on a network common to both machines.
6. You should now be able to log onto each machine with the Administrator account using the password “123”. You can also test network access by browsing to the other machine’s administrative shares such as \\machine\c$.
7. Now change the password for Administrator on one of the machines so something like “abc”.
8. Test to see if you can now access the other machines administrative shares without providing a password. This can be done even after a reboot of both machines.
Back in the day – time after time – the test would show that even after the password on one of the accounts (or both) had been reset, you would still be able to get to the other machines administrative shares without typing in the remote Administrator account password.
Again it has been a while since I have run this test and things do change with subsequent operating systems but I don’t know of any significant changes to the SID mechanism since the old NT and 2000 days.
The effect of the above – if it still is an issue – is that if these clones are released to production and if a user has the ability to log into one machine as an Administrator then the user has access to all other clones via administrative shares unless other mitigating factors are in place.
With 100% certainty, I know of 3 different software that would not work properly if SID's were not unique across machines on the same LAN:
1. a licensing server that uses SID to uniquely identify windows desktops at a large manufacturing company. It will invalidate certain software if it detects two machines reporting the same hash of a SID.
2. an enterprise security software that will deny access to machines having the same SID with another machine.
3. a help desk related software that requires supported desktops to have unique SID.
There are probably many dozens, if not many hundreds of third party software that will malfunction if Microsoft suddenly promoted having duplicate SIDs.
If Microsoft has patents regarding uniquely identifying machines, whereby it allows minor hardware changes, then other software companies are going to get hurt by not being able to rely on SID anymore. Was this the plan?