Delegated Authentication with Active Directory

AD Delegated AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. Overview

Okta’s AD integration automatically turns on delegated authentication. That is, user sign in attempts to will be checked against Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. for authentication. Users 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.