Configure a password policy

Password policies enable 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 other policies that are less or more restrictive and apply them to users based on group membership.

Password reset requests made by Lightweight Directory Access Protocol (LDAP)-sourced users can fail when a password policy on an LDAP server doesn't allow users to change their password. If a password reset fails, the Okta LDAP Agent log provides the LDAP error code. To create password policies that allow users to change their password, consult the LDAP server manual provided by the vendor.

When an admin creates a temporary password for LDAP sourced users, users must change their password when they next sign-in if the LDAP server password policy requires or allows it. To create password policies that support temporary passwords, consult the LDAP server manual provided by the vendor.

Create a password policy

In the Admin Console, go to SecurityAuthentication.
Click the Password tab and Add New Password Policy.
Complete these fields:
- Policy name: Enter a unique name for the policy.
- Policy description: Enter a description for the policy.
- Add group: Enter the names of the groups to which the policy applies.
In the Authentication Providers section, select the primary source for user data:
- Okta: Create an Okta password policy.
- Active Directory: Create an Active Directory (AD) password policy.
- LDAP: Create an LDAP password policy.
Complete these fields in the Password Settings section:
- Minimum length: Enter a minimum password length of 4 to 30 characters (the default minimum is 8 characters). For Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) sourced users, AD and LDAP set and enforce these requirements. Ensure that the settings here duplicate the minimum settings of AD and LDAP. Okta stores a maximum of 72 characters.
- Complexity requirements: Select options to define the level of complexity that is required for user passwords.
- Common password check: Select Restrict use of common passwords to prevent the use of common, weak passwords.
- Password age: select these options:
  - Enforce password history for last: Enter 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. You can configure this setting from one to 30 passwords.
  - Minimum password age is: Enter 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: Enter the number of days that a password remains valid before it must be changed. When a user's password expires, they must change it to sign in to Okta. You can configure this setting for up to 999 days. Users don't receive an expiration warning if the value is fewer than six days.
    For AD and LDAP sourced users: The Password expires after setting doesn't appear. The expiration date can vary and is imported from AD and LDAP.
  - Prompt user: Enter the number of days before 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. Users don't receive an expiration warning when the value is less than six days.
- Lock out:
  Select these options:
  - Lock out user after: Enter 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 login attempts. See About lockouts.
  - Account is automatically unlocked after: Enter the number of minutes a locked account remains locked before it's 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 isn't enabled by default.
  - Show lock out failures: Alert end-users when they've been locked out of their account due to too many failed login attempts.
  - Send a lockout email to user: Send an email to users when their account is locked due to too many failed sign-in attempts. You can customize the Account Locked email in SettingsEmail & SMS. You can also insert a link in the email to let users unlock their account. To enable the link, open the appropriate email and select The user can perform self-service account unlock.
- Unlock: If you selected Active Directory as the authentication provider, you may select these options:
  - Unlock users in Okta and Active Directory: Unlock user accounts in AD and Okta.
  - Unlock users in only Okta: Unlock user accounts in Okta.
Complete these fields in the Account Recovery section:
Self-service recovery options: select these options:
- SMS: Send users who have forgotten their password a text message with a password reset code. The user can enter a phone number or click Remind me later to receive a reminder when signing in on or after the first day of the next month.
  The security question is required to perform a password reset with SMS. With an Early Access feature, you can omit a security question from the password recovery flow. This applies to Okta and AD-sourced users only. To enable it, contact Okta Support.
- Voice Call: Send users who have forgotten their password a voice call with an audible password reset code.
- Email: Send users who have forgotten their password an email with a password reset code.
- Reset/Unlock recovery emails are valid for: Enter the number of minutes, hours, or days a recovery link remains valid before it expires. The values allowed for this field are:
  - 60–300000 minutes
  - 1–5000 hours
  - 1–208 days
Password recovery question complexity: Enter the minimum number of characters that the security answer must contain.
User accounts are locked after making five unsuccessful attempts to answer the password recovery question.
Click Create Policy.

Create a password policy rule

Optional. In the Admin Console, go to SecurityAuthentication.
Click the Password tab.
Click Add rule.
Complete these fields:
- Rule Name: Enter a name for the rule.
- Exclude Users: Start entering the name of a user that you want to exclude from the rule. As you enter text, Okta suggests usernames that match your text. Select the desired user from the list. Repeat for each additional user you want to exclude.
- IF User's IP is:
  - Anywhere: Apply the rule to all users regardless of whether their IP address is listed in the Public Gateway IPs list.
  - In zone: Apply the rule to users in all zones or in specific zones. Select the All Zones checkbox, or enter the specific zones you want to use in the Zones field.
  - Not in zone: Apply the rule to users outside all zones or specific zones. Select the All Zones checkbox, or enter the specific zones you want to use in the Zones field.
    See Network zones for information on the Public Gateway IPs list and the IP Zones features.
- THEN User can:
  - change password: Allow users to change their password and make the perform self-service password reset option available.
  - perform self-service password reset: Allow users who are unable to sign in, or who forgot their password, to perform self-service password resets and display the Forgot password? on the Sign-In Widget.
  - perform self-service account unlock: Allow users to unlock their account by clicking the Unlock account? link on the Sign-In Widget. When you select the self-service unlock option for LDAP-sourced Okta user accounts, the user account is unlocked in Okta, but it remains locked in the on-premises LDAP instance. If you don't allow self-service unlock, see Reset a user password.
Click Create Rule.

About lockouts

AD / LDAP Softlock

Okta can help prevent AD and LDAP-sourced users from getting locked out of their Windows account and hardware device due to too many failed Okta sign-in attempts. This feature also helps prevent a malicious third party from using Okta to lock out users.

To prevent Active Directory and LDAP lockouts, 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 and LDAP. For example, if the maximum number of failed Windows sign-in attempts is set to 10 in AD and LDAP, Okta recommends setting your maximum Okta failed sign-in limit to 9. If a user exceeds the sign-in limit set in Okta, additional failed attempts aren't sent to AD or LDAP. This prevents users from locking themselves out of their Windows account. In AD, locked out Okta users can use self-service account unlock or seek help from an Okta admin. Only admins can unlocked LDAP-sourced accounts.

Detect lockouts caused by unknown devices

Early Access release. See Enable self-service features.

Okta also prevents Okta-sourced users from getting locked out of their Okta accounts as a result of too many failed Okta sign-in attempts. This feature adds the ability to block suspicious sign-in attempts from unknown devices.

Okta can detect whether sign-in attempts are coming from a known or unknown device. A known device is one that has been previously used to sign in to Okta. An unknown device has never been used to sign in to Okta.

If Okta determines that the failed sign-in attempts are coming from an unknown device, Okta locks out new sign-in attempts from unknown devices. Okta still allows users to sign-in from known devices. This helps prevent malicious parties from disrupting Okta users' access to their accounts and enhances account protection.

The minimum lockout duration for lockouts triggered by unknown devices is two hours. If a legitimate user needs to sign in from a new device during this time, Okta initiates the self-service account unlock flow (if the org admin has enabled it). When the user unlocks the account, they're allowed to sign in from the new device.

Admins don't need to configure any settings to activate this feature.

Known limitations

Admins don't see user accounts on the Admin Console that were locked out due to unknown devices, and they can't unlock these accounts. To support users who lost a device and have a new one, Okta recommends that admins enable the self-service account unlock functionality so these users don't have to wait for the lockout duration to expire before they can access their account. See Self-service recovery options.