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

← Back to Sub 2: Agent Architecture ↑ Module 1 Overview

The Exam Bullet

"Manage Okta agent service account and permissions need for agents and in directories for password reset"

The agent we just covered has to actually log into Active Directory to do its job — imports, provisioning, password resets. It does that as a real AD account. This sub-topic is about what account that should be, and exactly which permissions it actually needs.

The Mechanism

If you don't pick an existing account during setup, the installer creates a default one for you called "OktaService." Out of the box, it inherits its permissions simply from being a member of the Domain Users group — nothing special yet.

That default membership alone isn't enough for the agent to actually read AD data properly — one more base permission has to be added on top of it.

The Base Requirement

Every Okta AD agent service account needs one of these two, in addition to Domain Users membership:

Membership in "Pre-Windows 2000 Compatible Access" group
— OR —
Explicit "Read all permissions for all synchronized AD objects"

The Gotcha — Least Privilege

The obvious shortcut is to just make the service account a Domain Admin so nothing ever breaks. That's exactly the wrong move.

Avoid making the service account a full admin — assign only the specific permissions each use case actually requires.

The exam frames this as a security judgment call, not just a technical checklist.

The Requirement — Provisioning

If the agent is going to create and remove users in AD (not just read them), it needs targeted permissions on the specific Organizational Unit (OU) where those users live:

Create Child permission for user objects on the target OU
Delete Child permission for user objects on the target OU

The Connection — Password Reset

Submodule 1 established that delegated-auth password resets need agent v5.3.0+ and a directory supporting the pwdReset attribute. This is the AD-side permission that actually makes that possible.

The service account needs the "Reset Password" control access right for user objects in the target OU, plus Write Property permission on two specific attributes: pwdLastSet and lockoutTime.

Without Write access to those two attributes specifically, password resets and unlock operations will fail even if every other permission is correct.

The Exam Angle

Watch for scenario questions built around these exact traps:

→ "Agent can import users but password reset silently fails." = missing Reset Password right or Write Property on pwdLastSet/lockoutTime.

→ "Security team flags the service account during an audit." = it was made a Domain Admin instead of using least-privilege permissions.

→ "New users aren't being created in AD from Okta provisioning." = missing Create Child permission on the target OU.

One Line To Remember

Default service account = "OktaService," starts with just Domain Users. Add Pre-Windows 2000 Compatible Access (or explicit Read all permissions) as the base. Never make it a Domain Admin — grant only what's needed: Create/Delete Child for provisioning, Reset Password + Write Property on pwdLastSet/lockoutTime for password reset.

Sources: help.okta.com — ad-agent-about-service-account.htm

Next: Sub 4 →