36% of the exam — the single largest domain.
6 sub-topics · this deck covers sub-topic 2 of 6
← Back to Sub 1: Delegated Authentication ↑ Module 1 OverviewThe Okta Agent is the piece of software that actually sits inside the customer's network and talks to Active Directory or LDAP on Okta's behalf. This sub-topic isn't about installing it once — it's about designing that bridge so it stays reliable, and knowing the exact network requirements it depends on.
The agent acts as a bridge between Okta's cloud and the customer's real Active Directory. It imports users from AD into Okta, and it can push provisioning changes back the other direction, writing updates from Okta into AD.
A single agent can be registered to handle multiple domains at once, and AD can optionally be designated as the authoritative profile source for those users.
Install two or more agents per domain, and put them on separate physical servers — not consolidated onto one box. That's the actual minimum for failover protection, not just a nice-to-have.
This is the same fragility we already saw in Submodule 1: delegated authentication depends entirely on agent availability. Too few agents means the exact same queue-and-bottleneck problem, whether the login is a normal sign-in or a delegated-auth request.
Admins don't have to guess whether an agent is working. In the Admin Console dashboard, a green circle next to the agent's name means it's connected and healthy right now.
That single visual check is the fast way to confirm the HA setup above is actually functioning, not just installed.
If the agent is deployed on a server sitting in the DMZ, it needs a specific set of ports opened to reach the domain controller. Miss one, and something in the AD integration quietly breaks.
This range is the part almost everyone misses. Port 135's Endpoint Mapper doesn't do the work itself — it just tells the RPC client which dynamic port was assigned for the actual conversation. If that high port range (49152-65535) isn't open, the agent can still reach 135 fine, but the real communication silently fails anyway.
Watch for scenario questions built around these exact traps:
→ "One agent is configured for the entire domain, no backup." = HA best-practice violation.
→ "Agent shows healthy, but user imports and provisioning fail from a DMZ deployment." = missing the dynamic RPC port range.
→ "How do you confirm an agent is actually working?" = the green circle in the dashboard.
Sources: help.okta.com — ad-agent-install-multiple.htm · ad-agent-manage-integration.htm · ad-agent-install-dmzports.htm
Next: Sub 3 →