While doing some research on whether servers with identical Sids (I.e. that have been cloned without Sysprep) propose either a security risk or an operational risk I came across the following blog entry by Mark Russinovich (Dark Lord of the Sid).
The essence of it is as follows (I love summarizing - but you should really read Mark's blog for the whole truth and some more):
Remember that unless you're using Kerberos the machine account (i.e. System account) can only authenticate as Anonymous - and Kerberos isn't an option in a workgroup scenario.
So, following that train of thought...
...identical Sids of machines become an issue if you at any point in time promote those machines to be the first DC in a new domain.
Other than that (i.e. for normal member servers) identical Sids shouldn't be of concern. Just don't promote them to be DC's in their own domain.
From the operations perspective you should still avoid cloning machines without sysprepping them first (and this is still a requirement from a strict supportability perspective as Microsoft doesn't explicitly test scenarios involving Machines with cloned Sids).
So, as Mark laments in his blog his Sysinternals utility NewSid.exe turned out to be far less useful than we all thought.
Mark's blog on the subject:http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.asp
Impact of Cloning and Virtualization on Active Directory Domain Serviceshttp://channel9.msdn.com/Events/TechEd/Europe/2010/SIA320
Yes, it's true that its not an issue for the Windows OS, but the need for the uniqueness of SID's has been accepted for so long that there is a risk that other parts of the infrastructure may now depend on that uniqueness - WSUS is a prime example of something which gets totally confused when duplicate SID's are present.
Good point, applications (3rd party or Microsoft) may indeed be expecting this.
Best practice and supportability limitation is still to Sysprep after cloning of course.
Good insight. I think I will keep using Sysprep :)