<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
Okta Active Directory User Unable to Perform Self-Service Password Reset
Administration
Okta Classic Engine
Directories
Okta Identity Engine
Overview

An Active Directory (AD) user attempting a self-service password reset (SSPR) in Okta fails due to insufficient service account permissions or restrictions on the AD user object. Resolve this issue by verifying the AD Agent service account permissions, checking the adminCount attribute, and ensuring inheritance is enabled on the user object.

 

The user receives one of the following errors when attempting a self-service password reset in Okta:

 

Error: FAILURE: Password could not be changed, please contact your administrator.

 

You do not have permission to perform the requested action.

 

Reset password is not allowed at this time. Please contact support for assistance.

 

AD Agent logs for the event display the message:

 

InsufficientAccessRights

Applies To
  • Okta Identity Engine (OIE)
  • Okta Classic Engine
  • Active Directory (AD)
  • Delegated Authentication
  • Self-Service Password Reset (SSPR)
Cause

The Okta AD Agent service account lacks the required permissions to reset a user password, or restrictions exist on the AD user object that prevent the password reset.

Solution

How to verify the Active Directory Agent service account permissions?

 

Verify the Active Directory agent service account has the following write and reset permissions to perform a password reset.

  • Write permission for the AD attribute lockoutTime
  • Write permission for the AD attribute pwdLastSet
  • Permission to Reset Password

 

Review Okta service account permissions for more information on the permissions required by the Okta AD Agent service account.

 

How to check the adminCount attribute on the AD user object?

If the Okta service account possesses the requisite permissions for password resets but the action still fails, verify whether the affected user has previous or current membership in Domain Admins, Account Operators, or any other privileged user group in Active Directory. As a security measure, both current and previous users of these groups have the AD attribute adminCount set to a value of 1, which  prevents anyone except Domain Admins or Enterprise Admins from performing password resets. Removing the user from the privileged group does not reset this attribute value.

 

Check the adminCount attribute for a user in Active Directory by executing a PowerShell command to find all user accounts with an adminCount equal to one.

 
 
Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount

 

Alternatively, manually check individual user properties by enabling advanced features in Active Directory Users and Computers (ADUC) and navigating to the attribute editor.

 

  1. Open Active Directory Users and Computers and enable Advanced Features.
  2. Right-click the user and select Properties.
  3. Navigate to the Attribute Editor tab to find the adminCount value.

 

For users no longer in a privileged group, an administrator must clear or reset the adminCount attribute using PowerShell. If users in privileged groups require Okta SSPR access, the Okta AD agent service account must be added to Domain Admins or specifically delegated permissions on the AdminSDHolder object. Okta does not assist with configuring delegated permissions; administrators should engage Microsoft for any assistance needed to configure delegated permissions.

 

How to verify inheritance on the user object?

If service account permissions and the adminCount attribute do not cause the password reset permissions error, verify whether the affected user object lacks inheritance. In Active Directory, inheritance allows child objects, such as user accounts or computers in an Organizational Unit (OU), to automatically receive permissions and policies from parent objects.

 

When delegated permissions are set on the AD agent service account at an OU level, inheritance allows child objects in the OU to inherit the permissions required for the service account to manage them. When a child object lacks inheritance, those permissions do not apply to the object, even though they apply to the parent OU and to other objects in the OU.

 

Verify inheritance on the user object by navigating to the Advanced Security Settings in Active Directory Users and Computers and enabling inheritance.

  1. Open Active Directory Users and Computers and view the user object.
  2. Select Security, and then select Advanced.
  3. Select Enable Inheritance in the lower left corner if inheritance is disabled.

 

Alternatively, set explicit permissions for the AD agent service account on the user object.

Loading
Okta Active Directory User Unable to Perform Self-Service Password Reset