At Okta, we see a lot of our customers using the Desktop SSO Agent to enable them to perform seamless Single Sign-On between their on-premises Active Directory and the Okta Service. We’ve worked hard to keep the installation experience as simple as possible, however there’s a lot you can do with the DSSO agent to further improve security and usability for your end-users.
Using SSL for your Deployment
First and foremost, we always recommend that you transition to using Secure Sockets Layer (SSL) with the on-premises agent. This is important to provide the utmost security, but it is also a hard requirement for some applications to successfully authenticate (in particular, Windows 10 Universal Applications such as OneNote, Mail etc). In order to switch to using SSL, you should follow the steps in the Install and Confgure the Okta IWA Web App for Desktop SSO Guide. As Domain joined computers will be the primary audience for DSSO, there’s no need to purchase an SSL certificate from a third-party if you have an internal Certificate Authority. These computers will, by default, trust the SSL certificate issued to the DSSO agent.
Your DSSO agent can support bindings on both port 80 and port 443 simultaneously, so remember to test out the change for yourself, prior to reconfiguring Okta to point to the HTTPS binding. This will stop any interruption to your user’s sign-on experience. To do so, simply copy the address of your IWA agent from Okta:
Jump to a browser session, paste the existing link into the address bar, change the address to use ‘https’ and add Authenticated.aspx to the end of the link. If everything has gone to plan and your browse to the link, you should see the page below presented:
If everything looks good, and you’re ready to make the change, jump back to Okta and make the switch to HTTPS (Note: Simply change the address from http:// to https://, no need to add anything else to the IWA redirect URL).
Redirecting incompatible clients with IIS ARR
Throughout your enterprise, you'll no doubt have different types of devices, running different OS versions with different capabilities. A Windows device will probably be joined to your AD Domain, whereas that probably won't be the case for that iPhone. Because of this, some of these clients aren't going to be able to achieve Integrated Windows Authentication (with Kerberos or NTLM) and will need to use a forms-based login page. Within the Desktop SSO agent, we've added a customizable fallback interval if IWA has not succeeded, though sometimes you may want to optimize this experience for clients that you know will fail. In order to achieve this, one common configuration is to leverage Microsoft’s Application Request Routing IIS extension to redirect clients that do not support Integrated Windows Authentication back to Okta’s forms-based login page.
You can find more information about detecting ineligible clients on your IIS Server from the Install and Confgure the Okta IWA Web App for Desktop SSO guide.
Once you have ARR Installed, load up your IIS Manager Console, browse to your IWA Application and open URL Rewrite:
You want to create a ‘Blank Rule’:
Give it a descriptive name and then configure the rule as you see fit. In the example below, if any request hits the IWA Application and has a HTTP_USER_AGENT string containing Mobile it’s going to redirect the user to the Okta login page for my tenant.
If you need information about the User Agent String for a Device, http://www.useragentstring.com can easily give you a wealth of information to help make pattern decisions simple.
You can also then test them as part of the IIS Conditions, ‘Test Pattern’ functionality:
Have you got any custom configuration tips that could help out others? Drop us a line on the community and get the word out! As always, feel free to reach out and let us know how you’re going with your deployment.