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.'"
Maybe slashdot should get rid of the dupe sids, too.
I found that unless you change the SID on a computer before becoming a (virtual or otherwise) windows Domain Controller, it will cause all sorts of issues. That is, at least in windows 2000 and 2003.
I know for a fact that WSUS (Windows Server Update Services... basically a centralized patch server) would do "weird, interesting" things when two machines tried to check into WSUS with the same SID. Not sure if they've resolved the problem in later versions of WSUS...see this thread for an example: http://www.neowin.net/forum/lofiversion/index.php/t343182.html
:-)
I thought that the problem was defined as being based around locking a specific machine down with Group Policy... when two machines have the same SID, AD had a hard time distinguishing them for security reasons, much as if two users' SIDs collided...
But who am I to question the great creator of psexec and psinfo, Lord Russinovich
Here's to the crazy ones
This is coming from the same company that billed my employer to the tune of $250,000 USD in order to create a utility that would move a user profile from the old location to the new one after the user account had been moved to a new NT domain.
And then we found the moveuser.exe utility on the server resource kit and asked them what the $250,000 was for. Not that anyone who pays two hundred and fifty thousand dollars for a few lines of vbscript is smart (the phbs wanted something bonafide), but I'm just sayin'...
So if SIDs are mostly irrelevant, why bother with them at all? Why not just always have them the same number (e.g., 42)?
So the "best practice" for MS-Windows was to randomly generate UIDs to avoid user accounts on different machines from having the same UID? This would have made sense had NFS been common, where indeed duplicate UIDs are an issue. But windows does not support NFS mounts -- and SMB mounting is based on a local account on the remote machine. There must be some subtlety here, or else why has this taken years to figure out?
A ggreat deal of Microsoft security is unfortunately just like the underwear of Brittany Spears.
If it's even there at all it's needlessly complex and frilly, looks good without actually covering much and is far too easy to get around or remove completely.
The excessive complexity for no good reason of the SID and the way UIDs are implemented on that array of platforms are a good example of this.
"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.
For what it's worth, using NewSID (or some other technique to accomplish the same thing) was too much trouble to do the first time when push came to deadline and I had to crank out a few hundred WinXP workstations for the college labs. I didn't have any problems. Never gave it another thought.
http://alternatives.rzero.com/
Speaking from experience, having two machines with the same SID on a single Domain you will have issues related to the computer account in Active Directory. Remove one of these computers from the Domain and the others will experience Netlogon errors and various other issues as a result. Although NewSID may no longer be relevant due to lack of Vista/2008/7/2008R2 support, you should always sysprep /generalize to prevent these issues from occuring.
Not too sure why an MS blogger would have this stance, I've seen it numerous times (10+) with my own eyes. The fix is to either perform an offline workgroup join and generate new SID's on all but 1 affected machine, or to remove machines, NewSID all but one, and rejoin the Domain.
Microsoft is now my employer, and I have no reason to cater to the needs of the user community anymore.
If you keep throwing chairs, one day you'll break windows....
I have said this for years, glad its finally being widely accepted. My coworkers when ghosting machines would be fanatical about changing the SId's. I have a bad memory and would often forget to change them with no problems. I finally just started skipping the step of changing SID's and never had any adverse issues. When I told me coworkers about this they would rattle off a liteny of problems that I "could" encounter. After 10 years its nice to know I was right all along. So now a drum roll please...... IN YOUR FACE....MY COWORKERS!
And then we found the moveuser.exe utility on the server resource kit and asked them what the $250,000 was for. Not that anyone who pays two hundred and fifty thousand dollars for a few lines of vbscript is smart (the phbs wanted something bonafide), but I'm just sayin'...
A company was having a problem with one of their machines, so they called in this specialist. The specialist came in, examined the machine, pulled out a hammer and tapped the machine. The specialist then produced a bill for $1,000. When asked why he was charging $1000 for just tapping he machine with a hammer, the specialist replied, "You're paying for me to know where to tap the machine with the hammer."
The bill was paid.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
Very nice.
Bill Cosby did a bit, "Why is there Air?" He's well known for being a Doctor of Education, but as an undergrad he was a Physical Education major. His mock reaction to this fact, "Ha, ha. Phys. Ed. You're dumb."
He relates the story of attending a Philosophy class where the titular question is posed. He comically states his surprise at the question. Something like, "Any Phys. Ed. major can tell you that. To fill up footballs, and volley balls, and soccer balls!"
You stand in fine comedic company!
-Peter
Doesn't it bother anyone else that even Microsoft doesn't have a clue how the OS they developed works anymore? That something like this is even an issue?
A ggreat deal of Microsoft security is unfortunately just like the underwear of Brittany Spears.
GOOGLE IMAGES: britney spears commando
As a student, I worked for the CS department. It was just me and my boss, and we both had extremely limited hours. Thus, we didn't have a whole lot of time or opportunity to figure out how to do things 'the right way' whenever that would change, and just kept doing things as we had been.
This was a problem when Vista was deployed. Once we got out image to where we wanted, we would ghost it and deploy to about 60 machines. For Vista, we used a KMS (Key Management Server) which is one of the options you have for licensing large numbers of machines. In a nutshell, each machine contacts the KMS and gets a license for itself.
This was supposed to be strictly limited to volume licensing; thus, the KMS would not activate any machines until it had at least 25 different machines registered to it.
Now, ideally what would happen is that before you make your image you'd basically set Windows into a 'deployment mode' (not the technical term) where, the next time it's booted, it would go through and reinitialize everything for the machine it's on, and part of this involves generating a unique SID.
We toyed with this a bit with the time we had, but couldn't get it to a place where we were happy with the results. In particular, we had some issues with networking, IIRC, that means we would have had to go and manually setup every machine for our network.
TL;DR: All of our machines had the same SID, the KMS only say 1 unique installation even though 60 machines were connecting to it, and Vista wouldn't activate. In order to fix it, we had to change the SIDs for each machine.
So to say that duplicate SIDs are not a problem is erroneous indeed.
I had to take Golf Ball Inflation six times before I passed.
rewriting history since 2109
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.
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."
He has (numerous) honorary doctorates, but he earned his Ed.D.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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>
Not that I ever used it to generate a completely new SID, but what I did find it invaluable for was to set a machine's SID back to its old value after a re-install. This did away with the need to change the ownership on all of the user's files still on the hard drive and meant that most of the time their user profile would just keep on working as if nothing had changed.
I know, brother. I agree. Do you know what my Windows support people reply to that? "Who cares? When it breaks, just clone it again."