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 on the Okta sign-in page.
- Users are prompted to enter their secondary email on their first sign-in attempt.
Secondary email is important for password recovery. This applies in particular when the Okta password and the primary email password are the same, which is common for AD users.
- 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 response to Okta.
- A yes response confirms the user's identity. The user is then 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.
You can retain delegated authentication functionality by assigning the Access this computer from the network security policy setting to domain users on the AD server where the Okta Active Directory (AD) agent is installed.