Azure AD Connect is the main application to sync the Active Directory object between the on-premise and Azure Active Directory and vis-versa. The password writeback feature enables the user to have a unified password across the cloud.

Keeping the synchronization in a healthy state is crucial, but sometimes things don’t go as expected, and issues happen. You don’t want your users failing in login in or changing their password using the Microsoft portal.

This post will focus on troubleshooting Azure AD Connect Password writeback and how to solve common problems.

Prerequisits

To follow along this journey, you need to have Azure AD Connect installed and configured as this post won’t discuss much on how to install, more than how to troubleshoot and configure.

This tutorial has the following:

• Single Domain Controller 2019, The Active Directory forest name Test.local
• Single Windows 10 Client join to Test.local forest
• On-premises AD user named MyUser.
• Microsoft E3 Trial Tenant with a tenant name: powershellonline.onmicrosoft.com
• Azure AD Connect is already installed on the Domain Controller.
• The current domain controller configured as the following for the password policy

Enforce password history	24 passwords remembered
Maximum password age	42 days
Minimum password age	1 day
Minimum password length	7 characters
Password must meet complexity requirements	Enabled
Store passwords using reversible encryption	Disabled

Password Writeback License Requirements

The Password Writeback is one of the features in Azure Active Directory P1 and P2, make sure your Azure Active Directory tenant license has one of the following:

• Azure AD Premium P1 / P2
• Enterprise Mobility + Security E3 or E5
• Microsoft 365 Business Premium

What is Password Writeback.

The password writeback is a feature in Azure AD Connect that allows passwords changed on the cloud to be written on the on-premises active directory. The password write is a real-time process, so once the user changes his password on the cloud, it will be reflected on-premises too.

Which Account is used for Azure AD Connect Password Writeback

To view the account used for the password write-back operation, open Azure AD Connect and click on View or Export current configuration. Under the Synchronized Directory, you find the account used for password writeback

As to Microsoft, these are the required permission for the account responsible for password writeback

Reset password
Write permissions on lockoutTime
Write permissions on pwdLastSet
Extended rights for “Unexpire Password” on the root object of each domain in that forest, if not already set

Microsoft.com

Enabling Azure Self Service Portal and Password Reset.

The first thing is to ensure that the Azure Self Service Portal is enabled for the selected user or all users. Start by opening the Azure Active Directory portal, and click on Azure Active Directory, then click on Password Reset

From the Password Reset, check and make sure that Selected or All is selected as you can enable the Self Service portal for some or all users.

if it’s None, then AD Users won’t be able to reset their password through the self-service portal, and they get the following error message when they try to reset their password through the self-service portal.

You can’t reset your own password because password reset isn’t available with your organization’s license.

You must contact your administrator to both reset your password and to check your organization’s setup.

Hide additional detailsSSPR_0012: Your organization doesn’t have the required licenses necessary to use password reset.
If you’re an administrator, you can get more information from the Licensing requirements for Azure AD self-service password reset article. If you’re not an administrator, you can provide this information when you contact your administrator.

So to fix this issue, make sure that Password Reset is enabled for All users or the users who should reset their password using the Microsoft self-service portal are in the Selected list.

Password Write Back is not enabled

Another possible reason why users may not be able to reset their password using Microsoft Azure Self Service Portal in a hybrid environment is the password write-back is not enabled on Azure AD Connect. To confirm, start by the following steps:

• Navigating to Azure AD Portal.
• Click on Azure Active directory.
• Click on Password reset.
• On the Password reset menu, click on On-Premises Integration

What is the status there? if you see the following message

On-premises integration has not been enabled. Learn how to enable password writeback.

Then you need to configure password writeback on Azure AD Connect.

Configure Password Writeback on Azure AD Connect.

If password writeback is not enabled, users won’t be able to reset their password by using the self-service portal, and once they request a password reset, they will get the following error

You can’t reset your own password because password writeback, how your password changes in the cloud are copied to your organization’s on-premises system, isn’t turned on for your organization

So the Password Writeback must be enabled first on the Azure AD Connect.

Configure Azure AD Connect for Password writeback (GUI)

Open Azure AD Connect and on the Welcome To Azure AD Connect, click Configure

On the Additional Task window, click on Customize Synchronization options and click Next

Type the Tenant Global Administrator username and password and click Next

