800 workstations on 2003 domain and every single workstation was created from the image that was not syspreped. Helpdesk guys change workstation names when they connect computers to the network, but the way I understand it it doesn’t really help as workstations keep the same SID. There are a number of policies applied to every workstation – sometimes it works, sometimes it doesn’t. We exhausted all logical troubleshooting options and the only one that I have in mind is that having the same SID on all workstation can make policies go south. If you agree with this assumption then I have a couple of questions: 1. Can you recommend some utility that can run through login script in a silent mode and generate random SID for every workstation? 2. Do you think the same SID can be an issue when applying policies centrally through GPO policy? (they are applied on a user-base, not on the workstation level)Any ideas on rectifying this situation ont he network would be appreciated.Thank you.

Interesting problem, i disagree that having the same local SID on all the workstations affects group policies...but i could be wrong.My understanding of the issues regarding the same local SID on workstations is that the local accounts would have matching SIDs, thus local accounts could be used to compromise security between workstations because they all share local SIDs. Beyond that issue, i don't know of any others.Perform some simple tests like sysprep a workstation that is known to have the GPO issue. Then see if the GPO goes away.1. Can you recommend some utility that can run through login script in a silent mode and generate random SID for every workstation?You should be able to use Sysprep and an unattended answer file.2. Do you think the same SID can be an issue when applying policies centrally through GPO policy? (they are applied on a user-base, not on the workstation level)Since you are applying to the USER, i really don't see how GPO's are affected by duplicate local SIDs, but i could be wrong.

If every user has same SID on the network does that mean that all those users have the same permisison on the network level? for example if I assign onlu john.stockton permission to his home directory them michael.jorda will have access to it because he has the same sid?

Hello, Thank you for your post here. Theoretically yes, but not in real world. The ticket, TGT and token are enrolled based on the SID of the security principal. If there are multiple users in the domain have the identical SID, they will have the same permission since they are recognized as ONE. However, in read world duplicated SID on user accounts is almost impossible in domain environment. Even if it happens, DS/KDC will detect the duplicated SID and generate Event logs. To correct the issue, you can also count on the NewSID tools to regenerate the SID for client computers. If you have any questions or concerns, please do not hesitate to let me know.

I've found a really interesting article that says that duplicate sid issue is really a myth - http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx"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 support policy will still require cloned systems to be made unique with Sysprep, no other tools"It's interesting to hear your opinion on this one.Thanks. Elijah.

1. So the way I understand it - domain user account is assigned Domain SID from DC and GPO policies are applied based on this SID. In that sense having duplicate SIDs on the machines that came from the image will never affect domain functionality such as GPO policy application. Is that correct?2. Would it be correct to say that domain MACHINE account SID is generated by the DC as well and has nothing to do with the SID generated during the workstation install?3. If both statements are corrcet then I don't understand how WSUS or SMS server can be affected by workstations having the same SID cloned from the image.Thanks.Elijah.

You are correct. A computer has a local SID created when the OS is installed, which is used as the basis for all local objects created on the computer. When the computer joins a domain it gets a domain SID, which is different and is unique in the domain. As noted in the blog linked above, opinion has recently changed about duplicate local SID values. They are no longer considered a security problem. When a user logs into the domain, they authenticate with a domain user object. This object has a domain SID (the SID of the domain plus their unique Relative ID). This has nothing to do with the local SID of the computer. In fact, when the computer starts it also authenticates to the domain with a domain computer object. This domain computer object has a domain SID that is completely different from the local SID of the computer. Richard MuellerMVP ADSI

1) Correct, but a better way view this (in my opinion) is to recognize that GPO's only apply to domain objects....A domain user account or a Domain Workstation Account in this case. A unqiue SID associated with these Domain Accounts is assumed (and almost a guaranty).2) Correct, when you join a computer to the domain an computer account is created with a unique SID given to that Domain Account.3) Possibly your (and others) ASSUMPTIONS about the situation are flawed? GPO's, WSUS and SMS (SCCM) are all different technologies, just because GPO's may not be affected does not mean another technology is unaffected. Somewhere in this thread you changed for being conerned with GPO's to these other applications (WSUS and SCCM). These are completely different concerns now.Are we assuming the WSUS doesn't use the local computer SID (as apposed to the Domain Account SID) when recording which patches are applied to which computers? Since WSUS doesn't REQUIRE the computer to be a member of a DOMAIN, why would you think that duplicate SIDs is not a issue for this technology? Actually, from a WSUS perspective the local computer SID would be a simple way to have a globally unique identifier and keep track of all changes regardless of computer name changes or domain changes for that device....just a thought. I have no specific knowledge this is the case, but seems plausible.I would research WSUS and SCCM specifically to see if these applications expect unqiue SIDs.Actually, if you read the Mark Russinovich article you posted earlier...you will find somthing to this effect in the 3rd paragraph. WSUS is affected by duplications in other "machine-specific" information, that when duplicated, causes issues in WSUS...thus Microsoft Supports SYSPREP for imaging computers. I think this proves my point.http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx

Hi Miles,i am a bit surprised that you mention NewSID, even this tool is NOT supported from Microsoft for cloned machines?Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights.

Hi,I do agree with Gunner999's comment "GPO's, WSUS and SMS (SCCM) are all different technologies, just because GPO's may not be affected does not mean another technology is unaffected."I also had faced issues in WSUS due to duplicate SIDs.Finally I had to carry out following steps on client machines..1. Stop Windows Update service 2.delete following registry values from client machine...HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate --> value:-AccountDomainSidHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate --> value:-PingIDHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate --> value:-SusClientId3. Start Windows Update service.Thank You.