locked
AADSync Password Reset RRS feed

  • Question

  • Hi All!

    I had been trying to configure the password reset using the password writeback but I hadnt get luck.

    I had successfully sync two AD forest to my Azure tenant

    

    I am using AR\aadsync as the service account to sync between AD Azure an AD onprem

    I had granted the proper permission to that service account

    But when the user try to change his password they got these errors:

    By the way, I already have below permissions set at Domain level for AD MA account:

    • Reset Password
    • Change Password
    • Write lockoutTime
    • Write pwdLastSet

    And the user that trying to change his password has not check the option password never expire.

    Any ideas? 

    Thanks in advance.

    Cheers,

    Javier.


    Thursday, September 6, 2018 4:42 PM

Answers

  • @Javier & Zafog, when you added new active directory forest after the password writeback option has already been enabled. Then the password operations for users in these recently added forests will fail.

    Did you tried disable and then re-enable the password write back option after changing of forest configuration?  If not, try disable the feature and re-enable.

    Check the similar issue that has been discussed here & here regarding the below error for the solution. (“Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access.”

    Check whether the following settings are configured correctly in on-premise DC. This is also one of the reasons being caused by the Minimum password age policy setting that in this instance is defined in the Default Domain GPO.  This setting determines the period (in days) that a password can be used before a user is permitted to change it. The minimum password age is set to 1 day. 

    You must change the value to 0, allowing passwords to be changed immediately.

    Let us know, if the issue still persists after trying the above suggestions.

    -----------------------------------------------------------------------------------------------

    If this answer was helpful, click “Mark as Answer” or Up-Vote. To provide additional feedback on your forum experience, click here.

    • Proposed as answer by YASWANTHM-MSFT Thursday, September 13, 2018 2:12 PM
    • Marked as answer by Javier.Ibarra Thursday, September 13, 2018 5:53 PM
    Thursday, September 13, 2018 2:11 PM

All replies

  • The error which you are getting in Event ID 6329 indicates that the password writeback service attempted to set a password that does not match the on-premises password policy. You can find more info and additional troubleshooting tips here:  https://docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-passwords-troubleshoot#troubleshoot-password-writeback .

    For more clarification, Did you check the article for Configure Password Writeback  ? If not, re-check once the permissions which you have configured for Active Directory is correct.

    Also, you may refer the similar discussion on this issue for troubleshoot here and here. See if this helps.

    Disclaimer: This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet. 

    -----------------------------------------------------------------------------------------------

    If this answer was helpful, click “Mark as Answer” or Up-Vote. To provide additional feedback on your forum experience, click here.

    Thursday, September 6, 2018 6:07 PM
  • Thanks for the response!

    I had already checked all of those document you had mentioned in the reply.

    I had created a new user for testing propuse and give Full Control of the AADConnect service account to validate if the permission is wrongly assigned.

    And I still have the same issue. Event ID 6329 and 33004. 

    : Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access.

     "ERR_: MMS(4148): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'ADMADoNormalization', 0x2
    BAIL: MMS(4148): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (The system cannot find the file specified.): Win32 API failure: 2

    The AADConncet is configured to perform the writeback.

    I ran out of ideas... I don't have a clue what else I need to check or configure to avoid the issue.

    Cheers!

    Javier.

    Thursday, September 6, 2018 8:00 PM
  • @Javier, For more clarification, did you check the Writeback-permissions for reset password and change password extended rights? If not re-check once here under Password Write-back. Also, I would recommend you to check the requirements mentioned in the following document here and here are configured correctly.

    I would suggest you re-verify once that Azure AD Connect has the required permissions for password writeback by following the steps mentioned in the document here. See if this helps and let us know.

    -----------------------------------------------------------------------------------------------

    If this answer was helpful, click “Mark as Answer” or Up-Vote. To provide additional feedback on your forum experience, click here.


    Sunday, September 9, 2018 2:17 PM
  • Hi! Yes, I'd already checked the information you had provied in the replay.

    Next, there are the resultant screenshots for those validation.

    The user is sspr@perceptiongrp.com. (Just created a new one, but the issue is the same for all).

    Licence:

    The users had asigned EMS E3 that includes de AAD Premium Plan 1 that supports SSPR

    The account that we are using is AR\AADSync. Is also responsable to sync de users from AD onprem

    DSACL:

    Tested again today and we are having the same issue

    The account AR\AADsync has permission to change and reset password on the test user that is failing to reset the password.

    Thanks in advance for any help or advice.

    Cheers,

    Javier

    Monday, September 10, 2018 2:18 PM
  • Hello everyone, I'm having exactly the same issue with SSPR. I tried all the suggested solution from microsoft tutorial, done all the permission etc but still not able to make it works. There is any updates? Thank you
    • Edited by Zafog Wednesday, September 12, 2018 10:36 AM
    Wednesday, September 12, 2018 10:36 AM
  • @Javier & Zafog, when you added new active directory forest after the password writeback option has already been enabled. Then the password operations for users in these recently added forests will fail.

    Did you tried disable and then re-enable the password write back option after changing of forest configuration?  If not, try disable the feature and re-enable.

    Check the similar issue that has been discussed here & here regarding the below error for the solution. (“Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access.”

    Check whether the following settings are configured correctly in on-premise DC. This is also one of the reasons being caused by the Minimum password age policy setting that in this instance is defined in the Default Domain GPO.  This setting determines the period (in days) that a password can be used before a user is permitted to change it. The minimum password age is set to 1 day. 

    You must change the value to 0, allowing passwords to be changed immediately.

    Let us know, if the issue still persists after trying the above suggestions.

    -----------------------------------------------------------------------------------------------

    If this answer was helpful, click “Mark as Answer” or Up-Vote. To provide additional feedback on your forum experience, click here.

    • Proposed as answer by YASWANTHM-MSFT Thursday, September 13, 2018 2:12 PM
    • Marked as answer by Javier.Ibarra Thursday, September 13, 2018 5:53 PM
    Thursday, September 13, 2018 2:11 PM
  • Thanks a lot. Finally it had worked.

    The issue was the group domain policy that we had set on 80 days the remember password.

    After modifying the value to 0 as you suggested in the screenshot of your last reply the process worked fine!

    Many thanks for your time and help!


    Thursday, September 13, 2018 5:56 PM
  • It's good to hear that your issue has been resolved.
    Thursday, September 13, 2018 6:15 PM
  • Hi Yaswanth,

    thanks for your reply. I still have the issue. Are four weeks now that I cannot figure out where is the issue.

    I did all the configuration and settings from the various forum, technet etc. but still cannot work.

    What I noticed is that if I access to the link account-activedirectory-windowsazure-com and then do Change Password I put my old password and new one and it works writing back on my prem AD.

    If I try to do it trough passwordreset microsoftonline com I get always the AdSync error

    My policy configuration is this

    ENFORCE PW HISTORY – 24 password remebered
    MAXIMUM PASSWORD AGE – 90 DAYS
    MINIMUM PASSWORD AGE – 0 DAYS
    MINIMUM PASSWORD LENGTH – 8 CHARACTERS
    PASSWORD MUST MEEt COMPLEX -  ENABLED
    STORE PASSWORD ENCRYPTION - DISABLED

    Any help is appreciated. I cannot sort it out.

    Thanks.

    Friday, September 14, 2018 3:20 PM
  • @Zafog, Could you share the AdSync Error log message with the screenshot?
    Tuesday, September 18, 2018 6:52 PM
  • Sorry I cannot send screenshot, it say I need to verify my account but I don't know how to do it.
    Anywayt I can past the logs:

    System
    - Provider
    [ Name] ADSync
    - EventID 6329
    [ Qualifiers] 49152
    Level 2
    Task 3
    Keywords 0x80000000000000
    - TimeCreated
    [ SystemTime] 2018-09-19T09:57:08.000000000Z
    EventRecordID 295843
    Channel Application
    Computer SERVER.DOMAIN.local
    Security
    - EventData
    ERR_: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'ADMADoNormalization', 0x2 BAIL: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (The system cannot find the file specified.): Win32 API failure: 2 BAIL: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (The system cannot find the file specified.) ERR_: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'ADMARecursiveUserDelete', 0x2 BAIL: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (The system cannot find the file specified.): Win32 API failure: 2 BAIL: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (The system cannot find the file specified.) ERR_: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'ADMARecursiveComputerDelete', 0x2 BAIL: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (The system cannot find the file specified.): Win32 API failure: 2 BAIL: MMS(6472): E:\bt\864962\repo\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (The system cannot find the file specified.) ERR_: MMS(6472): admaexport.cpp(2939): Failed to acquire user information: 0x5 BAIL: MMS(6472): admaexport.cpp(2963): 0x80230626 (The password could not be updated because the management agent credentials were denied access.) BAIL: MMS(6472): admaexport.cpp(3296): 0x80230626 (The password could not be updated because the management agent credentials were denied access.) ERR_: MMS(6472): ..\ma.cpp(8193): ExportPasswordSet failed with 0x80230626 Azure AD Sync 1.1.880.0

    - System
    - Provider
    [ Name] PasswordResetService
    - EventID 33004
    [ Qualifiers] 0
    Level 2
    Task 0
    Keywords 0x80000000000000
    - TimeCreated
    [ SystemTime] 2018-09-19T09:57:08.000000000Z
    EventRecordID 295844
    Channel Application
    Computer SERVER.domain.local
    Security
    - EventData
    TrackingId: 612eb20a-5a8c-4029-9344-8fd36d88056d, Reason: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access., Context: cloudAnchor: User_a11e6d18-7808-4e50-84a3-74b79f7f5b9e, SourceAnchorValue: zC7w0Slj2kacpZItNX4mPA==, UserPrincipalName: USER@DOMAIN.com, unblockUser: True, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access. at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr) at AADPasswordReset.SynchronizationEngineManagedHandle.ResetPassword(String cloudAnchor, String sourceAnchor, String password, Boolean fForcePasswordChangeAtLogon, Boolean fUnlockAccount, Boolean isSelfServiceOperation) at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ResetUserPassword(String passwordResetXmlRequestString, Boolean unlockUser)

    Thanks

    • Edited by Zafog Wednesday, September 19, 2018 10:03 AM
    Wednesday, September 19, 2018 10:02 AM
  • At the end I found that the issue was the server.

    After installing AD Connect on another server it worked fine.

    The configuration in this post is correct and working fine.

    Thank everyone for the help!


    • Edited by Zafog Monday, September 24, 2018 2:07 PM
    Monday, September 24, 2018 2:06 PM
  • Hi Javier,

    The noted symptoms and behavior covered above is EXACTLY what we were experiencing.  Finally after a lot of blood, sweat and tears, we finally got to the bottom of this particular issue.  Although this solution might not apply to everyone, it certainly matches the behavior and challenges expressed above.  

    Ok – Here are a few details of our landscape – The “Client” maintains an On-Prem Active Directory with 2016 DCs (2012R2 FFL/DFL), AADC (ver: 1.3.21.0), GMSA (local database), Pass Through AuthN (PTA), Primary/Staging servers, dedicated AD MA accounts for each AAD Connect server (separation of duties with strict non-interactive settings), security group (AD MA within) for AD delegation, SCHANNEL TLS 1.2 remediated, AD with minimal Password Age set to 0, etc..  Even within Azure AD, the PW Integration feature shows as up & operational - Green Lit baby!!

    SSPR failed only (exactly per your above symptoms) if a user would select "forgot password" from the Office 365 portal, followed by Application (Error) event IDs: 6329 & 33004 matching the EXACT same description provided above.

    However, strangely enough, SSPR would successfully write-back to OnPrem AD under the following circumstances:

    • Login Office 365 Portal (portal.office.com), > Account Management (upper right hand corner) > My account > Manage security & privacy > password – user changes password
    • Reset the user's AD password (On-Prem) and flag the account to change password on next logon

    Note: Delegating the AD Management Agent (AD MA) additional "full access" to EVERYTHING (all objects) further did not resolve the problems we were facing.  The exact same errors and behavior above continued.

    However, and certainly not recommended, granting my AD MA 'Domain Admin' rights allowed (repeat allowed) for successful password changes via the SSPR “Forgot Password” option.  This certainly was a head scratcher!  What the heck what going on?!?!

    Aside from all the recorded instances of "denied access..." messages appearing in both event IDs (33004 & 6329), an important and obvious detail was in plain sight - something in plain sight and directly in front of us the whole time.

    Inspection of the error message section (event ID 6329), there was an important clue - "Failed to acquire user information: 0x5".  This says the service account was unable to locate or query the user object.  It’s too bad the preceding and subsequent messages were so friggen ambiguous.

    Backing up a few steps - approximately 30 days ago, we implemented Microsoft Advanced Threat Analytics (ATA). One of the built in features of ATA is lateral movement path detection.  To enable this particular feature within ATA requires configuration of SAM-R (used to restrict which clients can initiate remote calls to SAM - read link).  For our ATA service account, we had gradually deployed SAM-R throughout the forest via a root level GPO.  Had our ATA deployment impacted our SSRP?? 

    Important Call Out: A Microsoft engineer provided the bread crumbs which lead us to isolating this SAM-R road block - Thank you Victor

    Anyway, this happened to be the exact source of our problem and the solution we were looking for.

    Furthermore; removing this SAM-R configuration from all DCs, plus isolating SAM-R to only member computers (via GPO), resolved the SSPR writeback problem (meaning we removed it from DCs and now the world has suddenly became a far better place live in - ha, ha).  Passwords resets (via "Forgot Password") were now successfully working without all the previous described complications  – boy did we feel like PIMPs.

    Important note though; backing-out (or removing) this GPO SAM-R setting did not automatically remove itself from the registry (HKLM\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam) – clean up either required 1.) manual intervention of the registry or 2.) a GPP to remove this.

    Finally, bringing this whole thing back to something mentioned above.  Our AD MA accounts are members of a delegation security group.  We solved the whole problem by configuring the GPO SAM-R security descriptors to include this same AAD Connect delegation security group (GPO applied to DCs).

    This provided the account with the necessary setting to query the AD SAM while at the same time maintained our security posture.

    Javier, purely speculating in your case - I can only guess the SAM-R setting might have been configured (or tattooed) on a Domain Controller.  Unless your AAD Connect was a DC, I’m uncertain why a rebuild fixed the issue (shrug).  In our case, a server rebuild wouldn’t have resolved our challenge as the SAM-R was applied via a GPO from the root.

    I hope this makes sense and helps anyone else experiencing similar challenges.

    Warmest Regards,

    Shawn May


    Shawn May ~ MCSE Principal Architect & CEO DTS Inc.







    • Proposed as answer by Shawn May Friday, October 11, 2019 10:41 PM
    • Edited by Shawn May Saturday, October 12, 2019 1:45 AM
    Friday, October 11, 2019 10:23 PM