Windows Local vs Domain SID Cloning Issues
When you install Windows a security identifier (SID) is assigned to the machine. This SID is used for local authentication purposes and is stored in the registry and used to assign ACLs to folders and files on the NTFS file system.
In a workgroup setting each computer needs to have its own unique SID. This becomes less important when joining the computer to a domain. When joined a secondary SID is assigned which is derived from the domain SID with a relative ID append.
You could potentially deploy cloned machines with the same local SID as long as you join them to the domain after they are cloned. Since domain logins will be used the local SID is insignificant for domain authentication purposes. The netlogon service will not complain of duplicate SIDs.
However you can run into an issue when setting up a new domain. I recently installed Windows Server 2008 to test out Exchange 2010 RC. Since I am using VMware ESXi I wanted to quickly deploy a domain controller and member Exchange server by cloning the base install.
After some tests I determined that when creating a new domain the domain root is assigned the local SID of the domain controller. The domain controller is given a secondary SID that is the same with a relative ID appended. This works fine until you add the member server with the same local SID to the domain. At this point you will receive netlogon errors as the domain root SID and the local SID of the member server are identical and conflict.
The best practice is to follow the Microsoft documentation and change the SID when cloning systems. You can use sysprep or newsid to do this. I understand that sometimes this isn’t possible. Just remember that the local SID of the computer that is promoted to be the first domain controller must be different than the local SID of every computer joined to the domain.
To help explain this lets walk through a demonstration. After installing Windows Server 2008 I looked up my SID with psgetsid.
Local SID: S-1-5-21-3179452221-47502888-2255943206
I went ahead and promoted this machine to be the first domain controller. I checked the local SID and used Active Directory Users and Computers with Advanced Features enabled to view the attributes on the domain root and domain controller items.
Local SID: S-1-5-21-3179452221-47502888-2255943206
Domain Root SID: S-1-5-21-3179452221-47502888-2255943206
Domain Controller SID: S-1-5-21-3179452221-47502888-2255943206-1000
I then installed another copy of Windows Server 2008, checked the SID, made it a member server.
Local SID: S-1-5-21-1145126761-3592465034-2073038063
Member Server SID: S-1-5-21-3179452221-47502888-2255943206-1003
As you can see if the second server had been a clone of the first the local SID would conflict with the domain root SID when establishing the trust relationship. The local SID just needs to be different to distinguish credentials between the resources. Since trust relationships aren’t made directly between machines cloning of member servers and clients works fine.
To finish up I then promoted the member server to a domain controller and checked the SIDs again. Notice that the local SID is changed to match the original domain controllers local SID.
Local SID: S-1-5-21-3179452221-47502888-2255943206
Domain Controller SID: S-1-5-21-3179452221-47502888-2255943206-1003