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 available, join your network through a Virtual Private Network (VPN). 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)
- 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 details about how to configure IWA for this use case.
Tip: 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 dashboard > Tools > Internet 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.
(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.
During agent installation, if the error message displays,
Failed to store IWA config
. . . 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 whitelist.
Alternatively, if SSL certificate pinning is enabled you can disable it.
Disable SSL certificate pinning
- Perform steps 1 and 2 of the procedure Install the Okta IWA Web agent.
- Instead of double-clicking the file as directed in step 3, open a command line terminal and enter the following:
- Press Enter.
- Complete the installation. See Install the Okta IWA Web agent.
The request was aborted: Could not create SSL/TLS secure channelerror 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.
If your OktaIWA 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 OktaIWA 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.
- On the same Windows 2008 R2 server that hosts your IWA Web agent, add the following values to the registry:
- Restart the server.