Okta Account Management Policy (OAMP) Limitation for Federated or Externally Sourced Users
Last Updated:
Overview
Okta bypasses the Okta Account Management Policy (OAMP) for federated or Active Directory (AD) sourced users because external directories handle these account management transactions. To allow AD-sourced users to reset passwords through Okta, administrators must enable Self-Service Password Reset (SSPR) and Delegated Authentication. When an AD-sourced user attempts to change a password from Account Settings, Okta generates the following error message:
Profile can’t be edited at this time.
Applies To
- Okta Identity Engine (OIE)
- Okta Account Management Policy (OAMP)
- Active Directory (AD) Sourced Users
- Federated Users
Cause
When administrators configure AD as the source of authority, the user profile in Okta remains read-only. AD directly manages profile updates, including password changes. Okta blocks profile edit attempts before evaluating OAMP because the profile is not editable. Okta evaluates OAMP only when it directly processes the account management transaction. For federated or AD-sourced users, the external identity provider (IdP) or directory handles the transaction, causing Okta to bypass OAMP evaluation.
Solution
How do administrators enable password resets for Active Directory-sourced users?
Okta does not fully support changing passwords from Account Settings for AD-sourced users under OIE OAMP. Enable SSPR and Delegated Authentication so Okta can trigger the password reset flow through AD.
- Enable SSPR in the Okta Admin Console.
- Enable Delegated Authentication.
NOTE: Changing the password from Account Settings still does not invoke OAMP because the editability check fails before Okta evaluates the policy.
