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:
- Open Active Directory Users and Computers
- Enable Advanced Features from the View menu
- Locate the user β Right-click β Properties
- Go to Security tab β Advanced
- Click “Enable Inheritance”
- 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:
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