News

Microsoft Responds to Remote Machine Password Reset Quandary

For organizations whose employees have shifted to working remotely en masse, Microsoft has explained how the machine password reset mechanism for Windows systems works for them.

The coronavirus pandemic has meant a sudden surge in remote work in March. Employees took company laptops and PCs home, but IT preparations to support remote work scenarios may have lagged.

Organizations may have lacked virtual private network (VPN) support, which is considered a requirement by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to support remote workers. Microsoft also recently addressed how patching remote clients can be affected by the use of VPNs in terms of the potential network bandwidth drag. A somewhat unaddressed issue is business reliance on the security of home routers that likely are being used by remote workers to connect to a company network.

Machine Password Resets for Remote Workers
Microsoft described a common question it's been getting of late about machine password resets for remote workers, which is different from personal password resets. Here's the question:

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?"

The answer from Microsoft is that there won't be issues because of how the machine password reset mechanism works in Windows client devices. That process was explained 11 years ago in this Directory Services blog post, which got recently updated by Microsoft.

In essence, a client device's machine password reset mechanism is its own thing. It differs somewhat from the password reset process enacted via Active Directory.

Windows client devices are set by default to request machine password resets every 30 days, unless IT pros change that default. It's the Windows Netlogon service on client devices that initiates these machine password resets. No machine password resets are attempted if the client machine can't connect to an organization's domain controller. A problem can occur, though, when the client device can connect to an organization's domain controller but a machine password doesn't get changed for more than 60 days.

Here's how the Directory Services post described that scenario:

If the machine was unable to communicate with a domain controller, it doesn't try to change its password -- for example if it was a laptop running at home with no VPN for 4 months. If it could contact the DC but not succeed in changing its password for 60+ days, then it will have a secure channel issue.

A secure channel issue is bad, of course. It disrupts the trust relationship of the network connection.

Organizations could also see a secure channel issue with remote Windows clients if those clients have intermittent connectivity to an organization's domain controller, Microsoft admitted. Here's how that problem was expressed:

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.

Microsoft's announcement didn't offer any clues on how to address such scenarios, alas.

Domain Controller Connection is Key
In essence, machine password resets get driven by Windows client devices, not by Active Directory. The machine password reset process gets postponed automatically if a client device can't connect to an organization's domain controller, which ensures that secure channel issues don't occur.

When machine passwords do get changed, the change takes place first on the device and second on Active Directory before the machine password change process gets completed.

"We first change the password locally and then update it in Active Directory," the Directory Services Team explained. "It will not rollback the changes to the current password if it is unable to update it in Active Directory."

About the Author

Kurt Mackie is senior news producer for 1105 Media's Converge360 group.

comments powered by Disqus