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.
Hi All, an update to this blog – if you have web applications that have dependencies on detecting IE versions via the user agent string, try configuring your custom agent string value via the following registry key. This will maintain the IE version, and append your custom string as an additional value in the user agent string.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform]
This not a Group Policy value, so Group Policy Preferences will be your friend in deploying this out.
A good reference on the use of this registry key can be found at the URL below:
http://msdn.microsoft.com/en-us/library/ms537503(v=vs.85).aspx
HI Mark,
We tried the registry value as above but single sign on fails. The SAML request gets sent to our adfs box in (IE 9,10,11 etc) but it doesn’t do anything. Once we submit the same URL by hitting enter, SSO goes straight in without us doing anything else,
Highly confusing but we are at a loss. We tried the group policy way and that worked but broke our office 365 as gave us the light version.
We are using ADFS 3.0 on 2012 r2. Clients are windows 7 and IE 10.0
Hope you can help
Is there anything logged in the ADFS server event logs? If not the best way to diagnose what is going on is to use Fiddler (http://www.telerik.com/fiddler).
For those having issues with the Post-Platform key, the value for the custom key needs to be IEAK for it to report.
so:
Name = ADFSSSO
Value = IEAK
If you go to the user agent string site it will now show your custom string.
However this only works for IE not Edge as far as I can tell 🙁
This is not working.
Basically this is what I did:
1. I went to Post Platform key and I can see 5 .NET strings there, and those are the 5 .NET strings that I can see when visiting the user string site.
2. I added a 6th one: name = test, value = IEAK
3. I close IE and re-open it, it still refuses to show the one I added…
If I want to revert my changes what steps needs to be followed to get back the default Internet Explorer authentication dialog?
Hi San,
To roll back you need to re-apply the set of WIA Supported User Agents that were present before you made the change.
As discussed in the blog, the following command will list off the WIA Supported User Agents currently configured, take note of these before making your change:
Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents
If you’ve already made the change and didn’t take note of the previous configuration (surely not!), the default list of WIA Supported User Agents can be restored via the following command:
Set-AdfsProperties -WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,”MSIPC”,”Windows Rights Management Client”,”MSIE 6.0″,”MSIE 7.0”,”MSIE 8.0”,”MSIE 9.0”,”MSIE 10.0”,”Trident/7.0”)
You’ll need to roll back any group policy changes too.
Is this possible with ADFS 2.0?
I haven’t implemented this personally, but the blog below outlines a similar solution for ADFS 2.0:
https://blogs.ncl.ac.uk/isg/?p=296
Thanks a lot. I just tried this myself and it works like a charm.
Hi Mark
I’ve been able to implement the forms authentication in my mixed environment via the GPO method. This however caused issues with various sites as you posted on the 19th of December. I’ve since removed the GPO and reverted the intranet authentication settings.
I’ve tested the registry method via a GPO, but this clearly does not work for me. As soon as I enable intranet forms authentication none of my workstations are able to log on via SSO.
I can confirm that javascript:alert(navigator.userAgent) shows that the devices have received the user agent setting and I have used the Set-AdfsProperties -WIASupportedUserAgents command to configure ADFS.
Any suggestions?
Hi Pierre,
Can you please send through an export of the following:
1. results of “Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents”
2. Export of “[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform]” registry
Also, please confirm that the user agent string is present (http://whatsmyuseragent.com/).
Hi Mark
Please see below:
PS C:\Windows\system32> Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents
MSAuthHost/1.0/In-Domain
MSIPC
Windows Rights Management Client
ADFSSSO
PS C:\Windows\system32>
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform]
“ADFSSSO”=”ADFSSSO”
http://whatsmyuseragent.com/ doesn’t show my agent string:
You!! Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
But the javascript:alert(navigator.userAgent) command in IE shows:
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; InfoPath.3; .NET CLR 3.5.30729; .NET CLR 3.0.30729; ADFSSSO; rv:11.0) like Gecko
Is it possible that our web filter may be affecting the agent string?
Hi Pierre, does look like something is processing your user agent string. Have you tried disabling proxy settings in IE, then attempting to perform an IdP initiated sign on?:
https:///adfs/ls/idpinitiatedsignon.aspx
Hi Pierre,
The string from the IdP initiated sign on URL was stripped – replace the bit enclosed in asterisks with your ADFS federation service name:
https://*Federation service FQDN*/adfs/ls/idpinitiatedsignon.aspx
Hi Mark
Apologies for the silence I’ve been traveling the past few weeks.
I’ve deployed some test clients that absolutely don’t go via any proxy service. My agent string still doesn’t show my custom parameters when accessing the whatsmyuseragent site as I mentioned above.
Any ideas?
Hey Mark,
Awesome article! I just had a question. We have SSO currently enabled for Chrome and FF using the Mozilla/5.0 string. The user string is applied so that it affects all browsers, right? So setting a custom user string, and removing Mozilla/5.0 will allow Chrome/FF/IE to continue to function?
Thanks!
Jason
I guess my question is, can you keep SSO enabled for Chrome/FF while forcing forms authentication for iPhones?
Hi Mark
I managed to resolve my issues with a very easy fix. It’s probably not the best solution, but it required extremely little change to my network.
Our iPad devices connect on a different VLAN via our wireless infrastructure. I configured the DHCP scope to point to a DNS server that redirects all ADFS requests to my proxy servers and voila forms based authentication for my non domain joined devices without touching my internal DNS infrastructure.
Not sure why the registry solution didn’t work for me, but at least I got it to work and now have Apple devices authentication internally as they would external to our network.
Thanks Anyway!
Hey guys. I wanted to chime in here as I’ve been working with this for awhile. I wanted to try to explain the problems and offer a final solution. If you change the browser’s User Agent to “Kloud”, the browser will function kinda wacky for other websites which try to determine your browser based on UA string. Don’t do that (unless your browsers only access intranet websites where you can re-write the websites to handle the new, wacky UA string).
Instead, you should add a “feature token” (you know what these are, they appear in UA strings like “.NET CLR 2.0.5.50727” or “.NET4.0E” or whatever). You have to make a GPO to add a registry key to your clients. So come up with a custom, unique string like “ABCDEFG”, add that to your client’s registry. See ms#537503 if you need to find out where to add the key in the registry. I added the string “MEDU” to “post platform” — so it appears at the end of my UA string.
Tell ADFS to use WIA when it sees that string (as mentioned in the inital article here).
It still won’t work. Why? Because beginning with IE9, IE will not send out the full User Agent string. It will not send out feature tokens to web servers. You must also add the FQDN of your federation servers to a GPO which tells IE to visit that site in compatibility mode. See, in compatibility mode, IE will still send the longer User Agent string. You can find this in GPO under Computer > Admin > Win Components > Internet Explorer > Compatibility View > Use Policy List of Internet Explorer 7 sites.
Thank you for this suggestion. We tried modifying the User Agent string but it caused issues with our SharePoint servers, so instead we are testing this with the Post Platform token. One suggestion I can make is instead of using Compatibility View we are using Enterprise Mode so that we can target that one site instead of the entire domain. It seems to be working great for us.
Thanks Mark and Robet for the addition help around post platform and compatibility mode. Have you found a way to do the same with Chrome via group policy?
We ran into all of the same above problems and simplified things by one step. Instead of using a longer string or a custom User Agent, we set the WIA to look for the User Agent for Internet Explorer 7 (MSIE 7.0). We then put the site in compatibility mode for the computers we wanted use with SSO. It’s a reasonable assumption that most computers are running at least IE 10 at this point.
ADFS works for me on an off-domain computer, running Window 10, but only works in Edge, and Firefox! It won’t load in an off-domain PC running Windows 10 in IE 11. It does load in an on-domain PC running Windows 11. I wish Microsoft would actually test their software.
There’s no reason for this non-sense. I’m going to have to waste time troubleshooting this BS now.
Hi Mark,
Very good article. I’ve found it when I was looking for customization for myself. Is it possible to do the same approach as you presented but based on Domain Users or Groups? I would like to point one bunch of users for WIA and other for Certificate Authentication.
I think there is no other way to mixing primary authentication for different groups of users unfortunately
Thank you very much for information.
I implemented the registry change to add an entry to IE Post Platform values. I added the ADFS URL to the IE Enterprise Mode Site List. When my app redirects to ADFS, IE Enterprise mode is not applied to the page. Interestingly enough, if I open Fiddler, I can see that although IE Enterprise mode is not applied to the page, IT IS applied to any subsequently requested resources such as CSS or images.
If I refresh the URL or paste the ADFS URL into a browser directly, it goes right through Windows Integrated Auth as expected. Has anyone else seen this and if so how did you get around it?
James,
We also saw that behavior with your same config. Not consistently. Agreed that when it occurs, the icon next to the URL even shows the site as Enterprise Mode. Hitting F5, or providing anything in the FBA fields (even wrong user) results in integrated auth kicking in. The fragility / complexity of this solution likely means throwing it away and using something simpler for us. In a Health Care environment, kiosks / generic users are a fact of life.
Hi Mark,
My question is if i want to allow Mac computer to login to the our ADFS 3.0 site what i need to do that?
Thank you.
Hi Hasanain,
Any compatible web browser would be able to login to AD FS on any operating system.
I have a Macbook Pro as my BYOD device and use Chrome with forms based auth to access Kloud and customer Office 365 and Azure tenants via AD FS regularly.
Are you wanting a ADDS domain joined Mac to leverage Win Auth for SSO? – I’m not sure if thats possible.
Cheers, Lucian
This does seem to work for my non domain attached devices, but what I does for my domain attached devices is break the WIA to sites through ADFS. Is there something that’s not configured correctly?
Works great internally and BYOD Devices. However what about external computers not joined to the domain and on a different IP Address I followd all steps but still get WIA from home either on IE or Chrome?
Thanks,
Damien
Any techniques for modifying the User Agent for Edge? Group Policy cannot be used as far as I know.
How about having two ADFS 3.0 servers, one externally facing and one internally facing, so that the internal can have all the user agent values for sso, while external for byod has little user agents.
Hi mate,
Both AD FS servers would be “internal” as you wouldn’t want to expose a domain joined machine to the internet.
They would reside behind proxies and both would be paired for HA.
Single servers for authentication for any size organisation increases risk for outages and downtime.
You can create leverage split brain DNS to send all your sts.domain.com or login.domain.com (whatever you AD FS site is) traffic to your internal load balancer, and all external traffic to your external load balancer and proxy HA pair.
Cheers!
I’ve just added a suggestion on Microsoft’s Windows Server suggestion box to add the ability to fall back to forms-based auth if Kerberos fails, or make the options for enabling WIA more flexible and not just based on user agent. If you think it’s worth a vote, please do so: https://windowsserver.uservoice.com/forums/304621-active-directory/suggestions/30968485-allow-ad-fs-to-fall-back-to-forms-based-authentica
The solution is to make use of a Web Application Proxy for all traffic from non-domain joined pc’s. All request coming from a Web Application Proxy are seen by ADFS as Extranet traffic and thus handled with forms auth. instead of WIA. All request directly to ADFS are seen as internal and are handled with WIA.
To achieve this you have to make use of a split DNS config to route the correct request to de WAP or ADFS.