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.

!!! THANKS FOR READING !!!

Regards,
HARISH KUMAR

Knowledge is not a finite resource to hoard; it’s a boundless treasure that grows when shared

Leave a Comment