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 additional 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 new password policy
- In the Admin Console, go to Security > Authentication.
- 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 name of the group(s) to which the policy will apply.
- Okta: select this option to create an Okta password policy.
- Active Directory: select this option to create an Active Directory (AD) password policy.
- LDAP: select this option to create an LDAP password policy.
- Complete these fields in the Password Settings section:
- Minimum length: enter a minimum password length of four to 30 characters (the default minimum is eight characters). For Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) sourced users, these requirements are set and enforced by AD and LDAP. Ensure that the settings here duplicate the minimum settings of AD and LDAP. The maximum number of characters that Okta stores is 72.
- Complexity requirements: select any or all of the 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 of time. 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 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. Users do not receive an expiration warning if the value is fewer than six days.
- Prompt user: Enter 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. Users do not receive an expiration warning when the value is less than six days.
For AD and LDAP sourced users: The Password expires after setting doesn't appear. The expiry date can vary and is imported from AD and LDAP.
- 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 below.
- Account is automatically unlocked after: enter the number of minutes 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 isn't enabled by default.
- Show lock out failures: select this option 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.
- Send a lockout email to user: select this option to 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 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 email and select The user can perform self-service account unlock.
If you selected Active Directory as the authentication provider, you may select these options:
- Unlock users in Okta and Active Directory: select this option to unlock user accounts in AD and Okta.
- Unlock users in only Okta: select this option to unlock user accounts in Okta.
- Self-service recovery options: select these options:
- SMS: select this option to send users who have forgotten their password a text message with a password reset code.
- Voice Call: select this option to send users who have forgotten their password a voice call with an audible password reset code.
Email: select this option to 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 to 300000 minutes
- 1 to 5000 hours
- 1 to 208 days
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 first day of the upcoming month.
The password 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.
- Password recovery question complexity: enter the minimum number of characters the security answer must contain.
- Click Create Policy.
Create a password policy rule
- Optional. On the Password tab of the Authentication page, scroll down and click Add Rule.
- Complete these fields:
- Rule Name: Type a name for the rule.
- Exclude Users: Start typing the name of a user 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 or not 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 make the Forgot password? link appear 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.
AD / LDAP Soft Lock
Okta provides a feature to 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 an end-user exceeds the sign-in limit set in Okta, additional failed attempts are not sent to AD or LDAP, and 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. Locked LDAP-sourced accounts can't be unlocked by users and must be unlocked by an admin.
This is an Early Access feature. To enable it, use the Early Access Feature Manager as described in Manage Early Access and Beta features.
Okta also lets you prevent 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 login attempts from unknown devices.
Okta can detect whether sign-in attempts are coming from a known device (for example, a browser the user has previously used when signing in to Okta), or unknown devices (a device that has never been used to sign in to Okta before). 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, but allows sign-ins 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 unless the admin configures a custom duration. 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 will be allowed to sign in from the new device.
Admins won't see user accounts on the Admin Dashboard that have a lockout on them caused by an unknown device, and they won't be able to unlock these accounts. To enable those users who may have lost their devices to log in, and who may only have access to a new device, 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.