About delegated authentication with Active Directory

When Okta is integrated with an Active Directory (AD) instance, delegated authentication is enabled by default. With delegated authentication, this is what happens when users sign in to Okta:

• Users enter their username and password in the Okta sign-in page.
• The sign-in page is protected with a security image to prevent phishing.
• Multifactor authentication (an extra security question or smart phone soft token) may also be enabled.
• The username and password are transmitted over the SSL connection implemented during setup to an Okta Active Directory (AD) agent running behind a firewall.
• The Okta AD agent passes the user credentials to the AD domain controller for authentication.
• The AD domain controller validates the username and password and uses the Okta AD agent to return a yes or no response to Okta.
• A yes response confirms the user's identity and they are authenticated and sent to their Okta homepage.

Delegated authentication maintains persistence for your directory authenticated (DelAuth) sessions and AD is maintained as the immediate and ultimate source for credential validation. As AD is responsible for authenticating users, changes to a user’s status (such as password changes or deactivations) are immediately pushed to Okta.

To retain delegated authentication functionality, the Access this computer from the network security policy setting must be assigned to domain users on the AD server where the Okta Active Directory (AD) agent is installed.