Azure AD Connect Password Writeback: “Denied Access to Perform the Operation on a Privileged Account” Error

by

Overview

If you’re configuring Self-Service Password Reset (SSPR) with Password Writeback from Entra ID (Azure AD) to on-premises Active Directory, you might encounter this frustrating error in the Event Viewer or password reset logs:

hr=80231367, message=Requesting user was denied access to perform the operation on a privileged account.

The affected user may not even be a privileged account! This blog post walks you step-by-step through diagnosing and resolving the issue — based on a real-issue and fix.

Error Details

The error looks like this in your logs:

Synchronization Engine returned an error hr=80231367,
message=Requesting user was denied access to perform the operation on a privileged account.

It may occur even when the user is only a member of Domain Users.

Root Cause

This happens when the user account is flagged as a “protected account” by AdminSDHolder, which locks down permissions on users who are or were in privileged groups like:

  • Domain Admins
  • Enterprise Admins
  • Administrators
  • Schema Admins
  • Account Operators

Even if the user was removed from these groups, the adminCount = 1 flag and inheritance block remain, causing password writeback to fail.

Step-by-Step Troubleshooting & Fix

Step 1: Confirm the Error Type

Open Event Viewer on your Azure AD Connect server:

  • Navigate to: Applications and Services Logs > Directory Synchronization
  • Find error: hr=80231367

Confirm this is the exact error you’re troubleshooting.

Step 2: Verify the User Is Not in Privileged Groups

Open PowerShell and run the below command I am using G5.Test account to demonstrate it. IN your case it could be any user account, so edit and use correct:

Get-ADUser g5.Test -Properties MemberOf | Select-Object Name, MemberOf

Ensure they are not in groups like:

  • Domain Admins
  • Enterprise Admins
  • Administrators

Step 3: Check adminCount Flag

Get-ADUser g5.Test -Properties adminCount | Select-Object Name, adminCount

If the result is:

Name     adminCount
----     -----------
g5.Test  1

Then the user is still flagged as a protected account.

Step 4: Clear adminCount and Enable Inheritance

Clear the Admin Count Flag:

Set-ADUser g5.Test -Clear adminCount

Re-enable Security Inheritance:

  1. Open Active Directory Users and Computers
  2. Enable Advanced Features from the View menu
  3. Locate the user → Right-click → Properties
  4. Go to Security tab → Advanced
  5. Click “Enable Inheritance”
  6. Apply and OK

Step 5: Re-test Password Reset via SSPR

Ask the user to reset their password via:

👉 https://aka.ms/sspr

You should no longer see the error, and the password writeback should succeed.

Optional: Script to Clean Up All Affected Users

You can find and fix all users with adminCount = 1 using this script:

powershellCopyEdit# Get all users flagged as protected
$users = Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount

foreach ($user in $users) {
    Write-Host "Fixing user: $($user.SamAccountName)"
    Set-ADUser -Identity $user.DistinguishedName -Clear adminCount

    # Enable inheritance (manual step recommended for caution)
    # You can also do this via ADSI or DSACLS if automating further
}

Cross check you have correct permission assigned to the service account for ADDS connector:

Please go through with my article where I have mentioned how to assign permissions:

How to give AAD Connect account permissions

Closing Thoughts

This issue is a classic example of how legacy security mechanisms in Active Directory like AdminSDHolder can block modern features like SSPR and password writeback even when all the usual permissions appear correct.

Leave a Comment