← 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 5 of 6

← Back to Sub 4: Password Policies ↑ Module 1 Overview

The Exam Bullet

"Demonstrate knowledge of user activation options when using AD as a source"

When AD is the source, a user doesn't just "appear" active in Okta. There's a real path from existing in AD to being active in Okta — and admins have choices over how that path plays out.

The Mechanism — Two Activation Paths

The standard path: AD-sourced users don't get sent Okta's usual activation email, and an admin manually activates them instead.

The other path is Just-In-Time provisioning, covered back in Submodule 1 — the profile is created (and later updated) automatically the moment a user successfully authenticates against AD, no admin step required.

The Mechanism — Import Matching Rules

When AD users are imported, Okta has to decide whether an incoming record matches an existing Okta user. There are three settings for this:

Auto-confirm exact matches — username, email, or a specified attribute lines up exactly.

Auto-confirm partial matches — first and last name match, even if username or email differ.

Manual confirmation — if neither auto-confirm option is on, an admin has to verify the match by hand on the People page.

The Mechanism — Account Status Propagation

The "Profile & Lifecycle Sourcing" settings decide how deactivation and reactivation move between the two systems.

When a user is deactivated in Okta, the admin chooses what happens in AD: deactivate the AD account, suspend it, or leave it unchanged. Going the other direction, reactivating a user in AD can be configured to restore a suspended or deactivated Okta user.

The Gotcha — Incremental Import Timing

Users and groups are tracked separately during incremental imports. That means a user who was just imported can temporarily have incomplete group memberships — the user record landed, but their groups haven't fully caught up yet.

JIT sidesteps this entirely: since the profile (and its group data) gets built at the moment of first login instead of waiting on an import cycle, there's no partial state to land in.

The Exam Angle

Watch for scenario questions built around these exact traps:

→ "A newly imported AD user exists in Okta but is missing from groups they should be in." = incremental import timing gap, not a real misconfiguration.

→ "Two AD records with different usernames got merged into one Okta profile." = partial-match auto-confirm behavior (first/last name matched).

One Line To Remember

Two activation paths: admin manually activates AD-sourced users, or JIT auto-creates them at first login. Import matching = exact auto-confirm, partial (name-based) auto-confirm, or manual. Profile & Lifecycle Sourcing settings control deactivation/reactivation propagation both directions. Incremental imports can leave a new user's groups temporarily incomplete — JIT avoids that gap entirely.

Sources: help.okta.com — ad-agent-configure-import.htm · ad-agent-manage-integration.htm