This guide provides steps for troubleshooting if Agentless Desktop Single Sign-On (ADSSO) does not work after initial setup.

• Agentless Desktop Single Sign-On (ADSSO)

Agentless Desktop Single Sign-On (ADSSO) is not working after initial configuration is typically due to misconfiguration in one of three areas:

• browser/client configuration
• service account properties
• routing rule settings

Browser/Client Configuration

1. Ensure that the org Kerberos URL (https://<org>.kerberos.<okta|oktapreview|okta-emea>.com) is configured as a local intranet site in any client browser attempting ADSSO.
   • Replace <org> with the Okta subdomain, and <okta|oktapreview|okta-emea> with the appropriate value. See an example of a Kerberos URL added to Local Intranet sites below. Specify the full URL and do not use wildcards (example: *.kerberos.okta.com) when setting the local intranet site value.

1. • Adding the URL to Trusted Sites is not sufficient in most environments. The URL needs to be added to "Local intranet" or "Zone 1". Additionally, other browsers may have additional requirements. Please see Configure browsers for agentless Desktop Single Sign-on on Windows for more information.
2. Ensure that the Kerberos URL specified is accessible from the machine performing Agentless DSSO. In a Windows Command Prompt or Mac Terminal, run nslookup <org>.kerberos.<okta|oktapreview|okta-emea>.com to confirm successful DNS resolution.

3. Verify that Automatic Log-on or Integrated Windows Authentication is enabled in the browser settings. 
   1. Open Internet Properties, select Security > Local Intranet > Custom Level, and User Authentication.
   2. Ensure Automatic log-on only in Intranet Zone is selected.
4. 

4. Modern Chromium-based browsers such as Google Chrome and Microsoft Edge do not rely solely on Internet Explorer zone settings and may require an explicit allowlist configuration to permit integrated authentication.
   • As described in Configure browsers for agentless Desktop Single Sign-on on Windows, configure the AuthServerAllowlist policy for browsers to include the Okta Kerberos endpoint.

Google Chrome Registry example: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "AuthServerAllowlist"=<org>.kerberos.<okta|oktapreview|okta-emea>.com

Microsoft Edge Registry example: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge] "AuthServerAllowlist"=<org>.kerberos.<okta|oktapreview|okta-emea>.com

If this change is applied in Windows via Group Policy, be sure to run gpupdate/force on the client machine and fully close and reopen the browser. To confirm the setting has been applied to the machine, access chrome://policy or edge://policy in the browser.

5. To verify that a Windows client is successfully retrieving a valid Kerberos ticket:
   1. Open Command Prompt and run the command klist purge to delete all cached Kerberos tickets.
   2. Attempt Okta ADSSO login, then return to Command Prompt and run "klist" to display all tickets for the currently logged on user.
   3. Successful ticket retrieval will show a ticket for HTTP/<org>.kerberos.<okta|oktapreview|okta-emea>.com.

Service Account Properties

• Use a dedicated service account configured with the SPN for ADSSO in Active Directory. Please ensure that each step in the Create a service account and configure a Service Principal Name document was followed for this process, including the specified encryption configuration within Active Directory.

Routing Rule Settings

• Verify that the Default Route to AgentlessDSSO routing rule is active and properly scoped for the network users who will connect to while using ADSSO. Routing rules can be found in the Okta Admin dashboard under Security > Identity Providers > Routing Rules.

In-Depth Situational Troubleshooting

Below are two common scenarios that may be encountered if ADSSO fails:

1. During the ADSSO flow, a browser pop-up prompts for credentials (the UX differs between Chrome and Edge).

Solution: Allowlisting the necessary site in the Intranet zone is not properly configured. See the instructions above under "Browser/Client Configuration" to address the issue.

2. Authentication flow redirects /login/default or to Integrated Windows Authentication (IWA) (on Okta Classic and if IWA is enabled in the org):

Solution: Ensure the device is on the domain network and can reach the KDC to obtain a Kerberos ticket. If the issue persists, a Fiddler trace (capturing HTTPS traffic) is recommended to ensure a Kerberos ticket is returned rather than an NTLM response. NTLM will fail the authentication flow as described in NTLM vs KERBEROS documentation. The Fiddler trace can be used to determine the response type based on the initial characters of the token itself. Kerberos tickets will begin with "YII" while NTLM responses will begin with "TIR" as shown below.

 

If an NTLM response is returned, it will be necessary to determine why the KDC does not return a Kerberos ticket in response to the Kerberos challenge. The following steps may be helpful in this process:

1. 1. Follow the steps in How to enable Kerberos event logging to capture Kerberos events in Event Viewer. These events will often reveal an error that can be researched for further information.

As an example below, an Okta feature is missing for the organization, causing subdomain.kerberos.okta.com to resolve to an address similar to the screenshot below. Contact support to resolve the dependency.

1. 2. Capture a Wireshark trace during an ADSSO attempt.

In the example below, DES is the only selected encryption type on the SPN account in Active Directory, but AES is required for ADSSO operation.

NOTE: It will be necessary to research each error to determine the underlying issue. Some errors can safely be ignored, as described in this Microsoft article.

Related References

• Agentless DSSO is not working on Chrome
• What are the known limitations of Active Directory Desktop Single Sign-on?
• 400 Error when attempting to authenticate via ADSSO
• What does "Kerberos validation failed with result=GSS_ERROR" in the system logs mean
• In DSSO - How do we modify SPN for Service Account
• Agentless DSSO not working after setting AES Encryption on the Service Account