How NOT to Change an Office 365 Password

Since so many worldwide have been locked inside their homes, unable to venture out to the office for work, they have been forced to change their own passwords. Office 365 administrators have scrambled to apply the necessary licenses and instructions to allow them to do so. The process isn’t well documented—certainly not the big ‘gotcha’—so here it is.

What happens when passwords are changed?

When a user changes their own password ctrl/alt/delete on their PC, an Event ID 656 is logged on the Azure AD Connect (AADC) server to say the password is being transmitted, and then Event ID 657 logged when the password is successfully transmitted to the tenant.
If an administrator does this for one or more users the same events are logged. Consequently, single Event ID 656 and 657 might show up to 50 password change events.

If an Office 365 user attempts to change their password, Azure AD will immediately communicate with AADC Connect with the desired password. If it’s accepted, Event ID 31007 is logged. If not, Event ID 33008 is logged. These 33008 messages mean the password is not long enough, complex enough, is a repeat of another recent password or has been changed too recently. Many organizations set Active Directory Group Policies to forbid more than one password change by end users in a 24-hour period. This is the most likely cause of errors when changing passwords in Office 365.

If a user changes their password in Azure AD, and meets all the requirements set in the relevant GPO, an Event ID 31006 is logged on the AADC Server stating the password change process is being started to write to AD. Event ID 405 (two of them) will then be logged to show that an LDAP connection is being opened, followed by an Event ID 31007 to state a password has been successfully changed and written to Active Directory. This password is written to the PDCE FSMO role holder where the AD “PwdLastSet” attribute will show the recent action.

If you are synchronizing your Active Directory with Office 365, the password expiration settings you might set for Cloud-Only accounts do not affect the synchronized accounts. Active Directory is always prime.

When Administrators Set Passwords

When working with Active Directory and sending passwords into the cloud—or when users change their own passwords in the cloud—the process generally works flawlessly.
Here’s when it doesn’t.

Exception Scenario 1

Passwords changed by an administrator in Office 365 (Admin, Users, Active Users)—and that don’t required the user to change the password on next logon—don’t generate an AADC Event ID because they’re not written back to Active Directory. These passwords become diverged and will only be converged when the user sets the desired password on their PC the next time they’re VPN’d-in or are in the office. The user will log onto their office PC with the old password and then ctrl/alt/delete and change the password, overwriting the one in AD and causing a synchronization action to Office 365, further overwriting that one as well.

Exception Scenario 2

Password changes by an administrator in Office 365 that require the user to change the password at next logon are more complex and (I venture to say) should be avoided!

The user goes to https://portal.office.com as usual and first enters the password set by the administrator in the portal. On the next screen, the user is prompted to enter their old password and their new password (twice). Here, they must enter their old on-premises password (not the one they were just given) and then choose a whole fresh new password to enter. This is because Office 365 goes to a Domain Controller (Via AADC of course) to try and set the password in accordance with complexity policies. When it does so it also supplies the old password and must supply the one that AD has. Therein lies the issue. One might ask why an admin would allow this situation, but it’s happening. Hence my wee contribution to cyberspace.

Even after all that, Office 365 will probably tell the user their password has been accepted but that “we’re trying to catch up” and to try again in a few minutes. On the AADC server there will not be an Event ID to say that Office 365 has taken the initial change by an administrator and sent it—or tried to send it—to Active Directory. Only after the user themself has entered the final and valid password will there be an Event ID 31007 to log that the password has now been changed in Office 365 by the user and written to Active Directory. That becomes the point at which the only valid password will be the one the user just typed in; it will be valid on Active Directory and on Office 365.

In Summary

Ensure your Self-Service Password Reset is setup correctly. It’s extremely simple but if you have AADC running and only allow SSPR later, you need to do an initial sync again. This doesn’t overwrite anything important or cause problems (and perhaps “initial” isn’t the best word) but execute: Set-ADSyncSyncCycle -PolicyType Initial and all will be well.

And administrators, don’t use Office 365 to reset AD-sourced accounts.

I hope you found this blog informative. If you have any questions, whether they be around Office 365 passwords, migrations, conditional access, or any other area of Office 365, please don’t hesitate to reach out. We at Anexinet would love to have a conversation.