What Is Okta Agentless Desktop SSO?

How Does Okta ADSSO Work?

Prerequisites & Considerations

• 1

  Active Directory

  Agentless DSSO requires an on-premises Active Directory environment. If your organization does not have AD, this feature will not work. Consider Okta FastPass as an alternative for passwordless authentication from trusted networks or devices.

• 2

  Kerberos-Capable Network

  Your network must support Kerberos authentication. Most Windows domain environments already have this in place. Verify that your domain controllers are reachable from the machines that will use ADSSO.

• 3

  Domain-Joined Devices

  Windows machines must be joined to the domain. macOS devices must also be domain members — Agentless DSSO will not function on non-domain macOS machines.

• 4

  Browser Configuration

  Browsers on both Windows and macOS must be configured to support Kerberos authentication for your Okta org's kerberos subdomain.

Benefits of Okta Agentless Desktop SSO

Key Components & Process

• 1

  Service Account & SPN

  A dedicated Active Directory service account with a configured Service Principal Name (SPN) establishes secure communication between Okta and your AD environment.

• 2

  Key Distribution Center (KDC)

  The KDC on your domain controller issues Kerberos tickets when users log in. When Okta challenges for authentication, the user's browser presents the ticket to the KDC for validation.

• 3

  Okta Kerberos Subdomain

  Okta provides a dedicated kerberos subdomain (e.g., myorg.kerberos.okta.com) that the browser connects to for ticket exchange. This must be in the browser's Intranet Zone and in the Okta network zone configuration.

• 4

  IdP Routing Rule

  An updated Identity Provider routing rule directs authentication requests from the designated network zones through the Agentless DSSO path rather than the standard Okta login page.

Configuration Steps

• 1

  Create a Service Account & Configure the SPN

  Create a dedicated service account in Active Directory. Then open the command prompt and run the setspn command below — substituting your Okta org subdomain and service account name:

  setspn -S HTTP/<myorg>.kerberos.<okta|oktapreview|okta-emea|okta-gov.com>.com <ServiceAccountName>

  Domain administrator privileges are required to set the SPN. After this, add https://<myorg>.kerberos.<oktaorg>.com to the Intranet Site list in Internet Settings on every device that will use Agentless DSSO.

• 2

  Configure Browsers for Kerberos Authentication

  Both Windows and macOS browsers must be configured to support Kerberos authentication. On Windows, Internet Explorer and Edge pick this up automatically from Intranet Zone settings. Chrome and Firefox require explicit Kerberos policy configuration via Group Policy or MDM. On macOS, configure the browser to trust the Kerberos realm associated with your Windows domain.

• 3

  Enable Agentless DSSO in the Admin Console

  Navigate to the Okta Admin Console and go to Security > Delegated Authentication. Select your desired DSSO mode: Off, Test, or On. Iron Cove strongly recommends using Test mode first to validate configuration before rolling out to all users. Choose the Active Directory instance where you configured the SPN and supply the service account credentials.

• 4

  Configure Network Zones

  Add the network zones associated with the machines implementing Agentless DSSO. If Identity Provider (IdP) Discovery is enabled, these options are managed through IdP routing rules instead of the standard zones interface.

• 5

  Update the Default DSSO Identity Provider Routing Rule

  After enabling Agentless DSSO, update the legacy Desktop SSO Identity Provider routing rule to point to the agentless configuration. Manage this from Admin Console > Identity Providers > Routing Rules. This final step completes the configuration and activates agentless authentication for users in the defined network zones.

Troubleshooting Common Issues

• Not Being Routed to the ADSSO Endpoint

  Verify that your IP address is added to the correct network zone and that this zone is configured for ADSSO. Also confirm that your browser can reach the Key Distribution Center (KDC) on your domain. If connectivity is the issue, try connecting via VPN to join the network before testing again.

• Authentication Failures

  Double-check that the username and password for the SPN account are correct in both Active Directory and Okta's configuration. A single character mismatch between the two systems will cause all authentications to fail silently.

• Slow or Intermittent Sign-On

  If sign-on is slow or failing intermittently, you may need to increase the number of polling threads for your AD Agents, or add additional agents for your domains to distribute the load.

• Users in More Than 600 Security Groups

  Agentless DSSO does not work if a user belongs to more than 600 security groups. The Kerberos token becomes too large for Okta to process, resulting in a 400 response and redirect to the standard sign-in page. Audit group membership and remove unnecessary assignments for affected users.

• Weak Encryption (Windows 2008 or Below)

  Windows functional levels 2008 or below use RC4 encryption, which is considered less secure. For optimal security, upgrade to Windows Server 2008 R2 or above to use stronger encryption algorithms (AES-128/AES-256) with your SSO implementation.