Slashdot Mirror
The Machine SID Duplication Myth
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.'"
I think there's an elegant, simple solution to this.
Microsoft should incorporate NewSID into the DCPROMO utility, and force generation of a new SID as part of the process of initializing a new domain (even if it means that another reboot will be required).
Since it's the only case where a DC needs to have a unique SID.
And domain creation is certainly an extra special case. Most potential DCs won't ever be used to perform the initial creation of a windows domain: in general, only 1 DC per domain is supposed to ever have that privilege over the entire lifetime of the Windows-based LAN, which usually means only 1 server per organization will actually ever need to have had a unique SID.
This surprises me. I'm not going to say he's wrong, after all the man literally wrote the book on Windows (Windows Internals from Microsoft Press, great book) but it just seems odd. We seem to have problems at work if a system is Ghosted, but not SID walked. It'll join the domain, but exhibit weird problems, like users not able to log in and such. Now maybe GhostWalk does other things too that are what really needs to be done, but it seems to just be a SID change tool.
Personally I'll keep using GhostWalk until Symantec removes it.
From the article:
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.
Is the product activation clock reset because of Sysprep, or because the SID is changed?
In other words, could NewSID be used to keep unactivated windows installations running indefinately?
<conspiracy_theory> Would that be the real reason for the NewSID retirement? What's the rush of removing the download instead of leaving it unsupported? </conspiracy_theory>