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/IWA not working

  • Ensure the host name of the server is resolvable from within the client network.
  • IWA must be turned on in both the IIS authentication configuration and in the client.
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.

Refer to Configure SSL for the Okta IWA Web agent for details about how to configure IWA for this use case.

If you have installed the Okta IWA SSO agent and used the same Okta Service account that was used to install the Okta AD agent, then you must also change the Okta Service account password in the IIS Server Manager dashboardToolsInternet Information Services (IIS) Manager when you change the OktaService account password in AD.

The Okta IWA service is installed under the Application Pools menu. Under Advanced Settings you can change the Okta Service password to match the new password. Due to caching, the IWA service may not stop immediately. When the cache does reset, IWA will stop working if the OktaService password has not been updated here to match the password you reset in the Active Directory Users and Computers tool and the Services console on the server the agent is installed upon.

IWA not functioning after a server restart or Group Policy changes

(The Okta IWA service account requires Logon as a Batch Job and Log on as a Service permissions. Ensure the service account has these permissions.

What do I do when I receive the The request was aborted: Could not create SSL/TLS secure channel error message?

Your Okta IWA Web agent may go offline and the error The request was aborted: Could not create SSL/TLS secure channel can appear if your Okta IWA Web agent is:

  • Installed on a server running Windows Server 2008 R2 SP1, and
  • Configured to use HTTPS, and
  • Configured for Automatic Fail over.

If your Okta IWA Web agent is installed on a server running Windows Server 2008 R2 SP1 and you want to use SSO IWA over secured connections (HTTPS), you must first enable the TLS 1.2 protocol for incoming (e.g. IIS) connections. This is necessary because the Okta Active Directory (AD) agent which tries to use TLS 1.2 whenever possible, may lose connectivity with Okta IWA Web agent installed on Windows Server 2008 R2 SP1 servers that are not enabled for TLS 1.2 incoming connections. Windows Server 2008 R2 SP1 supports TLS 1.2 protocol outgoing connections by default. However, support for incoming connections is disabled by default. Okta strongly recommends enabling this setting.

  1. On the same Windows 2008 R2 server that hosts your IWA Web agent, add the following values to the registry: 

    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.

Failed to store IWA config error when installing the agent

During agent installation, if the error message displays, then you are probably attempting to install a version of the Okta IWA Web agent in which SSL pinning is enabled by default and your environment is one in which the agent's support for SSL certificate pinning prevents communication with the Okta server. This is most likely to occur in environments that rely on SSL proxies. To allow installation to complete in this case, Okta recommends that you bypass SSL proxy processing by adding the domain okta.com to a allowlist.

If SSL certificate pinning is enabled use this procedure to disable it:

  1. Complete steps 1 and 2 of the procedure Install the Okta IWA Web agent.
  2. Open a command prompt and enter the following command: OktaSsoIwa.exe OktaDisableSslPinning=1
  3. Press Enter.
  4. Complete the installation. See Install the Okta IWA Web agent.