So long, and Thanks for all the Sid’s
On the retiring of the NewSid tool and the creation of Myths in IT
When working as a consultant, its not unusual to come across customers who for some reason has chosen to do things in a way that is not in accordance with established “Best Practice”.
Often the customer will tell you that it is because of some unique characteristic of his solutions and environment, and that the decision not to honor the best practice is based on previous experience of internal staff, and/or other external consultants. The rationale behind the decisions might have been true in the past , but may not be true anymore.
However- the details of the previous experience is not known, – but someone once made this decision, so it must have been based on some rational reason, – right?
The customer is sometimes unwilling to re-evaluate these decisions, and over time they can evolve into myths.
These myths strengthens the customers belief that he has unique concerns, and the result can be crippling on the customers ability to make changes in their environments and reach a higher IT maturity level.
To challenge established truths it takes a combination of competence, guts and trust that it takes a long time to establish.
To challenge an established practice adopted by the entire industry it takes the three qualities mentioned, -only in huge quantities..
So when someone was going to tell IT-Pros that they have been wasting their time creating unique machine-sid’s for years, I guess Mark Russinovich from Microsoft is one of the few who can do it.
Looking at his post The Machine SID Duplication Myth where he announces the retiring of his own NewSID tool, and reading all the comments on his findings he is getting from people , I guess It might take some patience to..
He concludes that it is not a problem to have several identical machine SID’s on the same network, since 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.
The New Best Practice
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.”
So there you go..
Read Mark Russinovich’s article here.
Aaron Margosis further clarifies the distinctions on machine vs domain sid’s on his blog
A while ago I created some scripts that others might find useful.
Today I was notified by a coworker that a database running on a VM in our test lab was acting up and that the event-log was filled with error messages like these:
