Helpdesk: a user at passwordreset.microsoftonline.com gets through MFA, types a new password, and lands on SSPR_0029: We're unable to reset your password due to an error in your on-premises configuration. A second ticket: the helpdesk reset someone's password in an admin portal, the cloud sign-in takes the new one, but the domain-joined laptop still wants the old one. Someone has already proposed adding the sync account to Domain Admins, "just reinstalling Entra Connect," or flipping PasswordWritebackEnabled with Graph.
Don't change permissions or reinstall anything yet. Password writeback runs the opposite direction from password hash sync: a password set in the cloud goes down to Active Directory, synchronously, while the user waits. It only works when the whole chain holds: the user is licensed and in scope for SSPR → writeback is switched on in both places (the Entra Connect wizard and Entra admin center > Password reset > On-premises integration) → the server holding it is the one active, non-staging server → that server can reach the tenant's Service Bus relay outbound on 443 (TLS 1.2, sane clock) → the operation is one Microsoft writes back (not every admin portal or PowerShell path is) → the sync engine can find exactly one linked AD user from the cloud anchor → the AD DS connector account can reset that user (rights inherited, not a protected account, not blocked by a SAM restriction) → the new password passes on-premises policy (minimum age, history, complexity, password filters). Many "writeback is broken" tickets turn out to be a protected admin account, a broken inheritance chain, a minimum password age above zero, or a staging/second server holding the relay, not a broken install.
If the problem is the other direction (a password changed on-premises isn't accepted by the cloud), that's password hash sync: use the password hash sync triage. If objects never export at all or Synchronization Service Manager shows permission-issue / 8344 on an AD export run, start with the Entra Connect sync errors triage. If Connect-MgGraph refuses the read-only queries below, the Connect-MgGraph "Insufficient privileges" walkthrough covers scopes and roles. This post covers password writeback through Microsoft Entra Connect Sync (SSPR reset, cloud password change, admin reset). Cloud Sync writeback is mentioned only where it changes which agent handles the request.
TL;DR
-
Get the exact error and operation first.
SSPR_0010= writeback not enabled;SSPR_0029= on-premises configuration problem (usually permissions, a protected account, or a SAM restriction);SSPR_0030= connectivity to on-premises. Reset (no old password) and change (old password typed) are different operations. Reproduce one of them the same way every time. -
Two switches, one license. Writeback must be on in the Entra Connect wizard (Optional features) and in Entra admin center > Entra ID > Password reset > On-premises integration. On-premises writeback needs Microsoft Entra ID P1/P2 or Microsoft 365 Business Premium. Standalone Microsoft 365 Basic/Standard plans don't support it. Ignore Graph's
PasswordWritebackEnabled: Microsoft says that flag is no longer in use. - A staging server never writes back, and only one active server can hold password writeback at a time. Read the Application log on the server that's actually active.
-
The Application log tells you which link broke. Source PasswordResetService:
31044/32002/31034= Service Bus channel down;33004= connector account denied;33008= on-premises password policy;33002/33003= user not found / multiple matches. Source ADSync:6329carries the AD-side detail. -
Rights are per user object. The AD DS connector account needs Reset password, Change password, write
lockoutTimeandpwdLastSet, and Unexpire Password at each domain root, inherited down to the user. Protected accounts (adminCount = 1) can't use writeback to reset a forgotten password, by design. Permission fixes can take up to an hour to land on the object. - Some admin resets never write back. An admin reset from the Microsoft 365 admin center, or from legacy MSOnline/AzureAD PowerShell, isn't written back. The Entra admin center and Microsoft Graph are.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Right operation and error | You know reset vs change, which portal, which user, and the SSPR_ code |
Mixing two users' tests, or an unsupported reset path that "worked" in the cloud only |
| 2. Licensed and in scope | User licensed and in the SSPR-enabled group |
SSPR_0012 / SSPR_0013 / "Your administrator has not enabled you to use this feature" |
| 3. Writeback switched on | Wizard Optional features and On-premises integration checkbox |
SSPR_0010; On-premises integration tab missing |
| 4. Active server, channel up | Not staging; one active server; Service Bus reachable on 443; TLS 1.2 |
SSPR_0030; Events 31044, 32002, 31034, 6800
|
| 5. User found | Exactly one linked, enabled AD account for the cloud anchor |
33002, 33003, "Object could not be found", "Multiple matches found" |
| 6. Connector rights | Reset/change rights inherited to the user; not protected; SAM remote calls allowed |
SSPR_0029; 33004; 6329 with ERROR_ACCESS_DENIED
|
| 7. Password policy | New password passes min age, history, complexity, filters |
33008 / 6329 0x80230619; user sees an on-premises policy violation |
| 8. Verify | Audit log shows the on-premises agent handled it; AD pwdLastSet moved |
Cloud "success" with no AD change (wrong portal / unsupported path) |
Write down the user's UPN, whether it was a reset or change, which portal, the time (with time zone), the SSPR_ code and Support code from the error page, and which Entra Connect server you believe is active, before you change anything.
Step 1: Pin the operation and decode the SSPR error
Microsoft's general troubleshooting guidance starts here: password reset (the current password isn't provided) and password change (the user types the current password) are different operations. Test one, the same way, with the same user, and compare against a user for whom it works.
| What the user sees | Microsoft's meaning | Where to go |
|---|---|---|
SSPR_0009 |
Password reset isn't enabled for the organization | SSPR policy (not writeback) |
SSPR_0010 |
Password writeback hasn't been enabled | Step 3 |
SSPR_0011 |
No password reset policy defined | SSPR policy |
SSPR_0012 |
Required licenses are missing | Step 2 |
SSPR_0013 |
User isn't a member of a group enabled for password reset | Step 2 |
SSPR_0014 |
Additional security info is needed | User registration, not writeback |
SSPR_0029 |
Error in the on-premises configuration | Steps 4–6 (Microsoft's three causes: protected admin account, connector permissions, SAM remote-call restriction) |
SSPR_0030 |
Poor connection with the on-premises environment | Step 4 |
| "Reset successfully, wait a few minutes before the changes are committed to the cloud" | Reset succeeded on-premises; the cloud write failed (time-out, cloud policy, throttling) | Not a writeback failure. Wait, then retest the cloud sign-in |
| On-premises policy violation | The password doesn't meet AD policy | Step 7 |
Then check the path the password took. Microsoft documents which operations write back:
| Operation | Written back? |
|---|---|
| User SSPR from the password reset portal; user voluntary or forced (expired) password change | Yes |
| Admin reset of a user from the Entra admin center or Microsoft Graph API | Yes |
| Admin reset of a user from the Microsoft 365 admin center | No |
| Admin reset from PowerShell version 1 or version 2 (legacy MSOnline / AzureAD modules) | No |
| User resetting their own password with PowerShell or the Microsoft Graph API | No |
| A synced admin in an on-premises protected group resetting a forgotten password | No, by design (they can still change it in the cloud) |
If the "old password still works on the laptop" ticket came from a Microsoft 365 admin center reset, nothing is broken: that path is documented as unsupported. Redo the reset from the Entra admin center.
Step 2: License and SSPR scope (read-only)
Microsoft's licensing table: hybrid user password change or reset with on-premises writeback needs Microsoft Entra ID P1 or P2, or Microsoft 365 Business Premium. Standalone Microsoft 365 Basic and Standard plans don't support SSPR with on-premises writeback.
In the Entra admin center: Entra ID > Password reset > Properties (SSPR enabled for Selected or All; only one group can be selected, nested groups supported) and Authentication methods (number of methods required). A user who isn't licensed or isn't in the selected group fails before writeback is ever involved.
Optional Graph read of the user's license and sync state (read-only; User.Read.All is enough for these properties):
Connect-MgGraph -Scopes 'User.Read.All'
$upn = 'user@contoso.com'
Get-MgUser -UserId $upn -Property displayName, onPremisesSyncEnabled, onPremisesDistinguishedName,
onPremisesLastSyncDateTime, lastPasswordChangeDateTime, assignedLicenses |
Select-Object displayName, onPremisesSyncEnabled, onPremisesDistinguishedName,
onPremisesLastSyncDateTime, lastPasswordChangeDateTime,
@{n = 'LicenseCount'; e = { $_.AssignedLicenses.Count }}
onPremisesSyncEnabled should be True. A cloud-only user never touches writeback. onPremisesDistinguishedName tells you which domain and OU to check in Step 6.
Step 3: Is writeback actually switched on? Both places, on the right server
Cloud side. Entra admin center > Entra ID > Password reset > On-premises integration: Write back passwords to your on-premises directory must be checked. Microsoft notes the On-premises integration tab only appears once Entra Connect has been downloaded and configured. If the tab is missing, the tenant has never seen a configured sync client. (Optional on the same page: Allow users to unlock accounts without resetting their password, plus the Cloud Sync writeback option if provisioning agents are detected.)
Don't trust Graph's flag. Microsoft's sync-service features page lists PasswordWritebackEnabled in Get-MgDirectoryOnPremiseSynchronization output, then says the property is no longer in use and updating it isn't supported. A False there isn't evidence that writeback is off, and setting it to True fixes nothing.
Server side. Read-only, elevated PowerShell on the Entra Connect server:
Import-Module ADSync
# A server in staging mode doesn't run password writeback, even if the feature was selected
"This server in staging mode: $((Get-ADSyncScheduler).StagingModeEnabled)"
# Writeback status for the Entra ID connector.
# Get-ADSyncAADPasswordResetConfiguration ships in the ADSync module; Microsoft Q&A answers use it for this,
# but it isn't on a Learn reference page, so treat the output fields as informational.
$aad = Get-ADSyncConnector | Where-Object {
$_.SubType -eq 'Windows Azure Active Directory (Microsoft)' -or $_.Name -like '*- AAD'
}
Get-ADSyncAADPasswordResetConfiguration -Connector $aad.Name
| Result | Read it as |
|---|---|
StagingModeEnabled is True
|
Microsoft: a staging server isn't running password writeback. Go to the active server |
| Two servers both out of staging | Unsupported. Microsoft warns only one active server can use writeback at a time, and activating a second disrupts the first one's Service Bus communication |
| Writeback configuration shows not enabled | Wizard: Configure > Customize synchronization options > Optional features > Password writeback was never committed (or was cleared) |
| Enabled, active server, still failing | Go to Step 4 |
Two scope traps Microsoft calls out:
- Cloud Sync and Connect Sync on the same domain: all password writeback for users from that domain is processed by the Cloud Sync agent, not Connect Sync. You're reading the wrong server's logs.
- Staged rollout: SSPR with writeback isn't supported when staged rollout is enabled for a security group. Microsoft says it may work in some cases but can't be guaranteed.
Step 4: Read the Application log, then test the Service Bus channel
Microsoft's best practice: inspect the Application event log on the Entra Connect server. Two sources matter: PasswordResetService (the writeback channel and each request) and ADSync (setting the password in AD). Read the last day (read-only):
Get-WinEvent -FilterHashtable @{ LogName = 'Application'
ProviderName = 'PasswordResetService', 'ADSync'
StartTime = (Get-Date).AddHours(-24) } -ErrorAction SilentlyContinue |
Where-Object { $_.ProviderName -eq 'PasswordResetService' -or $_.Id -in 6329, 6800 } |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName,
@{n = 'Message'; e = { ($_.Message -split "`r?`n" | Select-Object -First 3) -join ' ' }} |
Format-Table -Wrap
Read each request as a start/finish pair:
| Operation | Start | Success | Fail |
|---|---|---|---|
| User password reset (SSPR) | 31001 |
31002 |
31003 |
| User password change | 31006 |
31007 |
31008 |
| Admin reset on behalf of a user | 31009 |
31010 |
31011 |
No start event at all for the user's attempt means the request never reached this server: wrong server, staging, channel down, or the cloud refused earlier (Steps 1–3). Start then Fail means the channel works and AD refused the set. Go to Steps 5–7 with the detail events below.
| Event (source) | Microsoft's description | What to read next |
|---|---|---|
31015 / 31016 (PasswordResetService) |
Writeback service started / stopped |
31016 = no cloud requests will succeed until it's back |
31019 (PasswordResetService) |
Service Bus heartbeat sent successfully | Healthy channel. The message names the Service Bus namespace |
31034 (PasswordResetService) |
Error connecting to the tenant's Service Bus listener | "The remote certificate is invalid" → root CAs (Azure TLS certificate changes) |
31044 (PasswordResetService) |
Writeback isn't working. Either of the two relay Service Hosts isn't running ("Password writeback service is not in a healthy state") | Connectivity table below |
32002 (PasswordResetService) |
Error connecting to Service Bus ("token provider was unable to provide a security token") | Firewall/proxy for outbound 443 |
32009 / 32011 (PasswordResetService) |
Auth token error / onboarding service error | Wizard admin was federated or wrong password; outbound blocked |
32004 / 32005 / 32007 / 32008 (PasswordResetService) |
Decryption, configuration file, onboarding config, validation errors | Microsoft's fix for each: disable and re-enable writeback |
6800 (ADSync) |
The writeback endpoint didn't start when ADSync started | Neighbouring PasswordResetService events give the reason |
33002 / 33003 (PasswordResetService) |
User not found on-premises / two users with the same cloud anchor | Step 5 |
33004 (PasswordResetService) |
Connector (ADMA) account lacks permission on that user; also when AdminCount = 1 |
Step 6 |
33005 / 33006 / 33007
|
Account disabled / locked out on-premises / wrong current password (change) | Fix the account state, not writeback |
33008 (PasswordResetService) |
Password doesn't meet age, history, complexity, or filter requirements | Step 7 |
33001 (PasswordResetService) |
Unknown AD error | Look at ADSync events; Microsoft also lists reserved characters in OU names that cause 33001
|
6329 (ADSync) |
The AD-side detail: policy restriction 0x80230619, missing LDAP password policy control, ERROR_ACCESS_DENIED, or 0x8023061f (password sync not enabled on this management agent) |
Match the message to Steps 5–7 |
Connectivity checks (in Microsoft's recommended order, reads first):
-
Outbound HTTPS 443 to
*.passwordreset.microsoftonline.comand*.servicebus.windows.net(US Government:*.passwordreset.microsoftonline.us,*.servicebus.usgovcloudapi.net). Writeback needs no inbound firewall rules. - Take the Service Bus namespace from a recent
31019or31034and test it:
# Replace with the namespace named in your 31019 / 31034 event
$ns = 'ssprdedicatedsbprodXXX-1.servicebus.windows.net'
Test-NetConnection -ComputerName $ns -Port 443
- TLS 1.2 enabled on the sync server (Microsoft publishes check and enable scripts) and .NET Framework 4.8 or later.
-
Clock: Microsoft's "Unable to configure password writeback" article lists time skew on the Entra Connect server, alongside TLS 1.2 and a federated or unlicensed wizard admin, as causes of
6800/32001/31044. - Proxies that cut long-lived idle connections. Microsoft calls idle time-outs a common point of failure.
Older error rows on the same Learn page still mention TCP 9350–9354 for onboarding (32011). Microsoft's current "how it works" page says all writeback communication is outbound over 443. If 443 is open and 32011 persists, check whether your egress filtering predates that change.
Step 5: Can the sync engine find exactly one AD user?
Microsoft's "how it works" sequence: the cloud request carries the cloud anchor. The sync engine looks up the Entra connector space object, follows its link to the metaverse, then follows the link back to the AD connector space object. For that to work the AD object must be in the connector space and joined, and the AD-to-metaverse link must carry the Microsoft.InformADUserAccountEnabled.xxx sync rule. In a multi-forest design that rule is how the engine picks the single right AD account.
| Finding | Microsoft's meaning | Read |
|---|---|---|
33002 / "Object could not be found" |
User deleted on-premises but not in the cloud, or not synced by this Entra Connect instance | Synchronization Service Manager > Metaverse Search on the UPN; check its connectors and lineage |
33003 / "Multiple matches found" |
Two AD users share the cloud anchor, or the user is enabled in more than one forest | Unsupported for writeback. Disable the extra account (account/resource forests) |
80230402 "duplicated entries with the same anchor" (ADSync) |
Same user ID enabled in multiple domains, or a non-unique anchor (alias, UPN) | Fix the duplicate / anchor choice |
6329 0x8023061f "password synchronization isn't enabled on this Management Agent" |
A forest was added (or removed and re-added) after writeback was enabled | Microsoft's fix: disable then re-enable writeback once forest changes are done |
If the user is missing or unjoined in the metaverse, writeback can't work for them. Fix sync scope and joins first (the sync errors triage covers the export side).
Step 6: The AD DS connector account's rights on this user
Find the account first. Microsoft: Synchronization Service Manager > Connectors > the AD connector > Properties > Connect to Active Directory Forest > User name (often MSOL_xxxxxxxxxxxx). Or, with the ADSyncConfig module on the Entra Connect server:
Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1'
Get-ADSyncADConnectorAccount
What Microsoft says it needs (Enable password writeback tutorial), on the account Entra Connect uses:
| Right | Where Microsoft sets it |
|---|---|
| Reset password | Domain root, applies to Descendant User objects |
| Change password | Listed as required in the tutorial |
Write lockoutTime, write pwdLastSet
|
Domain root, Descendant User objects |
| Unexpire Password (extended right) | Root of each domain in the forest (This object and all descendant objects) |
Set-ADSyncPasswordWritebackPermissions in ADSyncConfig sets Reset Password, write lockoutTime, and write pwdLastSet on Descendant User objects. The tutorial's list is longer (Change password, Unexpire Password), so compare against the tutorial, not only the cmdlet. Every domain needs these at its own domain root, not just the forest root domain.
Read it on the failing user (read-only):
Import-Module ActiveDirectory
$sam = 'jdoe'
$u = Get-ADUser $sam -Properties adminCount, nTSecurityDescriptor, memberOf, distinguishedName
[pscustomobject]@{
User = $u.SamAccountName
DN = $u.DistinguishedName
adminCount = $u.adminCount # 1 = protected (AdminSDHolder) account
InheritanceBlocked = $u.nTSecurityDescriptor.AreAccessRulesProtected # True = parent ACEs don't reach this user
}
# Microsoft's ADSyncConfig read of the effective ACL on one object
Show-ADSyncADObjectPermissions -ADobjectDN $u.DistinguishedName
# Objects anywhere under an OU with inheritance disabled
Get-ADSyncObjectsWithInheritanceDisabled -SearchBase 'OU=Staff,DC=contoso,DC=com'
Or the GUI path Microsoft gives: ADUC > View > Advanced Features > user > Security > Advanced > Effective Access > select the connector account > look for Reset password.
| Finding | Read it as |
|---|---|
adminCount = 1 / member (now or formerly) of a protected group |
By design: writeback can't reset a forgotten password for protected accounts. Microsoft's 33004 row also names AdminCount = 1. Don't "fix" this by granting rights on AdminSDHolder (-IncludeAdminSdHolders is "not recommended") |
InheritanceBlocked = True or listed by Get-ADSyncObjectsWithInheritanceDisabled
|
The domain-root ACE never reaches this user. Microsoft's tip: inheritance must not be disabled. -ADobjectDN exists for these OUs/objects |
| Effective access lacks Reset password | Missing ACE at the domain root of this user's domain |
Rights just fixed, still 33004
|
Microsoft: permissions can take up to an hour to appear on the user's security descriptor (sdprop / replication). Pin a preferred DC while testing |
33004 and 6329 with Failed to acquire user information ... ERROR_ACCESS_DENIED
|
SSPR_0029 Cause 3: Network access: Restrict clients allowed to make remote calls to SAM on the Entra Connect server or DCs |
Check the SAM restriction (read-only). Microsoft notes the registry value can survive removing the GPO setting:
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name RestrictRemoteSam -ErrorAction SilentlyContinue
A few more Microsoft-documented AD-side causes:
-
Entra Connect installed on a domain controller: writeback depends on the legacy
NetUserGetInfoAPI, whose read requirements are hard to satisfy there. Microsoft recommends a member server, or Only use preferred domain controllers pointing at other DCs. - Pre-Windows 2000 Compatible Access should contain Authenticated Users, or writeback can fail (especially on older versions).
-
6329"The server doesn't contain the LDAP password policy control": theLDAP_SERVER_POLICY_HINTS_OIDcontrol must be enabled. Microsoft says the DCs must run Windows Server 2016 or later for it. -
hr=800700CE"filename or extension is too long" after an unlock: the connector account's password is longer than 256 characters.
Step 7: The password itself (on-premises policy wins)
When the channel and rights are fine, the failure is often policy. Microsoft (33008, 6329 0x80230619, 31003/31008/31011): the new password must meet the domain's minimum age, history, complexity, and password filter requirements, and an account with PASSWD_CANT_CHANGE can't be changed. Writeback is synchronous, so the user sees the refusal immediately.
| Finding | Read it as |
|---|---|
| User reset or changed once today already | Minimum password age. Microsoft's tutorial says set it to 0 for writeback to work most efficiently (and to allow more than one change per day) |
| Reused one of the last N passwords | Password history (default 24 remembered). Use a fresh password per test, e.g. increment a suffix |
| Third-party password filter on DCs | The filter rejects it. Read the filter's own log |
| Error says the password "doesn't comply with fuzzy policy" | Microsoft: the password is on the banned password list. Pick a different one; this isn't a writeback fault |
| Admin reset with "must change at next logon," but no prompt | Microsoft: if Password never expires is set in AD, the force-change flag isn't set on-premises |
| Account disabled or locked out on-premises |
33005 / 33006. Enable or unlock (SSPR can offer unlock without reset if you enabled that option) |
On-premises policy is enforced even when it's weaker than the cloud policy. That's Microsoft's documented behavior, not a bug.
Verify the fix landed (read-only): AD pwdLastSet moved at the test time, and the Entra audit log shows the on-premises agent handled it:
Get-ADUser jdoe -Properties pwdLastSet, PasswordLastSet, LockedOut |
Select-Object SamAccountName, PasswordLastSet, LockedOut
In the Entra admin center: Audit logs, filter Service = Self-service Password Management, then activity Reset password (self-service), Change password (self-service), or Reset password (by admin). Microsoft documents an OnPremisesAgent additional detail on admin resets: None (cloud-only), Microsoft Entra Connect, or CloudSync. Data collection starts only after someone has opened the Reporting tab or the audit logs once.
Timing: when "still broken" is just waiting
| Event | Microsoft's timing / rule |
|---|---|
| A reset or change | Synchronous. The user gets success or failure on the spot. There's no "next sync cycle" for writeback |
| Writeback service heartbeat | One message every five minutes while the service runs |
| Request while the on-premises service is down | The message times out of Service Bus and is removed after several minutes; it isn't queued for later |
| After fixing connector permissions |
Up to an hour (or more) to replicate and be stamped on user objects (sdprop) |
| SSPR throttling | 5 attempts in an hour (phone, security questions, or resets for one account) → blocked; wait 24 hours after the last attempt |
| Disable / re-enable writeback | Re-onboards and rolls the encryption keys (keys also roll every six months) |
| First enable of writeback | Microsoft: may trigger PHS events 656/657 as hashes resync; that's expected, not a new error |
| After a password GPO change | Wait for policy replication or gpupdate /force
|
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
SSPR_0010 / checkbox off |
Enable in the wizard and On-premises integration (Hybrid Identity Administrator) |
Update-MgDirectoryOnPremiseSynchronization on PasswordWritebackEnabled (unsupported, unused) |
| Staging server or two active servers | Keep writeback on the single active server | Taking a staging server out of staging while the other is still active |
31044 / 32002 / 31034
|
Fix outbound 443 / proxy / TLS 1.2 / root CAs / clock, then restart the ADSync service in a quiet window | Reinstalling Entra Connect first (Microsoft lists upgrade after restart and disable/re-enable) |
32004/32005/32007/32008, or 6329 0x8023061f after a forest change |
Disable and re-enable writeback in the wizard (clear Synchronize now at Finish) | Editing the writeback config files by hand |
33004 on a normal user |
Set-ADSyncPasswordWritebackPermissions (plus Change password / Unexpire Password per the tutorial), or -ADobjectDN on inheritance-blocked OUs |
Adding the connector account to Domain Admins |
33004 on a protected admin |
Accept the design: admin changes in the cloud, or resets on-premises |
-IncludeAdminSdHolders or clearing adminCount without a privileged-access review |
ERROR_ACCESS_DENIED + RestrictRemoteSam
|
Allow the connector account in the SAM remote-call policy (Microsoft's Solution 1) | Deleting the registry value while the GPO still re-applies it |
33003 / multiple forests |
One enabled account per person across forests | Changing the source anchor to "make it match" |
33008 / policy |
Minimum password age 0; user picks a compliant new password | Disabling complexity or history to close a ticket |
| Microsoft 365 admin center reset didn't reach AD | Redo the reset in the Entra admin center | Treating it as a writeback outage |
FAQ
Why is password writeback not working with SSPR_0029?
SSPR_0029 means the cloud reached your on-premises configuration and it refused. Microsoft lists three causes: the user is a synced admin in an on-premises protected group (by design, they can't reset a forgotten password through writeback); the AD DS connector account lacks Reset password and related rights on that user (often blocked inheritance); or Restrict clients allowed to make remote calls to SAM blocks the connector account (look for Event 33004 plus 6329 with ERROR_ACCESS_DENIED). Read the PasswordResetService and ADSync events at the time of the attempt before you touch permissions.
How do I check if password writeback is enabled in Entra Connect?
Check both sides. In the Entra admin center, Entra ID > Password reset > On-premises integration must have Write back passwords to your on-premises directory checked. On the server, confirm it isn't in staging mode ((Get-ADSyncScheduler).StagingModeEnabled is False), that Password writeback is selected under Optional features in the wizard, and that recent 31019 heartbeat events appear. Get-ADSyncAADPasswordResetConfiguration -Connector <Entra ID connector> also reports status (it comes from Microsoft Q&A guidance, not a Learn reference page). Don't rely on Graph's PasswordWritebackEnabled; Microsoft says it's no longer in use.
What permissions does the AD DS connector account need for password writeback?
Per Microsoft's tutorial: Reset password, Change password, write lockoutTime, write pwdLastSet, and the Unexpire Password extended right on the root of each domain, inherited down to user objects. Set-ADSyncPasswordWritebackPermissions sets the reset and attribute-write ACEs. Users with inheritance disabled or adminCount = 1 won't receive them. After a change, allow up to an hour before retesting.
What license is required for password writeback?
Microsoft Entra ID P1 or P2, or Microsoft 365 Business Premium. Microsoft states standalone Microsoft 365 Basic and Standard plans don't support SSPR with on-premises writeback. An unlicensed user gets SSPR_0012 before writeback is involved.
Does password writeback work on a staging server or with Cloud Sync?
Not on a staging server: Microsoft says a server in staging mode isn't running password writeback, and only one active server can use it at a time. If Cloud Sync and Connect Sync are both configured for the same domain, the Cloud Sync agent processes all writeback for that domain's users, so troubleshoot the provisioning agent instead.
Related posts
- Entra Connect Password Hash Sync Not Working (the opposite direction: on-premises password → cloud)
- Entra Connect Sync Errors Detected: Duplicate Attribute, Soft Match, and 8344 (objects that never export or join)
- Connect-MgGraph "Insufficient privileges to complete the operation" (scopes for the read-only Graph calls)
- Entra ID Break-Glass Accounts: Best Practices After Mandatory MFA (why emergency admins stay cloud-only and never depend on writeback)
- A Tier-1 helpdesk card for "Outlook keeps asking for my password" (the client side after a reset)
Free checklist
SSPR with writeback usually goes live alongside a Conditional Access and MFA push: combined registration, a pilot group, and admins who must stay out of the writeback path. If you're heading toward enforcing Conditional Access, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the identity and Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-connect-password-writeback-not-working
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 only read: Graph calls are GET-only, and the ADSync, ADSyncConfig, AD, and event-log cmdlets shown are Get-/Show-/Test- reads. Granting connector permissions, changing the SAM remote-call policy, editing password policy, restarting ADSync, and disabling/re-enabling writeback are deliberate changes. Take them in a change window, test with one user on one preferred DC, and check current Microsoft Learn for portal labels and defaults.
Top comments (0)