I'm your Clone Baby DC
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):
- The only time the Sid of a machine is referenced outside of the context of the machine itself is if the machine is promoted to be the first DC in a domain, in that case the Sid of the machine becomes the Sid of the domain.
- This should not be confused with the Sid of the computer account of the machine in AD if it is a domain member - that Sid is not related to the internal Sid of the machine.
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 Services
https://channel9.msdn.com/Events/TechEd/Europe/2010/SIA320