How to force password changes at next logon in Azure AD
Azure AD (soon to be Entra ID) 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 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 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:
- 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.
- Onboarding processes: When new users join, they might be given temporary passwords. Requiring a change ensures they set a password only they know.
- Password expiration: Periodic resets decrease the window of opportunity for unauthorized access.
- 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 Azure Active Directory be automated?
Syncing password changes with Azure AD
Generally speaking, most organizations migrating to a hybrid infrastructure utilizing resources in Microsoft 365 will configure Azure AD Connect. Azure AD Connect is a tool organizations use to synchronize their on-premises Active Directory Domain Services accounts to Azure AD.
Admins install and step through the synchronization wizard in Azure AD Connect to configure the various account and password synchronization options between the on-premises Active Directory environment and Azure AD.
Through Azure AD Connect, password changes enforced on the on-prem AD can be reflected onto Azure AD. However, this is where issues can arise.
Certain scenarios, when using Azure AD Connect, might surprise admins:
- Password writeback: If “Self-service password reset” is enabled, changes made in Azure AD might not reflect in the on-premises AD unless “password writeback” is also enabled.
- Authentication methods: Depending on your Azure AD password policy and on-premises AD settings, specific authentication methods might not immediately enforce the password change.
- 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 Azure AD Connect configuration with Password hash synchronization enabled, but Password writeback is disabled. However, if you’re using Specops Password Policy with 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 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 Azure AD. In order to enable syncing this setting, the ForcePasswordChangeOnLogOn feature needs to be set. It can be activated with Azure AD Connect using the command:
Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true
Below, we have run the PowerShell cmdlet on our 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 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 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 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 Azure AD Connect sync.
A note on 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 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 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 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 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 Azure AD might not recognize the password change event and allow logging in using the temporary password. This includes 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 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.
Can we leverage third-party password tools like Specops Password Policy in hybrid Azure AD environments? The answer is yes, and this blog will explain how.Read More
With default Active Directory password policies, many organizations find that users create weak, easily guessed, or incremental passwords that attackers can easily compromise. Using Azure AD Password Protection, organizations can have an additional layer of security for users’ passwords. The good news is you don’t need to abandon on-premises Active Directory to implement stronger password…Read More
Reusing passwords is common, despite years of warnings to end users. It’s a problem that’s difficult for IT teams to get a handle on, especially if people are reusing work passwords at home. This means a breach elsewhere can bring cybersecurity problems to an organization’s doorstep, even if their own Active Directory password policy is…Read More