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.

Login Prompt

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:

Group Policy Editor

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:

Customize User Agent String

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:

Edit Global Authentication Policy

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!

ADFS Web Form Login Exprienece

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.

Category:
ADFS, Identity and Access Management
Tags:
, ,

Join the conversation! 23 Comments

  1. 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

    Reply
    • 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

      Reply
  2. If I want to revert my changes what steps needs to be followed to get back the default Internet Explorer authentication dialog?

    Reply
    • 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.

      Reply
  3. Is this possible with ADFS 2.0?

    Reply
  4. 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?

    Reply
    • 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/).

      Reply
      • 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

  5. 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

    Reply
    • 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?

      Reply
  6. 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

    Reply
  7. 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!

    Reply
  8. 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.

    Reply
    • 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.

      Reply
    • 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?

      Reply
  9. 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.

    Reply
  10. 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.

    Reply
  11. 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?

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: