Use the Authentication page 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.
Policies are the first line of defense in keeping an organization secure. 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.
Note: If this feature is not enabled for your org, basic password management settings are located in here.
Group password policies allow you to define password policies and associated rules to enforce password settings on the group and authentication-provider level. You can 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 AD-mastered users. For AD-mastered users, ensure that your Active Directory password policies don't conflict with the Okta policies. Passwords for AD-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.
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-mastered users, the Active Directory complexity requirements should reflect the Active Directory instance.
Configure a password policy at the org level to manage the complexity and expiration of end user passwords. Passwords for Active Directory and LDAP delegated authentication users are managed by their directory service.
- Select Security > Authentication > Password.
- In the Password section, click Edit.
- Configure the following settings:
- Minimum length – Specify a minimum password length of four to 30 characters (the default value is eight).
Note: The maximum length for a password is 72 characters. You cannot change the maximum length.
- Common password check – Check Restrict use of common passwords to ensure that passwords are not too weak based on a list of the most commonly used passwords.
- Complexity requirements – Complex passwords increase the security of your users' accounts. Choose any or all of the items in the list to define the level of complexity that is required for your users.
- Password age – Specifies how often users must change their passwords and prevents them from reusing the same passwords within a specified period of time. Setting the password age does not set how long a password is valid for a session.
- Password history enforces the number of passwords that must be different before your users can reuse a password. You can specify from 1–24 passwords.
- Minimum password age enforces the minimum time interval required between password changes. This setting prevents users from bypassing the enforce password history requirement. You can configure this setting for 1–999 hours or days.
- The password expiration enforces how long a password remains valid before it must be changed. Users are warned five days before the expiration date that their passwords are going to expire. They can change their password when the warning appears or wait until the expiration date. After a password expires, users must change their passwords to sign into Okta. You can configure this setting for 1–999 days. Note that users do not receive an expiration warning if this field is set to less than six days.
Note: Password expiration cannot be accurately calculated for users created before March 10, 2014. For these users, the expiration period starts with the user's last sign-in date instead of the time the user last changed their password.
- Lockout — Select what happens when users enter an invalid password too many times. You can set the number of failed attempts before the account is locked to 1–100 attempts. You can allow locked-out users to reset the password themselves (i.e., Forgot password?). Select how a locked account is unlocked:
- Users can unlock their account with self service — If you do not permit self service, see Unlock an individual user account for how to reset users' passwords. Locked out users that wish to reset their password must unlock their account first before attempting to reset their password.
Note: If an account has ten successive lockouts and auto-unlocks with no successful log ons, Okta suspends auto-unlock and logs an event.
- Account is automatically unlocked after __ minutes — The account is automatically reset without additional action from users after the number of minutes that you specify. The minimum setting is one minute. The user password remains unchanged when the account is unlocked.
Important: To allow users to receive SMS messages as part of the self-service unlock process, you must enable Allow SMS for self-service operations in the Organization section shown below, in addition to configuring self-service unlock in this section.
- Send lockout email to user — Select to send locked-out users an email if their account is locked due to too many failed sign-in attempts. You can customize the Account Locked email in Settings > Email & SMS. You can also insert a link in the email to let users unlock their account. To enable the link, select Users can unlock account with self-service.
- Minimum length – Specify a minimum password length of four to 30 characters (the default value is eight).
- Click Save.
All Okta-mastered users are subject to the Default Policy unless another policy applies. The Default Policy cannot be deactivated or deleted, and always holds the lowest ranking within the policy list.
A Legacy Policy is automatically created for Okta-mastered users. In previous versions of the platform, password policy settings were located on the Security > General page. For orgs that were created before Group Password Policy was enabled, the Legacy policy and associated Legacy rules are preserved. Existing password policy settings for an org are copied to the Legacy Policy. All Legacy policy and rule settings are configurable.
Active Directory Policy
If you currently have one or more Active Directory (AD) integrations, an AD policy is automatically created for you. You can customize the elements of the policy and its rules.
- To create a password policy, click Add New Password Policy. In the screen that opens, enter any desired policy name and description.
- Configure the following items.
For new policies
Policy name: Enter a unique name.
Policy description: Enter a description.
Add group: Enter the name of the group(s) to which this policy will apply.
Authentication Providers: An authentication provider is the primary source of user-specific data. Use the Applies to: drop-down menu to specify the appropriate source. Note the following settings for each policy type:
- Default policy: the authentication provider cannot be changed.
- Legacy policy: the authentication provider should be set to Okta.
- Active Directory policy: the authentication provider should be set to Active Directory. For more information about using AD as an authentication provider, see Install and configure the Okta Active Directory agent.
- When done, click Save / Update Policy.
Password Settings: Allow you to dictate the strength of end-user password creation.
Minimum length: Specify a minimum password length of 4 to 30 characters (the default length is eight characters).
Note: For AD-mastered users, these requirements are set and enforced by AD. Ensure that the settings here duplicate the minimum settings of AD.
Complexity requirements: Complex passwords increase the security of your users' accounts. Choose any or all of the options in the list to define the level of complexity that is required for your users' passwords.
For AD-mastered users, these requirements are set and enforced by AD; no enforcement is triggered by Okta settings. Therefore, ensure that these settings duplicate the minimum settings of AD.
For non AD-mastered users:
Does not contain part of username: A username is defined by the string that precedes the @ symbol in a given email address. For example, in firstname.lastname@example.org, the username is johnsmith. Checking this option rejects any password that contains part or all of the username.
For non AD-mastered users, selecting the Does not contain first name or Does not contain last name option excludes all of the user's first name or last name in its entirety. Checking this option ensures that a password cannot contain all of the first or last name. This option only applies to names that are at least three characters long and is not case sensitive.
Password age (Okta-mastered users only): Configure settings related to password longevity. This setting does not define how long a password is valid for a session.
- Enforce password history for last . . .: Specify the number of distinct passwords that a user must create before they can reuse a previous password. This prevents users from reusing a previous password for a specified period of time. You can configure this setting from 1–30 passwords.
- Minimum password age is. . .: Specify the minimum time interval required between password changes. This setting prevents users from bypassing the enforce password history requirement. You can configure this setting for up to 9,999 minutes.
Password expires after . . .: Specify how long a password remains valid before it must be changed. When a user's password expires, they must change it in order to sign in to Okta. You can configure this setting for up to 999 days. Note that users will not receive an expiration warning if this field is set to fewer than six days.
For AD-mastered users: The Password expires after setting does not appear. The expiry date can vary among AD users and is imported from AD.
- Prompt user. . .: Specify the number of days prior to password expiration that users are prompted to change their password. Users can change their password when prompted, or wait until the expiration date. You can configure this setting for up to 999 days.
Lock out: Configure lockout settings.
- Lock out user after . . .: Specify the number of times users can attempt to log in to their accounts with an invalid password before their accounts are locked. The maximum is 100 invalid log in attempts.
Preventing Active Directory account lockouts: Okta provides a feature to help prevent AD-mastered users from getting locked out of their Windows account and hardware device due to too many failed sign-in attempts to Okta. This feature also helps prevent a malicious third party from using Okta to lock up an end user via the web.
To prevent AD lock outs, make sure that the number entered for Lock out user after <#> unsuccessful attempts is lower than the failed sign-in attempt limit configured in AD. For example, if the maximum number of failed Windows sign-in is set to 10 in AD, you might set your maximum Okta failed sign-in limit to 5. If an end-user exceeds the sign-in limit set in Okta, additional failed attempts are not sent to AD, thereby preventing users from locking themselves out of their Windows account. Locked out Okta users can either unlock themselves or seek help from an Okta Admin.
- Account is automatically unlocked after . . .: Specify how long a locked account remains locked before it is unlocked automatically. Auto unlock requires no additional user action, and the minimum setting is one minute. You can configure this setting for up to 9,999 minutes. It is not enabled by default.
- Show lock out failures: Select to show a message on the sign-in page to alert end-users when they have been locked out of their account due to too many failed login attempts.
This is an Early Access feature. To enable it, please contact Okta Support.
Send a lockout email – Select to send locked-out users an email if their account is locked due to too many failed sign-in attempts. You can customize the Account Locked email in Settings > Email & SMS. You can also insert a link in the email to let users unlock their account. To enable the link, open the appropriate password policy rule and select The user can perform self-service account unlock.
- Unlock: (For AD policies only) Choose whether end-users who have successfully unlocked their Okta accounts can also be automatically unlocked in AD.
- Unlock users in Okta and Active Directory: Users who successfully unlock their accounts are automatically unlocked in AD as well.
- Unlock users in only Okta: Users who successfully unlock their Okta account remain locked in AD and require admin assistance to unlock their AD account.
- Reset/Unlock recovery emails are valid for: Specify how long the recovery link remains valid before it expires. The maximum period is 180 days.
- Security answer complexity: Specify the minimum number of characters that security answers must contain.
- Self-service operations (Allow SMS or Voice Call): Select if you want to allow end users who have forgotten their password to be able to reset passwords using SMS or voice call. If end users forget their passwords, Okta sends them a text message with a password reset code or a voice call with an audible password reset code. The first time end users log on after this feature is enabled, they have the option to either enter a phone number, or click Remind me later to receive a reminder when signing in on or after the 1st of the upcoming month.
- When done, click Save / Update Policy.
- To create a password rule, click Add Rule. In the screen that opens, enter any desired policy name and description.
- Configure the following items.
Rule Name: Enter or modify the rule name.
Exclude Users: Specify which users (if any) that you want to exclude from the effects of the rule.
When a User is located: Apply the rule to users with any of the following connection statuses:
- Anywhere: Applies the rule to all users regardless of whether or not their IP address is listed in the Public Gateway IPs list.
- On Network: Applies the rule to users whose IP address is listed in the Public Gateway IPs list.
- Off Network: Applies the rule to users whose IP address is not listed in the Public Gateway IPs list.
Note: For information on the Public Gateway IPs list and the IP Zones feature, see Network.
The user can: Specify whether users can change or reset their password, or unlock their account. Note the following:
- Change password: This option must be selected in order for the option Perform self-service password reset to be available.
- Perform self-service password reset: Select to allow users who are locked out to perform self-service password resets (That is, Forgot password? appears on the end-user sign-in page).
- Perform self-service account unlock: The self-service unlock option allows users to unlock their account by clicking the Unlock account? link on the sign in page. If you do not allow self-service unlock, see Reset an individual user password.
- When done, click Update Rule / Create Rule.
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.
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.
Okta amalgamates the conditions of a policy and the conditions of a rule to determine whether a policy is applied to a particular user. Policies generally consist of large elements that can be applied to many users, such as a minimum password length. Rules consist of conditions such as place and circumstance, like geographical location or whether the user is on or off a company network. A policy that contains no rules cannot be applied.
For example, if you create a policy which you assign to the group “Admins”, you would create conditions special to the needs of administrators. The policy might contain a minimum password length of 12 to restrict password hacking. An applied rule to the policy might be one that allows for a self-service unlock only under certain conditions. One condition might be whether a particular admin is off or on your company network.
- A policy that contains no rules cannot be successfully applied—a warning will indicate that no rules exist for this policy.
- Ensure that any restrictive rules are placed at the top of the Priority list.
- If “Everyone” were on top, special conditions would not apply and a policy evaluation would be unnecessary. If multiple rules are present and the conditions of the first rule are not satisfied, Okta skips this rule and evaluates the following one.
The Prompt for Factor check-box is not active unless at least one factor has been chosen from the Multifactor page.
To access the page and choose one or more factors, navigate to Security > Multifactor.
Note: If a specific factor is specified in a policy, that factor cannot be removed until it is removed from all the policies that require it.
If MFA is enabled for your org, you are required to specify at least one factor. If a factor is not specified, an error message appears on the Multifactor page.
Creating a Sign-on Policy
To create a Sign-on Policy, click Add New Okta Sign-on Policy. In the screen that opens, enter any desired policy name and description.
You can specify that a policy can only be applied to certain groups. To assign a policy to groups, enter the desired group names in the Assign to Groups field. The group names must already exist before assigning them to a policy. When done, click Create Policy.
When a policy is evaluated, the conditions in the policy are combined with the conditions in the rule. The rule is applied when all these conditions are met. A policy wth no rule cannot be applied.
Note: Once a new policy has been created, you must close all active sessions for the new policy to take effect.
Click Add Rule to add a rule to a policy. Complete the following fields as needed.
Rule name: Add a descriptive name for the rule you want to create.
Exclude users: If needed, you can exclude individual users of a group from the rule.
If a user is located...: Use the drop-down menu to assign location parameters. You can specify what kind of location will prompt authentication.
Manage configuration for Network: Click the Manage Configurations for Network link to access your gateway settings that enable your choice of access. For details on using this option, see the Public Gateway IPs section of the Using the Okta Security Page.
And Authenticates via...: Use this drop-down menu to specify the required means of authentication.
And Behavior is: Add any defined security behaviors.
And Identity Provider is: Use the drop down menu to select your identity provider. For more information on identity providers see Custom IdP Factor Authentication
- Any = Bypass this criteria.
- Okta = Sign in using Okta.
- Specific IdP = Sign in using an IdP. For example: SAML, OIDC, Smartcard and others.
Then Access is...: Based on the authentication form of the previous drop-down menu, use this one to establish whether the condition allows or denies access.
Prompt for Factor: Appears as available only when at least one factor type is enabled.
Selecting this box also displays radio buttons that determine whether the prompt is triggered per a device, at every sign-on, or per a session time that you specify. Choosing Every Time does not allow end users to control MFA prompts. For details on the user experience for these options, see End User Control of MFA Prompts.
Remember Device By Default: Enabling this feature will auto-select the end user option upon sign-in: Do not challenge me on this device again.
Manage configuration for Multifactor Authentication:
Click the Manage Configurations for Multifactor Authentication link for quick access to the Authentication page and the Multifactor tab. See Configuring Multifactor Authentication for details about each of the authentication options.
Select the box to display radio buttons that determine whether the prompt is triggered per a device, at every sign-on, or per a session time that you specify. When specifying per session, note that sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session.
Factor Lifetime: Use this drop-down menu to specify how much time must elapse before the user is challenged for MFA. The default lifetime is 15 minutes, and the maximum period is 6 months. Setting a factor lifetime is a way for end users to sign out for the amount of time noted in the Factor Lifetime and not have to authenticate again with MFA at the next sign in. End users must check a box to confirm that the setting should be applied. An example is Do not challenge me on this device for the next 15 minutes. In the case, after signing out, there is no MFA prompt if the new sign in is within 15 minutes of the last sign in with MFA. If users do not check the box, they are always prompted for MFA. The time since the last sign in is noted in the bottom of the Dashboard; however, end users must refresh the screen to see the updated value.
And Session Lifetime is…: Use this drop-down menu to specify the maximum idle time before an authentication prompt is triggered. The maximum allowed time for this option is 90 days. This is not the total connect time. The default session lifetime is 2 hours. This is idle time before users see a countdown timer at the 5-minute mark of remaining session time.
Note: You can set the maximum session lifetime number through the Okta API. If you previously set this number with the API, you cannot exceed that maximum here in the Okta app. Setting a number over the API maximum will result in an error.
- Change the order of all policies except the default policy by grabbing the dotted bar next to the policy name, as shown to the left of policy 1 below, and moving the policy to the desired position in the list.
- Change the order of rules within a policy by grabbing the bar to the left of a rule name.
- Add a new policy by selecting Add New Okta Sign-on Policy.
You can perform the following actions that affect only the policy that is selected. Click the policy name in the list to select it—the selected policy displays in blue.
- Activate or deactivate the selected policy. If you deactivate a policy, it will not be applied to any user, but you can reactivate it later.
- Click Edit to edit the policy.
- Click Delete to delete a policy. You cannot delete the default policy. A deleted policy cannot be recovered.
- Click Add Rule to add a rule to the selected policy. Within a policy, you can activate, deactivate, edit, or delete a rule.
- To view details about a rule, click the rule name under Add Rule.
If you check the Prompt for Factor checkbox, as shown below, three options appear that affect how end users are prompted for MFA in a given session.
Two of these options allow end-users to control these prompts while one disallows it.
- Per Device: provides the option Do not challenge me on this device again on the end user MFA challenge dialog box. This option allows prompts solely for new devices.
- Every Time: end users are prompted every time they sign in to Okta and cannot influence when they are prompted to provide a factor.
- Per Session: provides the option Do not challenge me on this device for the next (minutes/hours/days) on the end user MFA challenge dialog box. You specify the Factor Lifetime in the accompanying Factor Lifetime field. When specifying per session, note that sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session.
End users that sign in using the AuthN API will have their sign on policies evaluated first before their password or other factor is verified. This evaluation helps to reduce the number of account lockouts that occur across an org.
If the sign on policy is set to
deny, the user's sign on attempt is rejected and prompted with the following generic error:
Authentication failed. In this scenario, the counter for failed logins is not incremented but instead, an event indicating a pre-auth sign-on policy evaluation is triggered.
- There are no visible UI changes or required setup in the admin console to enable this back-end feature.
- This policy does not work on initial authentication for newly created accounts via JIT provisioning. The end user account must exist in Okta for it to be affected by this policy.
- This policy does not prevent users from resetting their credentials from a denied location.