1️⃣
Agent placementInstall at least two AD Agents
One agent is a single point of failure for delegated authentication. Install a second on a different domain controller or member server for redundancy.
Windows Domain, Office 365, Apps, and Security
A working reference for connecting Okta to the rest of a hybrid environment: an on-premises Windows domain, Office 365, SaaS apps, and Azure. Covers how identity actually flows between these systems, how single sign-on and provisioning are wired up, how to enforce security policy, and what to check first when a sign-in or a sync job breaks.
Okta sits in the middle as the identity provider, but it rarely replaces on-premises Active Directory outright. In most real deployments, AD stays the source of truth for user accounts, Okta becomes the single sign-on and policy layer in front of everything, and Entra ID/Office 365 stays in the picture too, usually still handling mail attributes even when Okta owns authentication.
Okta reads users and groups out of on-prem AD through the AD Agent, applies its own sign-on and MFA policy, then either federates authentication to downstream apps directly or delegates password checks back to the domain controller.
| Question | Common answer |
|---|---|
| Who owns the login screen the user actually sees | Okta, once Office 365 and other apps are federated to it |
| Who still runs Conditional Access style policy for Office 365 itself | Both can, but organizations usually pick one as authoritative to avoid conflicting session controls |
| Why run both at once | Common after a merger or acquisition, or when Okta was adopted first and Entra ID/Intune arrived later for device management |
| What still needs Entra ID regardless | Intune device management and Exchange Online mailbox attributes still flow through Entra ID/Azure AD Connect even if Okta owns the sign-in experience |
Getting Okta to work with an on-premises Windows domain comes down to a small set of agents and connectors. Each one has a specific job, and most domain integration issues trace back to one of these being offline, misconfigured, or unable to reach a domain controller.
| Component | Job | Runs where |
|---|---|---|
| Okta AD Agent | Imports users, groups, and org units from AD into Okta's Universal Directory; handles delegated authentication back to the domain | Lightweight Windows service on a domain-joined server |
| Okta RADIUS Agent | Adds Okta MFA in front of RADIUS-based systems: VPN concentrators, network switches | Windows server with network line of sight to the RADIUS clients |
| Okta Windows Credential Provider | Adds Okta Verify MFA directly to the Windows login screen and RDP sessions | Installed on the endpoint itself |
| Okta Desktop SSO | Lets a domain-joined, network-connected device skip the Okta login prompt entirely using Kerberos | Configured via the AD Agent, works transparently on the LAN |
With delegated authentication, Okta never stores the AD password itself. When a user signs in, Okta passes the credential check through the AD Agent to a real domain controller in real time. This means a password change on-prem takes effect at Okta instantly, with no separate sync step, and it means an AD Agent outage directly blocks sign-in for anyone still using delegated auth (Okta cannot fall back to a cached password).
One agent is a single point of failure for delegated authentication. Install a second on a different domain controller or member server for redundancy.
The AD Agent makes outbound connections to Okta's service; there's no need to open inbound ports from the internet to the domain, which keeps the domain controller's attack surface unchanged.
Don't import every OU in the forest by default. Scope to the OUs that actually contain real user accounts, service accounts and disabled accounts don't belong in Okta's directory.
It uses IWA (Integrated Windows Authentication) through the browser; a device off the LAN or not domain-joined falls back to a normal Okta login prompt.
Federating Office 365 to Okta means Okta becomes the identity provider for sign-in, while Azure AD Connect (or Entra Cloud Sync) usually keeps running in parallel to handle mailbox and directory attribute sync. These are two separate jobs and it helps to keep them mentally separate: one moves attributes, the other decides who's allowed to log in.
| Step | What happens |
|---|---|
| 1. Domain federation | Convert the Office 365 domain from managed to federated, pointing sign-in at Okta's endpoint |
| 2. Immutable ID mapping | Match each on-prem AD object's immutable ID to the corresponding Entra ID object so accounts line up correctly |
| 3. Okta O365 app configuration | Set sign-on mode (WS-Federation is most common), configure the Office 365 tenant details in the Okta app |
| 4. Attribute sync stays separate | Azure AD Connect or Cloud Sync continues running for mailbox and group attributes regardless of who owns authentication |
Old protocols like POP, IMAP, and legacy SMTP can sometimes authenticate directly against Entra ID without going through the federated sign-in flow. Block legacy authentication at the Entra ID/Exchange level even when Okta is the primary IdP.
Okta's sign-on policy controls the Okta session; Entra ID/Office 365 has its own token lifetime settings. Misalignment between the two is a common cause of "I signed in but got logged out again five minutes later."
Converting the whole domain to federated is disruptive if something is misconfigured. Test with a single non-critical account and confirm sign-in end to end before rolling it out.
Not every app connects to Okta the same way. Picking the right protocol for the app you're onboarding decides how much automation you get, and how much manual account management stays behind.
| Protocol | What it does | Best for |
|---|---|---|
| SAML | Federated sign-on, no password shared with the app | Enterprise apps with native SAML support, most common modern integration |
| OIDC (OpenID Connect) | Modern token-based sign-on, built on OAuth 2.0 | Newer apps and custom-built applications |
| SWA (Secure Web Authentication) | Okta stores and auto-fills the app's own username/password | Legacy apps with no federation support at all |
| SCIM | Automated user provisioning and deprovisioning, separate from sign-in | Any app that supports it, pairs with SAML or OIDC for a full lifecycle solution |
Thousands of apps already have a pre-built integration in the OIN catalog with sign-on and provisioning already wired up. Building a custom SAML app from scratch should be the exception, not the default.
Email, first name, last name, and any app-specific role attribute all need to be mapped correctly before go-live; a wrong mapping shows up later as users landing in the wrong role or group inside the app.
Okta's sign-on policies are its equivalent of Conditional Access: rules built from conditions like network zone, device state, and risk signal, applied before a user is allowed in.
| Condition or control | What it does |
|---|---|
| Network zones | Define trusted IP ranges (office, VPN) versus everywhere else, and apply different rules to each |
| Device trust | Requires the device to be managed (enrolled and known) before allowing access to sensitive apps |
| Okta FastPass | Phishing-resistant passwordless authentication using a private key stored on the device, tied to Okta Verify |
| ThreatInsight | Blocks sign-in attempts from IPs Okta has identified as malicious across its entire customer base |
| Behavior detection | Flags sign-ins that deviate from a user's normal pattern (new location, new device, impossible travel) and can trigger step-up MFA |
Scope any new or tightened policy to a small pilot group, confirm real users can still sign in the way you expect, then widen it.
Store its credentials offline, monitor any sign-in on it closely, and never assign it MFA factors tied to a single person's device.
It's phishing-resistant by design, unlike SMS or even standard push notifications, which remain vulnerable to prompt-bombing without number matching enabled.
Okta Lifecycle Management automates the joiner, mover, and leaver process so access actually gets granted and revoked the moment HR data or group membership changes, instead of days later through a manual ticket.
| Stage | What triggers it | What happens |
|---|---|---|
| Joiner | New AD account created, or HR system feed adds a new employee record | Okta account activated, group assignments applied, downstream app provisioning fires automatically |
| Mover | Department, title, or manager attribute changes | Group membership rules re-evaluate, access to department-specific apps adjusts automatically |
| Leaver | AD account disabled, or HR marks the employee terminated | Okta account deactivated, SCIM-provisioned apps deprovision the user, active sessions revoked |
Keeps a group's membership synced one-way from Okta's Universal Directory to a connected app, useful when the source of truth for that group is already AD.
Rule-based membership using user profile attributes (department, title, location), similar in concept to a dynamic Entra ID group, evaluated continuously as attributes change.
Fast Okta API calls for the moment an account or a sync job needs attention right now.
curl -X POST "https://your-org.okta.com/api/v1/users/{userId}/lifecycle/unlock" `
-H "Authorization: SSWS {apiToken}"
curl -X POST "https://your-org.okta.com/api/v1/users/{userId}/lifecycle/suspend" `
-H "Authorization: SSWS {apiToken}"
curl -X POST "https://your-org.okta.com/api/v1/users/{userId}/lifecycle/reset_factors" `
-H "Authorization: SSWS {apiToken}"
curl -X DELETE "https://your-org.okta.com/api/v1/users/{userId}/sessions" `
-H "Authorization: SSWS {apiToken}"
Use immediately after a suspected account compromise, alongside a password reset and factor reset.
curl -G "https://your-org.okta.com/api/v1/logs" `
--data-urlencode "filter=actor.id eq \"{userId}\"" `
-H "Authorization: SSWS {apiToken}"
Get-Service -Name "OktaADAgentService" Restart-Service -Name "OktaADAgentService" -Force
Okta admin console: Directory > Directory Integrations > select the AD instance > Import > Import Now. There's no local PowerShell equivalent; the import is always triggered from the Okta side.
The issues that come up most often, with the fastest verified path to a fix.
| Symptom | Likely cause | Fix |
|---|---|---|
| All delegated authentication fails tenant-wide | Every AD Agent is offline or can't reach a domain controller | Check the OktaADAgentService status on each agent server; confirm network path and that the domain controller it targets is healthy |
| One user can't sign in but others can | Account locked, disabled, or password expired on-prem | Check the account status directly in Active Directory; delegated auth reflects the real domain state instantly |
| SAML assertion error on an app | Certificate expired, or attribute mapping doesn't match what the app expects | Check the SAML certificate expiration date in the app integration settings; re-verify attribute statements against the app's documentation |
| User exists in AD but not in Okta | Account sits outside the AD Agent's configured OU scope | Check which OUs are included in the Directory Integration's import settings |
| Office 365 sign-in loops back to Okta repeatedly | Immutable ID mismatch between the on-prem object and its Entra ID counterpart | Re-verify the immutable ID mapping for that specific user object |
| SCIM provisioning fails for a specific app | App-side API token expired, or a required attribute is missing from the user's profile | Check the Import and Provisioning logs for that app in the Okta admin console for the specific error returned by the app |
| Desktop SSO doesn't work for a specific device | Device isn't domain-joined, isn't on the trusted network zone, or Kerberos ticket issues | Confirm domain join state and that the device is on a network zone marked as trusted for Desktop SSO |
| User reports random extra MFA prompts | Behavior detection flagged the sign-in as anomalous, or a network zone boundary was crossed (VPN toggling on/off) | Check the System Log for that sign-in event to see which policy condition triggered the step-up |
The best places to go deeper on anything covered in this handbook: official documentation, protocol references, tooling, and community support.
The primary source for admin-facing setup guides, agent installation, and configuration reference.
Open ↗API guides, SDKs, and concept explainers for building and customizing Okta integrations.
Open ↗Full endpoint reference for the Users, Groups, System Log, and Lifecycle APIs used throughout the Quick Fixes tab.
Open ↗Searchable catalog of thousands of pre-built app integrations, the first place to check before building a custom SAML app.
Open ↗Live service health and incident history, check here first if sign-ins fail tenant-wide with no config change to explain it.
Open ↗Official user forum for admin questions, feature requests, and real-world configuration discussions.
Open ↗Install requirements, redundancy planning, and OU scoping for the AD Agent covered in the Windows Domain tab.
Open ↗Kerberos-based IWA setup so domain-joined, on-network devices skip the Okta login prompt.
Open ↗Adding Okta MFA in front of VPN concentrators and network switches that speak RADIUS.
Open ↗Step-by-step domain federation, immutable ID mapping, and sign-on mode configuration for Office 365.
Open ↗How SAML assertions, certificates, and attribute statements actually work, useful background for the App Integration tab.
Open ↗The provisioning protocol behind automated joiner, mover, and leaver lifecycle events.
Open ↗Token-based sign-on concepts for modern and custom-built application integrations.
Open ↗Phishing-resistant passwordless authentication tied to Okta Verify, covered in the Security tab.
Open ↗Cross-tenant malicious IP blocking and how it factors into sign-on policy evaluation.
Open ↗Automated provisioning and deprovisioning rules referenced in the Provisioning & Lifecycle tab.
Open ↗Manage Okta apps, groups, and policies as infrastructure-as-code instead of clicking through the admin console.
Open ↗No-code automation builder for lifecycle events and cross-app tasks that go beyond standard SCIM.
Open ↗Official SDKs, sample apps, and the CLI tool for scripting against the Okta API.
Open ↗Security advisories, compliance reports, and incident disclosures, useful for vetting Okta itself as a vendor.
Open ↗