Office 365 password change with password writeback
Many admins have the question how they should let Office 365 users change their password at next logon. One great way is to use the Office 365 portal with Password Writeback.
This post is not about configuring Password Writeback (since there are already many blogs about it) but rather how to properly let the user change its password with Office 365, when using a synced account.
First, create the user in your on premises Active Directory:
On the next screen, it doesn’t matter if you uncheck or check the checkbox “User must change password at next logon” because we will overwrite this checkbox in Office 365. But make very sure that you set the actual password here that you are going to provide to the user. Later in Office 365, the user password reset page will check the on premises password if it matches the “current password” field. So the password writeback functionality checks your on premise credentials.
Altough, When we set the password later in Office 365, this must be the same password as on premises because the first login page in Office 365, the password there will be checked against Office 365.
When the user is created, sync it to Office 365. Once available there, click the user and click on “Reset Password”. Make very sure here that you don’t use the Auto-generate option Because the Office 365 sign in page for the user is checking this password. Also make sure that the “Make this user change their password when they first sign in” checkbox is checked.
Now let the user login in Office 365 (https://portal.office.com for example). The user will get the password reset page and is able to change is password.
If you get the error message: “Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain”, make sure that no GPO is active that enforces that a password must be used for certain days before it can be reset. Check the account with a cmd command: net user <username> /domain.
Also check the event log on your AD Connect server under Administrative Events: