Configure the password authenticator (2024)

This authenticator lets you enforce the use of passwords when users sign in to Okta or an app. You can customize complexity requirements, apply password rules to groups or individuals, and set lockout conditions. End users can reset forgotten passwords without the aid of a help desk.

The password authenticator is active by default for Okta users. To use the password authenticator, you have to configure a password policy and rules.

This authenticator is a knowledge factor and fulfills the requirements for user presence. See Multifactor authentication.

Before you begin

• Create groups if you want to use them in a password policy. See Manage groups.
• Create network zones if you want to use them in a password policy. See Configure a network zone.

Add a password policy

1. In the Admin Console, go to SecurityAuthenticators.

2. On the Setup tab, click ActionsEdit for the Password item.
3. Click Add New Password Policy.

Configuration options

1. Set the conditions for your password policy:

   Field	Value
   Policy name	Enter a descriptive name for this policy.
   Policy description	Enter a description of what this policy does, and to whom it applies.
   Add group	Enter the groups of users that this policy applies to.
   Applies to	Select the authentication provider.
   Minimum length	Require a minimum number of characters in passwords. The minimum length is four characters. The maximum length is 30 characters.
   Complexity requirements	Require various character types and other attributes to make passwords more complex. You can use Active Directory password requirements if you have AD-sourced users.
   Common password check	Prevent users from choosing commonly used passwords like "Password" and "11111111". Okta checks the user's password choice against the list of 1 million commonly used passwords. Combined with case-sensitive matching, this list covers over 2.5 billion common passwords.
   Password age	Configure how long users can use passwords, how often they can reuse them, and when they're prompted to change their password. The minimum age is 0 (zero) days, and the maximum age is 999 days.
   Lock out	Configure these options: The number of times an incorrect password can be entered before the account is locked. How long the account remains locked. Send users a lockout failure email when their account is locked. See Block suspicious password attempts from unknown devices To prevent AD and Lightweight Directory Access Protocol (LDAP) lockouts, verify that the number of unsuccessful attempts is lower than the failed sign-in attempt limit configured in AD and LDAP.

2. Click Create Policy.
3. Select the policy in the policy list.
4. Click Add Rule.

5. Configure the following options:

   Field	Value
   Rule name	Enter a name for the rule.
   Exclude users	Enter the names of the users that 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 IP list. In zone: Apply the rule to users in all or specific network zones. Not in zone: Apply the rule to exclude users in all zones or in specific zones. See Network zones for information on the Public Gateway IP list and other IP Zones features.
   THEN User can perform self-service	Password change (from account settings): Allow users to change their password with the perform self-service password reset option. Password reset: Allow users to perform self-service password resets through the Forgot password? link on the Sign-In Widget. Unlock account: Allow users to unlock their account by clicking the Unlock account? link on the Sign-In Widget. When you select this option, LDAP-sourced Okta user accounts are unlocked in Okta but remain locked in the on-premises LDAP instance. If you don't allow self-service unlock, see Reset a user password for other options.
   AND Users can initiate recovery with	Okta Verify (push notification only): Allow users to initiate recovery with Okta Verify push notifications. See Configure the Okta Verify authenticator. Phone: Allow users to initiate recovery with either text messages or voice phone calls. See Configure the phone authenticator authenticator. Email: Allow users to initiate recovery with an email message that contains a one-time password or a magic link. See Configure the email authenticator. Google Authenticator: Allow users to initiate recovery with a one-time passcode from Google Authenticator. See Google Authenticator.
   AND Additional verification is	Not required: Don't require additional verification from users during recovery. Any enrolled authenticator used for MFA/SSO: Allow users to use any enrolled authenticator for recovery. Only Security Question: Only allow users to use a security question for recovery. See Configure the security question authenticator. Admins can determine whether an authentication challenge must be completed before the user enters their password. In an authentication policy rule, configure the AND User must authenticate with option. See Add an authentication policy rule.

6. Click Create rule.

Add the password authenticator to the authenticator enrollment policy

1. In the Admin Console, go to SecurityAuthenticators.

2. Click the Enrollment tab.
3. Add the authenticator to a new or an existing authenticator enrollment policy. See Create an authenticator enrollment policy.

Edit or delete password policies and rules

You can't edit or delete the password authenticator, but you can edit or delete the policies associated with it. Before you edit or remove policies from this authenticator, you may have to update existing authenticator enrollment, authentication, and global session policies that use this authenticator.

1. In the Admin Console, go to SecurityAuthenticators.

2. On the Setup tab, click ActionsEdit for the Password item.
3. Select a policy from the list to see its Edit and Delete options.
4. Select a rule in the policy to see its options. To edit, click the pencil icon. To delete, click X.

End-user experience

End users are always prompted for a password unless an authentication policy rule for passwordless authentication is enabled. In AD, locked-out Okta users can use self-service account unlock, but only an admin can unlock a locked LDAP-sourced account.

Related topics

Self-service account recovery

Multifactor authentication