Desktop Single Sign-on FAQ
Yes. When both are enabled and the user tries to sign in, Okta first tries authenticating against Agentless DSSO and if that fails, it falls back to the on-prem IWA server.
No. You need to be on-network to sign in through Agentless DSSO. However if using a VPN, Agentless DSSO will work.
Yes. In order for Agentless DSSO to work, the computer needs to be domain joined.
No. Agentless DSSO removes the need to have any IWA agents on your machines. Instead, the Kerberos validation is done on the Okta servers.
No that's expected. When the end user goes to the browser and types in <myorg>.okta.com, Okta sees your org has Agentless DSSO enabled and kicks off a 401 authenticate challenge to your KDC which then returns a Kerberos ticket back to Okta.
No. Okta uses the user SID to locate and authenticate the user. So it shouldn't matter if they don't match because the request resolves to the user object using SID.
The current rate limit for the Agentless DSSO endpoint /login/agentlessDSSO is 1000/minute. This is double the on-prem rate limit as described in Concurrent Rate Limits because each successful login performs two http commands to the Agentless DSSO endpoint. The number of successful logins per minute will be the same as on-prem IWA.
To provide high availability, you can install multiple Okta IWA Web agents on separate servers. Installing multiple web agents in close geographical proximity to your users may improve performance when combined with regional load balancing technologies. One example is having DNS netmask ordering enabled.
To get the latest agent release, in the Admin Console go to Settings > Downloads.
You do not need to uninstall existing agents prior to upgrading to a new agent. The installer keeps copies of all previous configurations, renaming existing Web.config file with a time stamp suffix (for example, web.config.636531690091372202).
After updating the agent you must port any previous custom edits to the new config file.
During the upgrade process the agent will not be able to handle requests. Users will see a 404 or 500 error page when IWA agent is being upgraded. In environments with multiple IWA servers, we recommend you manually fail over to a secondary IWA server while the primary is undergoing an upgrade.
You can configure a custom error page to which end users are redirected if Okta fails to process their IWA token. This option is useful if you embed Okta into your solution and you want to control end-to-end branding to enhance the end user experience. The custom error page you specify applies to all IWA users in your organization.
Note: The custom error page setting does not apply to sign in failures caused by an unknown user or a JIT failure. In these cases, users are redirected to their Okta sign-in page.