An increasingly common scenario for organisations is a mixed network of Domain joined and non-Domain joined or BYOD clients. To provide Single Sign-On for Domain joined clients, Windows Authentication must be enabled in the Global Authentication Policy for the internal ADFS farm. Unfortunately for the BYOD clients, the result is the default Internet Explorer authentication dialog below when attempts to access federated applications are made – a very poor end user experience.
It is possible however to configure ADFS V3.0 so that BYOD clients receive ADFS Forms authentication whilst Domain joined clients maintain SSO. ADFS uses the WIASupportedUserAgents property to identify what browsers are capable of performing Windows Integrated Authentication (WIA) and therefor support SSO. The following ADFS PowerShell command lists off browsers enabled for WIA:
Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents
Output will be similar to this:
MSAuthHost/1.0/In-Domain MSIE 6.0 MSIE 7.0 MSIE 8.0 MSIE 9.0 MSIE 10.0 Trident/7.0 MSIPC Windows Rights Management Client
Browsers with a User Agent string containing any of these values will default to WIA, and if logged on with a domain account, will perform SSO. If you’ve got Chrome or Firefox clients you’d likely have added “Mozilla/5.0″ to this list to enable SSO for those browsers. Unfortunately by default both Domain joined and BYOD clients return the same User Agent strings, so WIA is attempted for the BYOD clients too – and fails, resulting in the Internet Explorer authentication dialog. The solution is quite simple, the Domain joined clients need to be identified by a unique User Agent string, and ADFS configured to attempt WIA for browsers presenting that User Agent String only. Here’s how to accomplish this:
1. Domain joined clients receive Group Policy, so it makes sense to use it to deploy our custom User Agent string – the following Group Policy setting controls the User Agent string for Internet Explorer:
2. Edit this Group Policy setting, specifying your unique User Agent string value, in this case I’m using “Kloud”. Apply this group policy to your client workstations:
This will result in managed clients presenting a User Agent similar to this (for IE 11):
Mozilla/5.0 (Kloud; Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
Instead of this:
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
3. Next, fire up the ADFS V3.0 Management Console and edit the Global Authentication Policy, enable both Windows Authentication and Forms Authentication for the Intranet:
4. Run the following PowerShell to specify a new set of clients enabled for WIA – notice that the default MSIE and Trident strings have been removed and my custom User Agent “Kloud’ has been added. If you’ve added any User Agent strings for non-browser services, these should be maintained.
Set-AdfsProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain","MSIPC","Windows Rights Management Client","Kloud")
5. Restart the ADFS service.
6. Attempt to access a federated application from a BYOD client, the ADFS Forms authentication dialog below should be displayed. Domain joined clients will continue to use WIA as they present a User Agent containing “Kloud”. A much better end user experience!
By removing the default User Agent Strings from the WIASupportedUserAgents property, we force BYOD clients to default to ADFS Forms Authentication instead of Integrated Authentication.
Non-Microsoft browsers (e.g. Chrome and Firefox) will also receive the ADFS Forms authentication dialog by default – this can be addressed for Domain joined clients by enabling those browsers for WIA and configuring the same custom User Agent string. The methods to do this vary between browser types.