0

Thanks to recent answers to my questions, I was able to use sysprep to create a Windows 7 system image ready for deployment in our organisation.

I learned that the process of using sysprep creates a new machine SID for the system, rendering running the newSID software unnecessary on newly deployed systems. Also, I saw Mark Russinovich's blog post that machine SIDs are no longer an issue. However, I am still a bit confused:

As one of the tech support technicians in our group, I sometimes get calls from clients whose computers would be unable to connect to our Windows domain, or can't login using their AD credentials (the error messages would be along the lines of "the domain can't be reached" etc., while other computers can).

According to one of our admins, the fault lies with duplicated computer SIDs, since the computer fails to log in because another computer with the same SID is already logged in. He said this is why sometimes a computer that fails to join the domain now would suddenly be able to join an hour later because the other, conflicting machine is off.

He would ask us to run newSID on the problematic computer to solve the issue. Interestingly, after (1) leaving the domain, (2) running newSID, then (3) re-joining the computer to our domain, the user would then be able to log in with the AD account. This appears to conflict with the blog post I mentioned which claims machine SIDs are no longer useful.

To better help my clients and to better understand how this all works I'd like to ask the following:

(1) AFAIK, newSID and sysprep both give the computer new machine SIDs. How does this machine SID play any role in the success of joining a domain or logging in to the computer with AD credentials? What happens when two systems with the same machine SID try to do it? Does the "SID conflict" our admin said has anything to do with this? Why might running newSID help?

(2) Is this issue different between Windows XP and Windows 7?

(3) Does Microsoft have any official documentation regarding all this?

Thank you in advance for your help!

hpy
  • 835
  • 3
  • 18
  • 28

2 Answers2

4

I believe your admin has some incorrect assumptions on how SIDs work in a domain environment. The machine SID does not directly correlate to the SID generated for the machine in Active Directory. The whole bit about machines not being able to login or join due to another machine being online really implies that your admin's understanding of AD is less than sound.

More than likely the issues you are seeing are due to expired machine/computer account passwords. These passwords are generated automatically in AD and rotate every 30 days. If a machine is offline during this time it will attempt to authenticate using it's old password. Users will not be able to login via these machines because AD is actively refusing to authenticate the computer account. I believe the reason the solution provided by your admin works is because the account and password are regenerated during the domain unjoin/rejoin. You can test this theory by bypassing step 2.

Alternately if you have powershell v4 available on your machines you can use the new Test-ComputerSecureChannel commandlet to check the status of the trust relationship between that machine and the domain. If powershell v4 is not available Netdom can be used as well to reset the machine password.

If your trust/authentication checks out then you could be looking at other issues with your AD, potentially replication and or issues with FSMO roles.

Machine account SIDs are still used by some Microsoft software functions (WSUS, SCCM, SCEP etc). I've also seen the machine SID used by 3rd party vendors (looking at you symantec). You can get away with not sysprepping but in this day and age with the imaging technologies available there is no reason to skip sysprepping your image.

Regarding your (2) question. There are some structure changes between Win7 and XP, but as far as I am aware there shouldn't be any fundamental changes to how the SID operates, although as I've stated some software requirements have changed.

For your 3rd question, I'd recommend reading over Microsoft's technet pages for both SIDs and also check out the Join and Authentication troubleshooting pages (also technet). If that doesn't answer all your questions I would look into picking up a book or two about the topic, LDAP and AD can really be a deep dive but the concepts behind them are a vital part of the modern IT workers knowledge set.

NPS
  • 463
  • 3
  • 10
4

How does this machine SID play any role in the success of joining a domain or logging in to the computer with AD credentials? What happens when two systems with the same machine SID try to do it? Does the "SID conflict" our admin said has anything to do with this? Why might running newSID help?

It wouldn't help. There's some other problem that's being resolved (or temporarily swept under the rug) by rejoining the domain.

The only case where this would cause problems with the domain is if the machine were a clone (with no new SID) of the first domain controller that was used to create this domain.

The SID being regenerated by NewSID is not the SID (or more accurately, sub-authority ID) of the computer object in active directory (which is where you might run into conflicts), it's the authority ID that's used for the local user account database.

Going back to the "first domain controller" - the SID authority ID from that machine becomes the authority ID of the domain; other systems which have that same SID for their local users as well would run into issues on the domain. Other than this case, there's no possible conflict - especially not one that would cause communication problems with the domain.

In other words - he's got you looking in the wrong place :)

Is this issue different between Windows XP and Windows 7?

Nope, same behavior.

Does Microsoft have any official documentation regarding all this?

That blog post is probably the best doc there is, really.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248