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 1 of 6

The Exam Bullet

"Enable and manage delegated authentication with AD and LDAP using Okta agents"

A company already has real Active Directory or LDAP accounts. They don't want two separate password systems. This sub-topic is about how Okta lets people log in with their existing AD/LDAP password — without Okta ever storing a copy of it.

The Mechanism

When a user tries to sign in, Okta doesn't check its own password store. Instead it forwards the login attempt to the customer's real AD or LDAP server through the Okta Agent, and asks one question: "is this password correct?" Okta trusts whatever answer comes back.

That's what "delegated" means — Okta delegates the actual authentication decision to the directory that already owns the password.

The Default Behavior

LDAP → delegated auth is ON by default the moment you add an LDAP integration.

AD → must be explicitly enabled and managed via Security > Delegated Authentication.

This asymmetry is a classic place for an exam question to trip you up.

The Requirement Everyone Forgets

Letting users reset an expired password through delegated auth isn't automatic. Two things have to be true first:

1. The Okta LDAP Agent must be version 5.3.0 or later.

2. The directory must support the pwdReset attribute, so Okta actually knows a password has expired and must be changed at next login.

The Lockout Trap

Okta and AD each track failed login attempts separately. If their thresholds don't line up, users get confusing lockouts that don't match what IT sees in AD.

Rule of thumb: set Okta's lockout limit to no more than half of the AD/LDAP lockout limit.

Also: self-service unlock works for Okta-sourced accounts — but an LDAP-sourced account needs an admin to unlock it.

The Connection to JIT

Delegated authentication isn't just about logins — it's the gatekeeper for Just-In-Time (JIT) provisioning.

A brand-new AD user, never imported into Okta, signs in for the first time. Delegated auth confirms the password against AD. Because it succeeded, Okta silently creates the user's profile right then — no activation email sent.

No delegated auth → no JIT. They're a package deal.

The Reliability Risk

Every delegated-auth login has to round-trip through an Okta Agent to reach AD/LDAP. If there aren't enough agents for the login volume, requests queue up — real users experience slow or failed logins.

This is why the exam tests agent high-availability as its own related topic later in this same module.

The Exam Angle

Watch for scenario questions built around these exact traps:

→ "New AD users can log in, but nothing shows up in Okta until they do." = JIT + delegated auth.

→ "Users report random lockouts that don't match AD." = lockout ratio misconfiguration.

→ "Password reset doesn't work over delegated auth." = check agent version / pwdReset support.

One Line To Remember

Delegated auth = Okta asks AD/LDAP "is this password right?" instead of storing it. LDAP: on by default. AD: manual. Needs agent v5.3.0+ for resets. Set Okta's lockout ≤ half of AD's. It's the prerequisite for JIT.

Sources: help.okta.com — Security_Authentication.htm · configure-password.htm · ad-agent-add-update-JIT.htm

Next: Sub 2 →