My previous blogpost was about the Self Service Password Reset (SSPR). A nice feature for cloud identities, but this doesn’t work if you have synchronized identities or federated identities. These are managed in your on-premises Active Directory, so for SSPR to work you need to implement a password writeback solution.
Luckily this feature is available, but the standard Office 365 licenses do not include password writeback functionality. You this you need an Azure AD Premium P1 or Azure AD Premium P2 license. Enterprise Mobility + Security (EMS) E3 does include Azure AD Premium P1, EMS E5 does include Azure AD Premium P2.
To implement password writeback, you need to have SSPR up-and-running. To configure password writeback you have to run the Azure AD Connect wizard.
Note. Make sure you always have the latest version of Azure AD Connect running. Even better, use the auto update feature of Azure AD Connect to make sure you’re up-to-date. At the time of writing the latest version of Azure AD Connect was 1.1.882.0 (as of Sept. 8, 2018).
Start the Azure AD Connect wizard and select the Customize Synchronization Options. Follow the wizard until you reach the Optional Features. Check the Password Writeback option as shown in the screenshot below and click Next to continue.
Follow the wizard until the configuration is complete and click Exit to finish the wizard and store the new configuration.
The service account that’s used by Azure AD Connect needs the appropriate permissions in your on-premises Active Directory to store the new password that has been set in Azure AD.
To find out which service account is used by Azure AD Connect, start Azure AD Connect and select View Current Configuration and check the account as shown in the following screenshot:
The following permissions need to be granted to the service account on either the domain object, or on an OU if you want to scope the permissions:
- Reset password
- Change password
- Write permissions on lockoutTime
- Write permissions on pwdLastSet
Open Active Directory and Computers, enable Advanced Features, select the properties of the domain, click on Security, click on Advanced and click Add.
Select the service account that was retrieved earlier under Principal and in the applies to dropdown box select Descendent User Objects. Check the following options:
- Reset password
- Change password
- Write lockoutTime (scroll down)
- Write pwdLastSet (scroll down)
Click on OK to apply the changes to Active Directory and close any following pop-up boxes.
To test the password write back option, follow the same procedure as in the SSPR blogpost. After you have changed your password, it is written back to your on-premises Active Directory and the following event is written to the eventlog of the Azure AD Connect server.
Summary
In this blogpost I’ve shown you how to implement password writeback in your synchronized Azure AD environment. One prerequisite is that you need to have Self Service Password Reset implemented, and you need to have an Azure AD Premium P1 or Azure AD Premium P2.
Jaap Wesselius 
Fun thing with SSPR write-back is when using on-prem GPO minimum password age. Users cannot reset their password if their password is not older then minimum password age 🙂 Next to that make sure inheritable permissions are enabled on all users so that the AD Connect service account has the password change permissions on the users. I see companies where it does not work cause Some users dont have inheritable permissions enabled. PS. Cool fact is that next to password reset a user can also unlock his account with SSPR, if enabled.
LikeLike
Good feedback, thanks. Let me get you a coffee in two weeks 🙂
LikeLike
Hello, We have Azure AD Connect syncing on prem AD to Azure. I set up password write-back and SSPR today. Things are looking good. One question I have that i cant find any information on , is when “User must change password at next logon” is checked off in AD, it doesn’t prompt the end user to change password when logging into Azure or O365.
LikeLike
Good question, there are more pitfalls here when it comes to password policies and SSPR, this is just one I’m afraid
LikeLike
We have experienced the same thing, we came to the conclusion that we cannot use “User must change password at next logon” in local AD, it just doesn’t work with AD Sync.
LikeLike
I’m afraid you’re right. I’m looking for some spare time to dive into this and create a blog on these specific scenarios
LikeLike
On another note, SSPR and MFA setup are converged. User only has to enroll once both both services l. https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-registration-mfa-sspr-combined
LikeLike
Thanks
LikeLike