The Machine SID Duplication Myth 201
toppings writes "Microsoft Technical fellow Mark Russinovich explains why he is now retiring NewSID, which has been used by IT departments for years when deploying Windows to new systems from customized clone images. Russinovich writes: '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.' He concludes: '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. Microsoft's official policy on SID duplication will also now change and look for Sysprep to be updated in the future to skip SID generation.'"
Except for Domain Controllers.. (Score:2, Informative)
With an important caveat! (Score:5, Informative)
"As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s randomly generated by Domain setup, 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. All accounts in a Domain, including computers, users and security groups, have SIDs that are based on the Domain SID in the same way local account SIDs are based on the machine SID, but the two are unrelated."
The low ramifications of this as mentioned above may have changed post Win2K and XP. This particular caveat governed our processes as system deployment specialists for Microsoft corporate events. We had to make sure that any potential DC had a unique SID even before the machines were promoted to DC, otherwise we saw (verifiably!) many issues with Workstations failing to join the domain. I seem to recall other more esoteric issues with older Microsoft server products, but that may be delusions based on the mass hysteria we had about unique SIDs at the time.
Re:Except for Domain Controllers.. (Score:3, Informative)
Agreed...when I was reading up for one of the Server 2008 AD MCTS exams, I cloned a base VM image of Server 2008 to simulate two DCs, a file server, an IIS/application server, etc. I had to download and run NewSID because every server I joined to the domain (i.e. the "primary" DC) had problems getting joined correctly. I don't recall the specifics but Server 2008 did throw a hissy fit and I had to run NewSID on each VM prior to joining before I could do anything else.
Re:Well... it WAS a problem... (Score:5, Informative)
Did you mean the SusClientId? AFAIK this is the only identifier WSUS uses to distinguish between computers (they also don't have to be on the same domain).
On new clones you only need to delete the SusClientId key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate; the update service will take care of assigning the machine a new ID.
Re:Well... it WAS a problem... (Score:2, Informative)
It is a common misconception that duplicate SIDs create the issue where multiple PCs check in as the same PC (with a rolling name) in WSUS. The WSUS ID is in fact stored here: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate]
as the SusClientId and SusClientIdValidation keys.
It can and should be reset independently of SIDs to have PCs correctly check-in to WSUS
Re:Except for Domain Controllers.. (Score:5, Informative)
It's not for domain controllers in general it's for the very first domain controller used to initialize a brand new domain. You want to never create a new server with that same SID again. The first domain controller's SID is special, it will be used to generate the domain SID. From then on, all subsequent domain controllers promoted in the domain will have the same machine SID.
So you're good if you create the very first DC with a unique install, and clone all your other servers from an image.
As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s randomly generated by Domain setup, 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. All accounts in a Domain, including computers, users and security groups, have SIDs that are based on the Domain SID in the same way local account SIDs are based on the machine SID, but the two are unrelated.
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.
Re:Well... it WAS a problem... (Score:2, Informative)
Add Sophos enterprise to that list.
Re:Hmm... Pretty sure I ran into an issue somewher (Score:4, Informative)
You should sysprep the machines to reset their state before joining the machines. Basically, you should create a stock VM that is your disk image right after a "sysprep" and then NEVER EVER do anything with that. Clone it, complete the setup process, and join that cloned machine to the domain.
So in your case, you should have installed each VM from the ISO/CD and joined the domain, or used a first sysprepped disk image, cloned that twice, and used the two clones to join the domain.
The reason is that sysprep does the necessary work to separate two machine's identities in a more significant way than just the SID.
Microsoft's policy is you should never clone a disk image in a domain environment without first running sysprep. NewSID was just a way of doing "sysprep lite."
Re:Well... it WAS a problem... (Score:3, Informative)
Re:Well... it WAS a problem... (Score:5, Informative)
This is absolutely correct.
Identical machine SIDs and WSUS identifiers (stored in the registry) don't stop the updates from being applied...they just cause the WSUS reports to show only the details for the last cloned machine that connected.
KMS has nothing to do with SID - it's the CMID. (Score:1, Informative)
Sysprep does *many* important things, not just change the machine SID.
For example, it sets the machine up to recreate a new machine SID *and* it sets itself up to rejoin the domain, which gives it a new domain account and hence, a new domain-SID for the machine (tehnically, SID of the computer's account on the domain.)
SYSPREP also changes the CMID of the machine. It's this CMID that has to be changed for KMS to see it as a seperate computer.
http://support.microsoft.com/kb/KB974176
So, yeah. Duplicate SIDs are NOT a KMS problem, but duplicate CMIDs are. Running SYSPREP fixes it not because SYSPREP changes the SID, but because SYSPREP *also* changes the CMID.
Re:ID (Score:2, Informative)
Ignorant and inconsiderate (Score:4, Informative)
Not so much of Mark, if he doesn't want to maintain it, thats fine, it was free, I get it.
However ... this is typical of MS.
They tell us (developers) that the sid will be unique. We write software that expects this and uses the sid as a unique ID.
Now they come along and say 'naaa, its not important to be unique, use the same sid all you want, no one will notice!'
And then I have to say ... thank god for real OSes where backwards compatibility is a rule for a reason, not just because they need it to maintain compatibility. They throw corner cases to the wind and go back on something they've said for years, completely ignoring the fact that people have built things based on something they said was a requirement.
This is the forth change that will break (or potentially in this case) software I have to maintain. Two patches that remove existing functionality in the name of security with the argument that 'no one uses it that way', to which Google can clearly show to be wrong. Even better is that one of them, a change to the DHTML control breaks some of their own apps, OWA for instance.
Its fucked up when you have to find a hack via Google to fix a bug in MS software that they say doesn't effect anyone ... except everyone that uses one of their more popular clients. Their response is 'patch exchange' which breaks OTHER things.
STOP
CHANGING
BINARY
COMPATIBILITY
you worthless fucks. Yes, I'm annoyed.
Re:With an important caveat! (Score:5, Informative)
Here's what happens when a DC and member server are both cloned from the same base image with identical SIDs:
Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5516
Date: 04/11/2009
Time: 08:52:35
User: N/A
Computer: SERVER01
Description:
The computer or domain SERVER01 trusts domain TESTDOMAIN. (This may be an indirect trust.) However, SERVER01 and TESTDOMAIN have the same machine security identifier (SID). NT should be re-installed on either SERVER01 or TESTDOMAIN.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp [microsoft.com].
Re:With an important caveat! (Score:4, Informative)
NewSID changes the machine SID
Unjoining and rejoining changes the domain SID
They aren't the same thing and MS support should have told you that.
Re:Well... it WAS a problem... (Score:5, Informative)
I ran into this same issue. I've now got a batch script that runs at first logon (post-reimaging) that resets the client ID. Probably overkill at this point (the bad image that was causing this has long since been redone), but it ensure that every machine checks in with a fresh key.
net stop wuauserv /v SusClientId /f /resetauthorization /detectnow
reg delete "HKEY_LOCALMACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Windowsupdate"
net start wuauserv
wuauclt.exe
That does require a more windows update client (the old wuauclt only accepted a couple of options, including detectnow, and ignored the reset. If you typed wuauclt.exe /gogetmeabeerandasteak it wouldn't throw an error, it just looked like it ran).
There's a distinct difference between the SID and the SusClientID.