This article provides information about how Okta evaluates Password Policies. Use this information to better understand why a certain password policy was used over another, or to prioritize Password Policies over others to fit specific needs.

This article does not cover password complexity requirements, lockouts, resets, or any individual password settings. These are out of scope for this article.

NOTE: Multifactor Authenticators (MFA) factors will not be covered as they are evaluated separately.

• Password Policy
• Okta Sign-On
• Authentication Provider

Okta Password Policies are evaluated by three things:

1. The policy's numerical priority.
2. The group or groups assigned to the policy, and;
3. The Authentication provider.

For example, assume an org has three password policies in the following order.

• Ppolicy_A is a created policy for the Okta Everyone group using Okta as an Authentication Provider.
• Active Directory Policy is a default Policy. It is assigned to the Okta Everyone group and uses Active Directory as its Authentication Provider. This policy is created automatically when Delegated Authentication (DelAuth) is enabled for any Directory integration.
• Default Policy is a default policy. It is assigned to the Okta Everyone group and uses Okta as the Authentication Provider. This policy is automatically created when the Org is created.

Using the above constructs, policies will be evaluated as follows:

1. PPolicy_A will be evaluated first, as it is in the top priority slot. This policy will ONLY apply to users who belong to the Okta Everyone group and are signing on to Okta using an Okta-sourced password (Okta is the Authentication Provider). Delegated Authentication users will NOT meet this policy.
2. Active Directory Policy will be evaluated second, as it is in the second priority slot. This policy will ONLY apply to users that belong to the Okta Everyone group and are signing-on using Delegated Authentication from Active Directory.
3. Default Policy will be evaluated third, as it is in the third priority slot. Users that belong to the Okta Everyone group but do not match ppolicy1 or Active Directory Policy will use this policy. Because the Everyone group is assigned to both ppolicy1 and Active Directory Policy, this policy will never be used.

Now, assume ppolicy_B must be created for a subset of users. 

• When creating a password policy for a subset of users it is strongly recommended to first create an Okta group for the subset of users. 
• When prioritizing the new Password Policy for the new group, it must be a higher priority policy than any policy using Okta as the Authentication Policy, which would otherwise apply to the subset of users. This ensures the policy will be triggered.
• If a new policy is prioritized below any policy that applies to the subset of users, the new policy will be ignored due to its priority.

Using the above specifications, the new order of policies would look like this:

1. ppolicy_B
2. ppolicy_A
3. Active Directory Policy
4. Default Policy

Now, assume ppolicy_C must be created that only applies to a subset of DelAuth users.

• When creating a password policy for a subset of AD/LDAP users who use Delegated Authentication, it is possible to use AD/LDAP groups, Okta groups, or both. Though it is not required, Okta recommends creating an Okta group for the subset of DelAuth users.
• When prioritizing a Password Policy for a DelAuth group of users, it must have a higher priority than any policy that uses Active Directory as the Authentication Policy, which would otherwise apply to the DelAuth user.
• If a new DelAuth policy is prioritized below any policy that would also apply to the DelAuth user, the new policy will be ignored because of its lower priority.

Using all of the above information, the new order of policies can look like this:

1. ppolicy_C
2. ppolicy_B
3. ppolicy_A
4. Active Directory Policy
5. Default Policy

Or like this:

1. ppolicy_B
2. ppolicy_C
3. ppolicy_A
4. Active Directory Policy
5. Default Policy

This is because ppolicy_B and ppolicy_C will never interfere with each other - they are created for different Authentication Providers.

To find Password Policies:

In Okta Classic Engine:

1. Go to Admin > Security > Authentication.

In Okta Identity Engine:

1. Go to Admin > Security > Authenticators.
2. In the row for Password, click Actions, then click Edit.

To ensure the Password Policy applies to the correct user group, please refer to the Applies to field to verify if it targets Okta users or Active Directory.

Related References

• How to Create a Password Policy
• How to Assign a Password Policy to a Specific Group
• How to Determine Which Password Policy Applies to Okta and Which to Active Directory
• How To Send A Password Reset Email To An End-User