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:
- The password change process on your remote worker’s PCs will kick-off at some point after the MaximumPasswordAge interval is exceeded on the PC. However, in the ‘no AD connectivity’ situation, a DC won’t be discovered/reachable. The machine password change process ‘logic’ is such that if the client can’t connect to a DC, “the process” will shut itself down before the PC’s local registry is updated with a new password - nothing changes on the client.
- When these PCs come back to the office in xxx days (or get full VPN connectivity to a DC or whatever), the password change process on the PC will “wake up” again and re-attempt the domain password change process. This time, assuming the PC will be able to find a DC, the process will complete its machine password change (and its corresponding registry update) - and then communicate that new value to the DC it found. This DC updates the password attribute of the computer object in its copy of AD, and then AD replication takes that new value out to other DCs. All will be well.
- The netlogon process on the client has been trying this, every so often, while offline - but the process always bailed-out because it couldn’t find/reach a DC.
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.
- As an FYI, here’s the doc on ports needed for full communication to AD/DCs/clients - https://support.microsoft.com/en-us/help/179442/how-to-configure-a-firewall-for-domains-and-trusts
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:
- PowerShell - from the device or remotely. This seems like the natural winner and was a breeze in testing. Take a look at Example # 3 in the docs for the remote option:
- Windows GUI – from AD and the endpoint:
- AD Users and Computers - ADUC (for the AD old-schoolers)
- To short-cut any AD replication latency/delays, you might connect this console to on a hub DC or the DC with the PDC-Emulator role (PDC-E in the image below).
- Find the device
- Right-click the computer account and select ‘Reset Account’
- AD Users and Computers - ADUC (for the AD old-schoolers)
1. AD Admin Center - ADAC
- Now, from the client, use the “Network ID Wizard” and follow the screen shots:
- You need to be signed-in to the endpoint with a local admin ID (cached creds or a local account)
- NOTE: The account you enter here in the wizard here does NOT need to be a Domain Admin - but it DOES need the AD permissions/rights to ‘join a computer to the domain’ (one aspect of which is change/reset passwords for computer objects)
- Many customers don’t have those permissions set for typical users in AD, so you might need to use some other creds than the ‘normal’ domain user
- Some customers have a service account that is used to join computers to AD – if so, this would be a good use of such a service account
- Sometimes, depending on how the computer account object was created/PC joined, the permissions on the client computer account may be restrictive.
- In that case, you may need to manually edit the ACL(s) on the existing computer account(s)
Well, there ya have it, folks … more secure channel/device password details than you can shake a stick at.
Cheers!
Hilde