Is a new SID applied when sysprep-ping a Windows image or when deploying?

Question

My organisation currently has Windows XP (yes, I know official support for it ceases in less than 24 hours) and Windows 7 system images made with Symantec Ghost 11 that we routinely deploy to machines. A required step after deployment is to run NewSID to apply a new SID to the system. Obviously a potentially better way would be to use sysprep to make the images in the first place.

I've been reading about sysprep for both Windows XP and 7, and I see that a new SID is created at some point if you use the "/generalize" command line option. What I'd like to confirm is: Is the new SID applied to a system after deployment, i.e. if I deploy and start the image on 10 machines they will get 10 different SIDs? Also, is this true for both Windows XP and Windows 7?

Lastly, I've also read (but can't fully understand) that there are "different" kinds of SIDs. So is a new SID applied via NewSID the same as that by sysprep?

Thank you in advance for your answers.

Solution 1

From : Sysprep Command-Line Syntax

/generalize Prepares the Windows installation to be imaged. If this option is specified, all unique system information is removed from the Windows installation. The security ID (SID) resets, any system restore points are cleared, and event logs are deleted.

The next time the computer starts, the specialize configuration pass runs. A new security ID (SID) is created, and the clock for Windows activation resets, if the clock has not already been reset three times.

This means on the next reboot (after deployment!) your SID will reset. Your machines will get 10 different SID's, yes.

There are multiple kinds of SID's. Users have SID's, Machine's have SID's, there are local SID's, Domain SID's, and there are "special" SID's, but the SID's you are talking about (MachineSID) is the same in sysprep and NewSID (Machine SID)

Solution 2

There are Machine SIDs, Service SIDs, Domain SIDs, and User SIDs. NewSID and sysprep /generalize only reset Machine SIDs. Yes, those are the same Machine SIDs, and yes, sysprep changes the Machine SID after deployment.

However, changing Machine SIDs is not necessary. According to this blog entry on TechNet by Mark Russinovich:

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.

ThatGraemeGuy here on Server Fault agrees with me.

Seriously, you don't need NewSID. Microsoft has retired NewSID on the grounds that it's not necessary. The NewSID download page says, "Note: NewSID has been retired and is no longer available for download. Please see Mark Russinovich’s blog post: NewSID Retirement and the Machine SID Duplication Myth."

Sysprep still gets rid of things like those pesky registry keys that interfere with WSUS, however. Microsoft does not support cloning without sysprep.

I presume from your question that you're hoping to get rid of that NewSID step (yay!) by saying that sysprep /generalize performs the same function. This is true, but hopefully pointing out that NewSID has been unsupported since 2009 will also help you get rid of that unnecessary step in your rollout process.

Solution 3

After deployment. Common sense. If the generalization would generatea new SID, you would have to repeat it on every machine - which would sort of totally go against what the word means.

After generalize the machine is generalized and then reinitializes on next boot. So you shut down, deploy and then - the deployed images boots and generates a new SID pe machine.

Comments

[Philip]

See also: serverfault.com/questions/69144/…

[HopelessN00b]

Having said that, don't forget to do a sysprep as part of the deployment process, or your cloned machines will run into difficult-to-troubleshoot issues with WSUS and ADDS.

[Katherine Villyard]

I probably know those WSUS registry keys by heart now. ;) But yes, definitely.

[hpy]

Thanks for the detailed answer! For some reason using NewSID is still part of our organisation-wide standard operating procedure. I wonder why they don't know about what's described in your answer, but hopefully this will eventually lead to us finally deprecating the NewSID step.

[kasperd]

Using links to cite sources is great, but it is no substitute for writing a good answer. You should write your answer in a way that will remain useful even after all the links have stopped working.