Security Policies

Okta policies allow control of various elements of security, including end-user passwords, the authentication challenges a user receives, the devices they can use, and the places they use them from. A policy can be based on a variety of factors, such as location, group definitions, and authentication type.

In the Admin Console, navigate to Security > Authentication to configure password, sign-on, and group password policies. For mobile and wifi policies, navigate to the Devices menu. Some of these options are not visible if they are not enabled for your org.

Group Password Policy

Group Password Policy enables admins to define password policies and associated rules that enforce password settings at the group and authentication-provider level. Okta provides a default policy to enforce the use of strong passwords to better protect your organization's assets. Admins can also create additional policies that are less or more restrictive and apply them to users based on group membership.

 

Group Password Policy is now enabled for all orgs.

  • The Password tab on the Authentication page displays all group password policies. Initially, only the Default Policy and the Default Rule appear.
  • If Group Password Policy was previously not enabled, the Password tab now displays the Legacy Policy and the new Default Policy. The Legacy Policy reflects the org settings present when Group Password Policy was enabled and includes the Legacy Rule and the additional Default Rule.

Note

Note

The Default Rule cannot be edited.

The Password Expired count for users on the People page is not displayed when Group Password Policy is enabled. See Expire all user passwords.

With group password policies, you can:

  • Define password policies and associated rules to enforce password settings on the group and authentication-provider level.
  • Create multiple policies with more or less restrictive rules and apply them to different groups.
  • Use policies to enforce the use of strong passwords to better protect your organization's assets.

Group Password Policies are enforced only for Okta and Active Directory (AD) and LDAP mastered users.

  • For AD and LDAP mastered users, ensure that your AD and LDAP password policies don't conflict with Okta policies. Passwords for AD and LDAP mastered users are still managed by the directory service. Some applications, such as Microsoft Office 365 and Google G Suite, check an Okta password policy when provisioning a user to ensure that the Okta policy meets the application's password requirements.
  • It is sometimes possible for a user's Okta password to meet these requirements while the password policy itself does not, which results in an error during the provisioning attempt. If you observe provisioning errors after configuring or editing an Okta password policy, ensure that it meets the application's requirements, typically, eight characters with an upper and lower case character and either a symbol or number.
  • Previous group password policy options are not retained after the LDAP group password policy feature is disabled.

  • When the LDAP group password policy feature is enabled, a custom password policy message cannot be used and previous password policy messages are not applied.

  • When LDAP delegated authentication is disabled, the LDAP group password policy no longer applies to LDAP mastered users.

Note: The default password policy is applied when a user is created. Group assignment on password policy is not evaluated when user is created.

Password Policy Evaluation

There are three general guidelines for password policy evaluation.

  • Complexity requirements are evaluated at the point in time when the password is set.
  • Password expiration is evaluated based on the current policy and when the user last set their password, unless the user's password is already expired in which case it remains expired.
  • For AD and LDAP mastered users, the AD and LDAP complexity requirements should match the AD and LDAP instances.

Okta Sign-On Policies

Sign-on policy can specify actions to take, such as allowing access, prompting for a challenge, and setting the time before prompting for another challenge. You can specify the order in which policies are executed and add any number of policies. If a policy in the list does not apply to the user trying to sign in, the system moves to the next policy.

You can specify any number of policies and the order in which they are executed. There is one required policy named Default. By definition, the default policy applies to all users.

In addition to the default policy, which you cannot delete, there is another policy named Legacy that is present only if you have already configured MFA. This policy reflects the MFA settings that were in place when you enabled your sign-on policy, and ensures that no changes in MFA behavior occur unless you modify your policy. If needed, you can delete it.

When a policy is evaluated, the conditions in the policy are combined with the conditions in the associated rules. Rules are applied when all these conditions are met.

Note: A policy with no rules cannot be applied.

Policies can contain multiple rules, and the order of the rules determines their behavior.

 

Configure sign-on policies for RADIUS applications

If you create a sign-on policy from the admin console under Security > Authentication > Sign On, it will not apply to a RADIUS application. Sign-on policies for RADIUS applications must always be configured as part of the RADIUS application setup instead. For more information, see Add sign-on policies for applications.