Anyone in IT who sets up computers knows Sysprep, which strips the computer-specific information from a base system before cloning or imaging (duplicating) that system. That way, you can create a customized image to use over and over again. Although Microsoft does not provide support for computers set up with tools other than Sysprep, the reality is that many system administrators don't use it, due to the difficulties of working with an answer file, which is required to respond to machine-specific questions that arise when the imaged PC is booted and its individual attributes need to be loaded.
Instead, admins often choose third-party prep tools that work with their imaging product. For example, if you use Symantec's Norton Ghost to image your PCs, you'd likely use Symantec's Ghost Walker to change the SID and prep the machine for imaging.
But these third-party applications will change the SID in most -- but not all -- locations because they don't know where all the SIDs are buried in the OS. The result: a PC with two SIDs, one that's unique to that PC and another that's shared by all PCs (the SID from the default image that didn't get changed on each PC). That explains why Microsoft's support extends to PCs imaged with its own Sysprep tool.
But is having multiple PCs with the same SID really a problem?
An experienced administrator will say "absolutely!" and describe all sorts of scenarios in which the existence of two systems with the same SID could create a black hole that swallows up the planet. They've taken on faith what we all have accepted for years: Duplicate SIDs are the highest form of evil.
Even Mark Russinovich, a software engineer and author who works for Microsoft as a technical fellow, believed that multiple machines with the same SID on the same network would pose a security risk. In fact, he created a tool in 1997 called NewSID (aka NTSID) that fixed the problem post-imaging. If you had a cloned or imaged system and needed to change the SID, you would run the NewSID tool and save yourself from security breaches of epic proportions.
But oddly, NewSID has been retired. Certainly, Russinovich is a busy fellow, so maybe he couldn't keep up with tool development, but surely someone else would have stepped in, given the reputed dangers of duplicate SIDs on the network.
It turns out that SIDs aren't that simple. A SID is actually a collection of IDs: for user accounts, groups, and the machine itself. It's used to manage security by providing distinct IDs for distinct roles. Russinovich explains all this beautifully in his blog post, "NewSID Retirement and the Macine SID Duplication Myth." The bottom line is that the only way a duplicated machine ID would cause a problem is if "Windows ever references the machine SIDs of other computers," he notes.
But Windows doesn't do that. When you try to connect to another computer, Windows doesn't allow authentication based on the SID of the connecting computer, nor does it reference that SID. Instead, it either looks at its own local Security Accounts Database and allows for remote authentication using a local account on that remote system or it checks to see if that other computer is tied to a domain. If it's the latter, it determines whether the user has a domain account with permissions or if the domain is one the system is set up to trust.
Therefore, the SID, duplicated or not, is not the huge security hole we all believe it to be. The username and password are the keys, not the machine SID. The one exception mentioned in Russinovich's post involves domain controllers. Domain controllers get a domain SID, and machine SIDs for domain controllers match their domain SID. Thus, in that situation, the SID is referenced by other systems. However, from an authentication perspective, it still uses the computer account in the domain for the identity when authenticating remotely.
I encourage you to read not only Russinovich's posts but the reader comments as well. If you are thinking, "But ... but ... what if ... ?" you can rest assured everyone else is feeling the same way. It's like a fundamental truth has been shattered.
Despite this myth-shattering turn, I'm not suggesting that you don't use Sysprep. Regardless of the overblown security issue, the fact remains that Sysprep resets many different internal aspects of a system and is required for support by Microsoft. Without it, you may have problems with certain applications functioning properly. Yes, Sysprep can be a pain to use, but you can get past that.
This article, "The SID debate: To Sysprep or not to Sysprep," was originall published at InfoWorld.com. Follow J. Peter Bruzzese's insights on managing Windows servers and PCs in InfoWorld.com's Enterprise Windows blog.