Many organizations were forced to transition to a Work From Home (WFH) posture practically overnight and grapple with the numerous considerations the change brings with it. As the dust has (hopefully) started to settle and secondary and even tertiary items are being addressed, you may not be aware that there is a potential timebomb ticking away on your users' devices. This timebomb can strike when users begin returning to the workplace and have the potential to overwhelm the service desk with what is normally a minor and rare annoyance of an issue.
Workstations automatically change their passwords by default every 30 days in an Active Directory forest. When connectivity to the forest is not maintained on a reasonably consistent basis, this process can no longer occur as expected. This failure can lead to systems that become “out of sync” with the forest they are members of and result in systems that generate an error when users log onto the systems the next time they are in the corporate network. The error typically states that the trust with the parent domain has failed and must be reestablished.
In many environments, the user population has a schedule that forces them to change their passwords regularly. When these password changes occur within the corporate LAN, there is no issue since the users are all logged into the domain and the new passwords “just work” as they are supposed to in a way that the user population is used to. Unfortunately, since WFH became standard, the option of coming into the office to change the users’ passwords is no longer an option.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-map-da
Since this method of connecting a VPN to the corporate network is “always on” and based on certificates, it means that the VPN can be active before the user logs on. As a result, the user and machine passwords could be changed just as they would be when connected directly to the corporate network.
By having the user use the password change functionality in OWA, the users can change their passwords easily via a web interface.
Changing the users’ passwords over a standard VPN is easily accomplished by pressing <ctrl>-<alt<->del> and selecting to change the password from the security screen. Since the password change is still done against the domain when the user in this situation changes his or her password, this does not update the local, cached password. To update the local cache, the user should lock the console with the VPN active after the password change is complete. When the user unlocks the console with the new password, the passwords are automatically synced, and that password can be used for future logins when the system is outside of the corporate network.
While a standard VPN works for the user accounts, this option does not specifically address the machines changing their passwords, but this may happen in the background if the VPN is active most of the time.
Assuming the organization has a Microsoft 365 subscription, the SSPR is an option for changing the user’s password but it will only help with the internal Active Directory domain if passwords are being synced into the internal AD domain. This option should not have the limitation that it cannot be used after the password expires, as does the standard VPN.