Delegated Authentication (Delegated Auth) is an Okta feature that delegates the authentication process for Okta logins to on-premises Active Directory. When enabled, users sign into Okta using their AD credentials, and Okta forwards the authentication request to AD — which responds instead of Okta.
IMPORTANT
For Okta-mastered deployments, you will always disable Delegated Authentication. Leave it enabled only for AD-mastered deployments. See User mastery – MSP best practices for information about user mastery strategies.
How Delegated Auth affects authentication
The two diagrams below show how authentication flows differently depending on whether Delegated Auth is enabled or disabled.
Delegated Auth ENABLED
When Delegated Auth is enabled:
User logs into the Okta User Dashboard.
User credentials (username and password) are transmitted to the Okta AD Agent(s).
The Okta AD Agent(s) passes the credentials to the Domain Controller.
The Domain Controller authenticates the user.
The authentication response is transmitted back to Okta via the Okta AD Agent(s). A successful authentication results in the user being signed into Okta.
Delegated Auth DISABLED
When Delegated Auth is disabled, authentication is handled differently depending on whether the user is remote or local:
Remote users:
User logs into the Okta User Dashboard.
Okta authenticates the user directly. A successful authentication results in the user being signed into Okta.
Local users (on AD domain-joined machines):
User logs in to an AD domain-joined machine using their credentials.
The Domain Controller authenticates the user. A successful authentication results in the user being logged on to the AD domain-joined machine and signed into Okta via the Okta AD Agent.
Why disable Delegated Auth for Okta-mastered deployments?
Disabling Delegated Auth in an Okta-mastered deployment delivers significant advantages:
Authentication infrastructure resiliency — Okta's SLA guarantees 99.99% uptime. When Delegated Auth is enabled and on-premises AD goes down, account changes and password authentication will eventually fail, causing outages. With Delegated Auth disabled, Okta handles authentication independently.
User empowerment and lower IT burden — Users can reset their password in the cloud via Okta to regain access quickly and securely, without depending on AD infrastructure or IT intervention.
Authentication resiliency and future flexibility — When Delegated Auth is disabled, AD account passwords are stored securely in Okta. When Delegated Auth is enabled, no AD account passwords are stored in Okta — making a future migration away from on-premises AD significantly more disruptive.
When to consider enabling Delegated Auth
You should only consider enabling Delegated Auth — and deploying an AD-mastered strategy — if there is a strong business case for keeping password management within the confines of the organization's private network, and for not moving away from on-premises AD.
Example: An organization may require that password resets be performed only on AD domain-joined machines. In this case, those machines must have access to the Domain Controllers for password resets — and if the organization has a distributed workforce with many offsite machines, a VPN connection is highly recommended.
If you later need to switch from an AD-mastered to an Okta-mastered deployment, see Switch an AD-mastered Okta integration to Okta-mastered.