Desktop Single Sign-on troubleshooting
With Agentless DSSO enabled, you browse to your Okta tenant and see the regular sign in page
You were not routed to the Agentless DSSO endpoint. Confirm your IP address is added to the correct zone and that zone is used for the Agentless DSSO.
I am working remote and Agentless DSSO doesn't work
In order for Agentless DSSO to work your browser must be able to connect to the Key Distribution Center (KDC) on your domain. This is crucial to the Kerberos validation. If you are unable to reach the KDC you will not obtain a Kerberos ticket and will not be able to authenticate. If a Virtual Private Network (VPN) is available, use it to join your network. If the KDC is available through the VPN, Agentless DSSO will work.
I am in the right zone and on-prem and Agentless DSSO still fails
Confirm the username and password are correct for the SPN account both in AD and as stored in the Okta configuration. If the account expired or was changed it will break the flow.
I have verified I am in the correct zone, verified the account used for the SPN is correct, I am on-premises and Agentless DSSO still fails
This could suggest some type of Kerberos failure. Using tools such as Wireshark, capture your network traffic during your Agentless DSSO attempt. Once captured, filter for Kerberos traffic. Compare this traffic to the Event Viewer logs on your KDC. Using these two tools (or similar) you should be able to uncover Kerberos failures.
In order to see debug-level Kerberos events you may need to enable Kerberos event logging. For more information, see https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging.
Kerberos validator and sign-in failure
If the clock skew between your corporate network and Okta Agentless SSO becomes too great, Kerberos validation and sign-in will fail. This issue will not occur if your domain controller's clock is synced to an external time server.
Slow or failed sign-on experience
During Agentless DSSO sign-in Okta does a SID look-up. During the EA time frame this is being done with a call to the AD Agent. If you experience a slow sign-in experience or failed sign-ins consider increasing the number of polling threads for your AD Agents or adding new AD Agents for your domains. For details on how to do this, see Install multiple Okta Active Directory agents and Change the number of Okta Active Directory agent threads.
If this occurs, you will see the AD Agent logs filled with a large number of read LDAP calls, without any Next action = NONE lines shown. For example:
2018/06/11 23:14:34.441 Debug -- N079-H076(57) -- Sending result for READ_LDAP action (id=ADS2n15k1yGW23cn10g7) finished, (executionTime=00:00:00.2196026)
Desktop SSO not working
Ensure the host name of the server is resolvable from within the client network.
What do I do when I receive the The request was aborted: Could not create SSL/TLS secure channel error message?
Your OktaIWA Web agent may go offline and the error The request was aborted: Could not create SSL/TLS secure channel can appear if your OktaIWA Web agent is:
- Installed on a server running Windows Server 2008 R2 SP1, and
- Configured to use HTTPS, and
- Configured for Automatic Fail over.
- On the same Windows 2008 R2 server that hosts your IWA Web agent, add the following values to the registry:
- Restart the server.