On the Connect your directories window just click Next

On the Domain and OU Filtering click on Next

Now and on the Optional Features make sure that you enable (tick) the Password writeback check box. Other features are optional and won’t affect the user password reset feature. Click Next

On the Directory Extensions window click next.

On the Enable Single Sign-on window click next

Now the Azure AD connect will prepare to sync the configuration again, make sure that the Start the synchronization process when configuration completes is checked, and click Configure

Wait for a few minutes for the sync to finish.

Now jump to Azure Active Directory -> Password Reset -> On-premises integration

Enable or Disable Azure AD Connect Password writeback using PowerShell

Instead of going through all these GUI clicks, a much simpler way is to use PowerShell to enable or disable the Azure AD Connect Password writeback.

To enable the password writeback using PowerShell, use the following code

$ADconnector = (Get-ADSyncConnector | Where-Object {$_.Name -like "*AAD"}).Name
Set-ADSyncAADPasswordResetConfiguration -Connector $ADconnector -Enable:$True

The code should return the following

Password Reset Configuration for AAD connector “powershellonline.onmicrosoft.com – AAD” updated.

To disable the password writeback using PowerShell, use the following code

$ADconnector = (Get-ADSyncConnector | Where-Object {$_.Name -like "*AAD"}).Name
Set-ADSyncAADPasswordResetConfiguration -Connector $ADconnector -Enable:$False

How long does password writeback take to work

Usually, it won’t take much time, once the configuration is synced from Azure AD Connect, you should be able to see it enabled on the Azure Active Directory. Also, make sure that you refresh the Azure Active Directory page. If the writeback still not enable after 30 minutes, try re-syncing the configuration by running Start-ADSyncSyncCycle -PolicyType Delta or restarting the service by running the following PowerShell line Restart-Service ADSync

If you have issues in writeback, check the “On-Premises Directory Synchronization Service Account” account. Make sure that this user can log in and doesn’t require any MFA that blocks the log in.

Open AAD –> Users, and search for “On-Premises Directory Synchronization Service Account” and check the Audit log and Sign-in logs. Make sure there is no failed login.

Some Users Cannot Reset their password using Office 365

After we confirm the basics and ensure that all the services are working and enabled, some users may complain that they cannot reset their password and they are getting the following error when they try to type the new password.

This password does not meet the length, complexity, age, or history requirements of your corporate password policy.

Even though they follow the policy and use a very complex password such as W=*B2!qmv_$PkbV4dJr surely this password should work. Only a few users complain about this. It looks like the password writeback is not working for some users.

So let’s check why some users are getting this. In this tutorial, the user who is facing the issue is named MyUser user, so let’s open MyUser profile on Azure Active Directory –> Users –> Find MyUser user. And from there click on the Audit logs blade.

You will see logs with the following activity with a failure status :

• Self-service password reset flow activity progress
• Reset password (self-service)

Clicking on the Self-service password reset flow activity progress log shows the following details

Activity Type: Self-service password reset flow activity progress
Category: UserManagement
Status: failure
Status reason: User submitted a password that did not meet the requirements of the AD on-prem policy

Clicking on the Reset password (Self-Service) shows the following details:

Activity Type: Reset password (self-service)
Category: UserManagement
Status: failure
Status reason: OnPremisesPolicyViolation

Click here to learn how to Active Directory Auditing: How to Track Down Password Changes

The error state clearly that the error was caused by the AD on-prem policy, Let’s check the audit log on the domain controller and filter the log to show only Failed Audit

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Event ID: 4724
Task Category: User Account Management
Level: Information
Keywords: Audit Failure
Description:
An attempt was made to reset an account’s password.

Subject:
Security ID: TEST\MSOL_161f84601d39
Account Name: MSOL_161f84601d39
Account Domain: TEST
Logon ID: 0x4D1DC61

Target Account:
Security ID: TEST\MyUser
Account Name: MyUser
Account Domain: TEST

So Yes, the local DC prevent the password changes, this can be due to multiple reasons and some of the common reasons are:

• Password recently change and still did not complete the Minimum Password Age, such as a user change his password today and he forget it, so the user try to reset it again, but based on the Minimun password age, he cannot change it as its less than 1 day.
• The user is set not to change his password in the user attributes.

Related Post

Learn how to troubleshoot Active Directory Account Lock out using Audit log