← Course Home
Okta Certified Administrator · Part I

Identity and Access Management

36% of the exam — the single largest domain.

Identity & Access Management

Module 1: Active Directory Integration

6 sub-topics · this deck covers sub-topic 4 of 6

← Back to Sub 3: Agent Service Account ↑ Module 1 Overview

The Exam Bullet

"Demonstrate knowledge of the requirements for Okta/AD password policies"

Password policy isn't one setting — it's a bundle of separate rules Okta enforces together. And once AD or LDAP becomes the source, some of those rules stop being Okta's decision at all.

The Mechanism

Password policy configuration lives under Security > Authenticators > Password. It's built from two layers: policies, which define the actual requirements, and rules, which define the conditions those requirements apply under plus any self-service options.

The Requirements — Complexity & Length

A policy can require combinations of uppercase, lowercase, numbers, and symbols, along with character restrictions. Password length can be set anywhere from 4 to 30 characters — but Okta's own recommendation is a minimum of 12.

The Requirements — Age & Lockout

History enforcement can remember between 1 and 30 previous passwords, blocking reuse. Policies also set a minimum age between changes and an expiration timeframe, plus a lockout rule: a threshold of failed attempts, paired with an auto-unlock duration.

The Requirement — Common Password Blocking

Every password is checked against a list of roughly 2.5 billion known common passwords — this check runs regardless of whether the complexity rules above are satisfied.

The Gotcha — AD/LDAP Changes the Rules

Once an account is AD or LDAP-sourced, expiration dates come from the directory itself, not from Okta's policy screen — Okta stops being the source of truth for that one setting.

This is also the practical reason behind Submodule 1's lockout rule: because Okta and AD track failed attempts as two separate systems, they need to be tuned relative to each other, not independently.

Self-service unlock works for Okta-sourced accounts — but an LDAP-sourced account still needs an admin to unlock it.

The Exam Angle

Watch for scenario questions built around these exact traps:

→ "A user's password never seems to expire, even though Okta's policy says it should." = account is AD-sourced; the directory owns expiration, not Okta.

→ "Lockouts in Okta don't match what AD is reporting." = lockout ratio isn't tuned between the two systems (see Sub 1).

One Line To Remember

Password policy = policies (requirements) + rules (conditions/self-service), configured under Security > Authenticators > Password. Complexity, 4-30 char length (12+ recommended), 1-30 password history, lockout with auto-unlock, and a 2.5-billion-password common-password check. For AD/LDAP-sourced accounts, the directory — not Okta — owns expiration, and LDAP-sourced lockouts need an admin to clear.

Sources: help.okta.com — configure-password.htm