none
Admin-initiated end-user password reset not working : Your new password doesn't meet your organization's password policy RRS feed

  • Question

  • I have an Azure AD tenant with Password Hash Synchronization (PHS - screenshot) and Password Writeback (screenshot) enabled.

    I am trying to reset a test user's password through the Microsoft 365 admin portal (screenshot). This operation - administrator-initiated end-user password reset from the Microsoft 365 admin center - is explicitly listed as supported under Microsoft's public documentation regarding Password Writeback:

    https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#supported-writeback-operations

    After I proceed on resetting this test user's password (screenshot, where I create a new password myself, with the flag to force the user to change the password on next logon), the user can no longer log in with his old password (good). If the user inputs the new admin-generated password, the user is then prompted to change his password (screenshot - good). However, when inputting (1) the admin-generated password as the "current password", and (2) a new complex password as the "new password", there is an error (screenshot):

    Your new password doesn't meet your organization's password policy. Try something else, or ask your admin for tips.

    This error does not make any sense for multiple reasons:

    1. My on-premises AD password policy is even disabled by GPO (screenshot).
    2. The error still shows up regardless of how complex my new password is. Error is repeatable after several different new passwords.
    3. The error persists even if, in the field for "current password", a completely incorrect password is typed in (i.e. neither the admin-generated new password, nor the original password).

    Any idea of what is going on?


    Monday, May 20, 2019 9:14 PM

Answers

  • This error went away for a new user created from scratch in on-premises AD. We noticed that the security tab for the old user and the new user were different. For example, "Creator Owner" did not have any special permissions over the old user, but it did over the new user:

    Still no root cause, but it was probably something regarding this difference in the user accounts.

    Tuesday, May 21, 2019 4:57 PM

All replies

  • This error went away for a new user created from scratch in on-premises AD. We noticed that the security tab for the old user and the new user were different. For example, "Creator Owner" did not have any special permissions over the old user, but it did over the new user:

    Still no root cause, but it was probably something regarding this difference in the user accounts.

    Tuesday, May 21, 2019 4:57 PM
  • Thank you for sharing your findings with the community . We appreciate you taking time for the same. 


    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!!

    Wednesday, May 22, 2019 6:49 AM
    Moderator
  • Microsoft support request number associated with this problem: 119052025002536.

    It was the Microsoft support engineer that discovered the differences in the security tab of the different user accounts.

    Wednesday, May 22, 2019 2:59 PM