Desktop Single Sign-on troubleshooting

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.


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.


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.


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.

Note: 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.


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.


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)


not working
  • Ensure the host name of the server is resolvable from within the client network.

Note: The latest builds of Office 2016 and Windows 10 are incorporating their Web Account Manager (WAM) for sign-in workflows (see this Microsoft article). WAM requires https — it blocks non-https traffic during auth workflows.


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.
  1. On the same Windows 2008 R2 server that hosts your IWA Web agent, add the following values to the registry:

    2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\DisabledByDefault : 0 (DWORD)

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\Enabled : 1 (DWORD)

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\DisabledByDefault : 0 (DWORD)

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\Enabled : 1 (DWORD)

  2. Restart the server.