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.

These “timebomb" issues are:

• Device passwords expiring and causing the workstations to fall off the domain without regular connectivity into the corporate network:

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.

• User password changes not functioning as they do inside the corporate LAN:

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.

Some solutions to these issues include:

• Always on VPN:

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.

Caveats:

• Setup of this system does require planning and is more complex than many VPN systems available on the market in that there are many requirements for this to be an option, such as an on-premises PKI, a Remote Access Server (RAS) and NPS server (RADIUS).

• Use Outlook Web Access (OWA) to change the password

By having the user use the password change functionality in OWA, the users can change their passwords easily via a web interface.

Caveats:

• This does not solve the issue of workstation Active Directory account password, so the machine may still lose its trust with the domain.
  
  
• This option does not update the passwords on the users’ cached accounts on the workstations, so they will have to continue to log into the workstation with their old password until the machine can sync these when in the office, while they have to log into the domain with the new passwords to gain access to resources in the internal environment.

• Change password over a standard VPN

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.

Caveats:

• There are some potential issues that can occur that prevent the users from completing the standard password update process on a standard VPN, such as if the password expires without it being changed. This is an issue because many VPNs use the Active Directory database as the list of accounts to log the users into the VPN in the first place. When this is the case, the VPN sees that the password is no longer valid and will not allow the users to login normally.
  
  
• Since the machines may not update their passwords on a standard VPN, they may lose their trusts with the domain when they reenter the corporate network at some future date.

• Use the Self-Service Password Reset (SSPR) features of Microsoft 365 to allow the users to set their passwords.

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.

Caveats:

• This option would not be able to do anything to update the machine passwords since these are not available within this system.
  
  
• This does require the organization to have the password sync process back into the internal Active Directory from Azure for the users’ password changes to take effect on the internal network.