Members of the Authentication Administrator role can not reset passwords for users with this same role

Question

I created an Azure AD group and granted that group the role of Authentication Administrator so that members of this group can reset passwords, require re-register multifactor authentication, and revoke multifactor authentication sessions with in the Azure AD admin center.

Recently I have been getting reports that members of this group that have this role are un-able to reset passwords for other members of this group. When they are logged into the Azure AD admin center and are within the User profile when they press the "Reset Password" link they receive the following error message:

Reset Password
User Display Name
The password can not be reset. This may be due to an incorrect level of administrative privilege or trying to reset your own password.

Is this error due to members with this role (Authentication Administrator) being unable to reset any password for users with the same role?

I have attempted to add in the Password Administrator role to this group as well but this did not resolve this issue. Does anyone know of a role combination that would allow this to be resolved?

• Password reset for all users including the users of this role.
• MFA re-register and revoke MFA sessions.

Answer 1

In order to reset passwords of other elevated accounts, you need to add those users to the Privileged Admin Authentication Role at a minimum or Global Admin:

https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#privileged-authentication-administrator

Answer 2

Here is an update to this question from Microsoft Technical Support:

We have been able to identify the source of the issue – The reason that your auth admins are unable to reset the passwords of other auth admins is due to restrictions placed on role-assignable groups.

As noted previously, our documentation clearly states that Auth Admins can reset the passwords of other Auth admins, with the only exception being noted as roles assigned at the scope of an administrative unit.

After testing this and replicating the issue, I was puzzled, I continued to test and found that this behavior is only present when the roles are assigned by a role-assignable group, and not when the roles are assigned directly to the users themselves.

This is working “as intended” but is poorly documented, and I will be requesting a documentation update to reflect this information. Below is the excerpt that explains the behavior that we’re seeing, with the associated documentation here.

To continue to utilize role-assignable groups opposed to direct assignments to users, you will need to provide the role of the Privileged Authentication Admin instead of the Authentication Admin. Otherwise, what you’re requesting will not be possible.

Please let me know if you have any questions regarding this, I am moving forward with a documentation update request to reflect this information where appropriate.