How to force password changes at next logon in Entra ID (formerly Azure AD)

Entra ID (formerly Azure AD) is the central component for identity and access management in Microsoft Azure, and by extension, Microsoft 365. Managing users and passwords for organization accounts requires understanding how Entra ID (formerly Azure AD) handles password changes, especially when accounts are synchronized from on-premises Active Directory environments.  

Forcing users to change their password at next logon is a common setting that has been used for years. However, how is this accomplished with Entra ID (formerly Azure AD) and synchronizing accounts and passwords from on-premise Active Directory? We’ll walk through how it’s done and cover any issues to be aware of.  

The reasons behind “User must change password at next logon” 

A user’s password is the first line of defense against unauthorized access. Over time, however, these passwords can become vulnerable due to phishing attacks, accidental data breaches, brute force techniques, and other forms of cyber-attack. The directive to “change password at next logon” is a proactive step, helping to ensure credentials maintain a certain level of security. 

What are some reasons why an organization would enforce this setting? Several stand out: 

1. Post-breach protocols: Changing passwords can be seen as a proactive step against credentials becoming compromised. It’s also key after a security breach, when forcing a password reset ensures compromised accounts are eliminated. 
2. Onboarding processes: When new users join, they might be given temporary passwords. Requiring a change ensures they set a password only they know. 
3. Password expiration: Periodic resets decrease the window of opportunity for unauthorized access. 
4. Helpdesk password resets: If a helpdesk technician is resetting an end user’s password, it’s best practice to force the user to change their password again at next logon so that no one but the end user knows the current password. 

Below is an example of the Active Directory Domain Services setting: User must change password at next logon. 

As an example from the Microsoft 365 SaaS environment, an admin has selected “reset password” and checked the option: Require this user to change their password when they first sign in. 

How can the process to synchronize passwords between on-premises Active Directory Domain Services and Entra ID (formerly Azure AD) be automated? 

Syncing password changes with Entra ID (formerly Azure AD)

Generally speaking, most organizations migrating to a hybrid infrastructure utilizing resources in Microsoft 365 will configure Microsoft Entra Connect (formerly Azure AD Connect). Microsoft Entra Connect (formerly Azure AD Connect) is a tool organizations use to synchronize their on-premises Active Directory Domain Services accounts to Entra ID (formerly Azure AD).  

Admins install and step through the synchronization wizard in Microsoft Entra Connect (formerly Azure AD Connect) to configure the various account and password synchronization options between the on-premises Active Directory environment and Entra ID (formerly Azure AD. 

Through Microsoft Entra Connect (formerly Azure AD Connect), password changes enforced on the on-prem AD can be reflected onto Entra ID (formerly Azure AD). However, this is where issues can arise. 

Certain scenarios, when using Microsoft Entra Connect (formerly Azure AD Connect), might surprise admins: 

• Password writeback: If “Self-service password reset” is enabled, changes made in Entra ID (formerly Azure AD) might not reflect in the on-premises AD unless “password writeback” is also enabled. 
• Authentication methods: Depending on your Entra ID (formerly Azure AD) password policy and on-premises AD settings, specific authentication methods might not immediately enforce the password change. 
• Entra ID (formerly Azure AD) password policy vs. on-premises policy: Discrepancies might exist between the two, especially if custom policies have been applied to either. It’s crucial to understand and reconcile these differences. 

Below, we see an example of an Microsoft Entra Connect (formerly Azure AD Connect) configuration with Password hash synchronization enabled, but Password writeback is disabled. However, if you’re using Specops Password Policy with Microsoft Entra Connect (formerly Azure AD Connect), we would recommend enabling password writeback here. 

The flow of forced password change

When a user is logging in for the first time, or an admin has reset the user’s password, the general practice is to ensure they change their password. Admins configure the “User must change password at next logon” option on a user’s account. This temporary password system is vital, ensuring only the rightful user knows the credentials beyond the first use, minimizing security issues with the password.

What is required for Microsoft Entra Connect (formerly Azure AD Connect) to pick up these changes properly and synchronize the forced change attribute and temporary password?

Synchronizing forced password changes with Azure

By default, the “User must change password at next logon” setting is not synced from on-prem AD to Entra ID (formerly Azure AD).  In order to enable syncing this setting, the ForcePasswordChangeOnLogOn feature needs to be set. It can be activated with Microsoft Entra Connect (formerly Azure AD Connect) using the command:

Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true

Below, we have run the PowerShell cmdlet on our Microsoft Entra Connect (formerly Azure AD Connect) server to enable the ForcePasswordChangeOnLogon setting.

However, there are several key points to understand with this process related to account synchronization:

• Simply setting the “force password change” doesn’t activate the process by itself. This will only synchronize future events where “user must change password at next logon” is set – it will not sync existing instances where this flag is set on user accounts.
• Users with the “Password never expires” attribute in AD won’t have the force password change flag activated in Entra ID (formerly Azure AD). Thus, no change prompt appears during their next Azure login.
• Newly created users in AD with the “User must change password at next logon” activated are always directed in Entra ID (formerly Azure AD) to change their password on the next login. This behavior remains unchanged, irrespective of the ForcePasswordChangeOnLogOn setting. This happens because these new users are created without any password in Entra ID (formerly Azure AD), making this feature specific only to scenarios involving admin password resets.

You can read more details from the Microsoft official documentation here: Implement password hash synchronization with Microsoft Entra Connect (formerly Azure AD Connect) sync.

A note on Entra ID (formerly Azure AD) joined workstations

There is a notable gap in Microsoft’s ecosystem as it pertains to forcing password changes at next logon: a user will never be asked to change their password when logging into or unlocking a workstation joined to Entra ID (formerly Azure AD). 

For on-prem or hybrid Azure joined workstations this is not an issue.  The user authentication is done against on prem domain AD and the user is forced to change their password (as long as the user is on network and not logging in with cached credentials):

At this step, the user clicks OK, and is presented with the Change password dialog:

For purely Entra ID (formerly Azure AD) joined machines, the user is authenticated against Azure when signing in, and Microsoft will never force a password change before logging into the workstation. We might speculate that this is a side effect of removing the change password dialog shown above from Entra ID (formerly Azure AD) Joined machines; if a user hits Ctrl+Alt+Del and selects change password, they are taken back to their login session and a Microsoft change password page is opened in their default browser.

If a user working exclusively on an Entra ID (formerly Azure AD) joined workstation does not proactively change their password, they may not be forced to until the next time they sign in on a new device.

Future points to consider

• Temporary passwords: While Azure might mandate a user change their temporary password at the next login, certain services or apps connected to Entra ID (formerly Azure AD) might not recognize the password change event and allow logging in using the temporary password. This includes Entra ID (formerly Azure AD) Joined workstations as described above.
• Password expiry duration: Azure’s default settings might differ from what an organization has set on their on-premises AD. These differing settings can lead to confusion regarding password expiration policies.
• Wider password strategy: Forcing password changes has long been a core component of password strategies for most organizations with on-premises Active Directory Domain Services environments. However, as businesses migrate from on-premises infrastructure to using SaaS solutions like Microsoft 365, they must understand how forced password resets work between accounts synchronized from on-premises and Entra ID (formerly Azure AD).

Is your Active Directory due a password health check? Run a read-only scan with our free tool, Specops Password Auditor. You’ll get a customizable report with details on breached/compromised passwords, stale/inactive user accounts, and how you comply with all the major cybersecurity regulations and stanadards.