Something that I’ve had
the misfortune of working on to look into recently was the user experience when accessing federated business apps using a browser that isn’t Internet Explorer. Suffice to say, my customer has “two” supported browsers: IE (9, 10 and 11) and Chrome. A number of apps, such as Office 365 and Salesforce.com don’t support IE9, however other apps require IE9. Wonderful. So Chrome has its place (and thankfully supports GPO, which is one of the reasons I’m a big IE fan).
In its default state, Windows Server 2012 R2 Active Directory Federation Services (AD FS) will only perform Integrated Windows Authentication (IWA) for Internet Explorer. Other browsers will fall back to Forms Based Authentication (FBA) *if* FBA, and failback, is enabled in the global authentication policy. This configuration is made possible through two AD FS configurations (three individual settings):
- The Global Primary Authentication policy is configured for both Windows Authentication and Forms Authentication for the intranet (Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider) and failback to FBA (Set-AdfsGlobalAuthenticationPolicy -WindowsIntegratedFallbackEnabled $true)
- The global AD FS property (Set-AdfsProperties -WIASupportedUserAgents) contains regex patterns for various versions of IE
What does this mean? Basically you enable FBA on the intranet and ensure that the property WindowsIntegratedFallbackEnabled is TRUE. Then, any user agent not matching an element in the WIASupportedUserAgents property list will hit the FBA page even on the corporate network. The experience is like the Internet/WAP experience.
As and when new browsers come along you have to carefully consider how to match those that work with IWA via the WIASupportedUserAgents property, e.g. you might choose to add the following elements to handle Edge and IE11:
- Windows NT 10.0; WOW64; Trident/7.0
To handle other browsers, you need to match them. Mozilla/5.0 will capture a slew of other browsers, including mobile devices, but if you expand that to:
- Mozilla/5.0 (Windows NT
Then that will limit it to Firefox, Chrome and Opera running on a supported build of desktop Windows. This is the approach I took.
That mitigates the UX issues whereby Chatter users, using Chrome, for example are faced with the “external/Internet experience” while on corpnet. Everyone wants SSO on corpnet right?
The real problem comes with how these browsers react after you make this configuration change.
Firefox first, as this works. It prompts a rubbish IWA prompt, you enter your creds (DOMAIN\sAMAccountName or firstname.lastname@example.org) and you’re done. To stop it prompting and actually do IWA like you’re used to with IE you configure the following properties with your domain, e.g. corp.contoso.com,concorp.com:
Having done that Firefox is done. Hit an RP and behold SSO like IE gives you.
Here’s a screenshot of configuring those properties via about:config:
Safari, Opera, A. N. Other browser
I’m led to believe that Safari on a domain-joined Mac and Opera on Windows also work as expected (i.e. they can correctly handle IWA) but haven’t tested this myself. Let me know if you see differently.
Chrome on the other hand has an issue with Extended Protection for Authentication (EPA). I’m not going to go off-topic and try and fully explain EPA, suffice to say that EPA is intended to increase the strength of the binding for the authentication when run over a Transport Layer Security (TLS) connection. It mitigates a number of man in the middle (MITM) attacks and thus provides additional protection of browser-based authentication traffic. More info.:
- Extended Protection
- Integrated Windows Authentication with Extended Protection
- Extended Protection for Authentication
What is the issue? Look to #43 in Chromium #270219 (https://code.google.com/p/chromium/issues/detail?id=270219):
Because Chrome doesn’t use Schannel for the SSL implementation it is not correctly implementing channel binding, thus Chrome cannot perform IWA when EPA is enabled (mandated) or allowed (optional).
What does this really mean? It means you have to disable EPA within AD FS to support Chrome until the above bug is fixed and a stable released.
There’s plenty of info. about this around the place. Basically that means setting the AD FS property ExtendedProtectionTokenCheck to None, e.g.
Set-AdfsProperties -ExtendedProtectionTokenCheck None
Here’s the KB: https://support.microsoft.com/en-us/kb/2461628
I felt that I needed to post something because the KB doesn’t give me enough. This is quite specific to Chrome and the reason is a bug in Chrome not some issue in AD FS. Firefox isn’t affected. It’s also worth noting that the obvious answer isn’t to downgrade the security of the TLS session by simply disabling the ability to use CBTs. For many the fall-back to FBA might be perfectly adequate. This is only an issue if you use Chrome in the enterprise, want IWA and not FBA on corpnet and have configured AD FS to request IWA from non-IE browsers.
For completeness, the TechNet article Configuring intranet forms-based authentication for devices that do not support WIA, currently (as of December 2015) lists the following user agent strings (which is a larger set than that that ships with AD FS):
Set-AdfsProperties -WIASupportedUserAgents @( 'MSIE 6.0', 'MSIE 7.0; Windows NT', 'MSIE 8.0', 'MSIE 9.0', 'MSIE 10.0; Windows NT 6', 'Windows NT 6.3; Trident/7.0', 'Windows NT 6.3; Win64; x64; Trident/7.0', 'Windows NT 6.3; WOW64; Trident/7.0', 'Windows NT 6.2; Trident/7.0', 'Windows NT 6.2; Win64; x64; Trident/7.0', 'Windows NT 6.2; WOW64; Trident/7.0', 'Windows NT 6.1; Trident/7.0', 'Windows NT 6.1; Win64; x64; Trident/7.0', 'Windows NT 6.1; WOW64; Trident/7.0', 'MSIPC', 'Windows Rights Management Client' )
In my environments I actually implement the following:
Set-AdfsProperties -WIASupportedUserAgents @( 'MSIE 6.0', 'MSIE 7.0; Windows NT', 'MSIE 8.0', 'MSIE 9.0', 'MSIE 10.0; Windows NT 6', 'Windows NT 6.3; Trident/7.0', 'Windows NT 6.3; Win64; x64; Trident/7.0', 'Windows NT 6.3; WOW64; Trident/7.0', 'Windows NT 6.2; Trident/7.0', 'Windows NT 6.2; Win64; x64; Trident/7.0', 'Windows NT 6.2; WOW64; Trident/7.0', 'Windows NT 6.1; Trident/7.0', 'Windows NT 6.1; Win64; x64; Trident/7.0', 'Windows NT 6.1; WOW64; Trident/7.0', 'MSIPC', 'Windows Rights Management Client', 'Windows NT 10.0; WOW64; Trident/7.0', 'Edge/1', 'Mozilla/5.0 (Windows NT' )
…and one more thing
I promised my colleague John that I wouldn’t rant about the whole WIA vs. IWA nomenclature clash. So I won’t. But I’ll end the post with this question: what were the AD FS product group thinking? (The correct and true acronym is IWA and has been for years!) 🙂 🙂
If you want to support non-IE browsers enable FBA on the intranet authentication provider and enable fallback to FBA, e.g.
Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider @( 'WindowsAuthentication', 'FormsAuthentication' ) -WindowsIntegratedFallbackEnabled $true
If you want to enable some of these browsers to not perform FBA and work in the same way as IE, i.e. SSO using IWA, then you need to pick an appropriate user agent string and add it to the WIASupportedUserAgents property, as illustrated above using Set-AdfsProperties -WIASupportedUserAgents …
If you want to use IWA to SSO to AD FS using Chrome you will need to disable EPA in the short term until Google fix Chrome. Long term you should look to turn EPA on and make use of CBT.