Delegated Authentication with Active Directory

AD Delegated Authentication Overview

Okta’s AD integration automatically turns on delegated authentication. That is, user sign in attempts to will be checked against Active Directory for authentication. UsersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. can then easily log into Okta using their Okta username and active directory password.

More specifically, the process is:

  1. The user types username and password in the Okta end user home page. This sign in page is protected with SSL and a security image to prevent phishing; multi-factor authentication (extra security question or smart phone soft token) can be enabled as well.
  2. The username and password are transmitted to an Okta AD AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. running behind the firewall over the SSL connection that had previously been established during setup.
  3. The Okta AD agent passes those credentials to the AD DomainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). Controller for authentication.
  4. The AD Domain Controller responds with yes/no answer, validating the username and password.
  5. The yes/no response is transmitted back to the Okta service by the Okta AD Agent. If yes, the user is authenticated and sent to their Okta homepage.

Because this feature governs user access into Okta, the architecture supports multiple Okta AD Agents running in your environment to provide higher throughput and redundancy. If one of the Okta AD Agents stops running or loses network connectivity, the authentication requests are automatically routed to the other Okta AD Agents.

With this authentication method, we internally maintain persistence for your directory authenticated (DelAuth) session, and Active Directory is maintained as the immediate and ultimate source for credential validation. Because AD is always relied upon for user authentication, changes to the user’s status (such as password changes or deactivations) are reflected immediately in the Okta service.