The reasons behind “User must change password at next logon”
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.
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).
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.
- 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
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
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.
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).
