Greetings! – I hope you and yours are as safe and as healthy as possible.
Due to the huge up-tick in remote workers, there has been a surge in questions/concerns around ‘stale’ device passwords/secure channel issues. Many people were simply told “Take your PC and go home, right now.” So, they unplugged their work laptop (or even PC) and left their office building in February or March - and haven’t been back to the office since. In many cases, there wasn’t any time for thorough (or any) planning of a remote access design/implementation. Some have VPN or some form of remote access but many more do not. This is the scenario we’re seeing concerns about – “My users have their PCs at home, without VPN/connectivity, for well-beyond the machine password lifetime in AD. Will there be issues when people come back in to work?”
Several of us chatted internally and decided it was a good idea to publish a post about this “no connectivity” scenario, clarifying the situation, as well as sharing a link to a thorough technical blog that has some recent updates. We also include some guidance, in case you do run into machine password issues – a nice PowerShell command to reset it, as well as a way to do this within the client UI (without needing to be a Domain Administrator).
Special thanks to Ned Pyle, Ryan Ries, Justin Turner, Sagi Vahabi, Daniel Carroll and Chunlin Xu for “helping the masses” on this one.
Scenario
“Users have their PCs at home and are without VPN/connectivity. Many are disconnected for longer than the machine password age setting in my AD. Will there be secure channel/device password issues when people come back into the office and plug back into the LAN? Will users see this at sign-in?”
The answer is “No” - and here’s why:
NOTE: There is one more BIG assumption here – that there aren’t any scripts/processes that run to delete/disable “stale” computer accounts in AD while these client devices are offline.
NOTE: The above scenario is “no connectivity to AD/DCs.” However, we have seen some issues in the past if there was ‘intermittent’ connectivity, and a DC is resolved/found, but something blocks unfettered communications to the DC (such as a firewall rule or some other connectivity issue). In that case, the client password change process may not bail-out. The local device’s registry may get updated with a new password - but the DC won’t be updated. This is rare, and not normal, but if it happens, you may be on the road to secure channel issues.
Bottom line: The device password change process (which is performed by the netlogon service on the client) – is smart enough to bail-out if it can’t find/talk to a DC and it won't change the local password.
“Ok, but what if my user’s PC lost the secure channel and the device password is out of sync with AD?”
If there are issues with PCs losing the secure channel/trust (per the screen shot above), it can be reset several ways. NETDOM.EXE (a shout-out to the ‘good ol’ days’ of NT Resource Kit tools and those books!), NLTEST.EXE and of course, PowerShell (was there any doubt?). GUI-wise, you can reset the computer account in AD then leave/re-join the domain or simply use a wizard in the Windows GUI that will reset the machine password.
Two examples:
1. AD Admin Center - ADAC
Well, there ya have it, folks … more secure channel/device password details than you can shake a stick at.
Cheers!
Hilde
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.