Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2015-05-19) Configuring Windows Integrated AuthN For Chrome Against ADFS v3.0 And Higher

Posted by Jorge on 2015-05-19


ADFS by default supports multiple authentication mechanisms, being certificate authentication, forms based authentication (FBA) and Windows Integrated Authentication (WIA). For non-domain joined clients or clients on the extranet, FBA is the best option. For domain-joined client on the intranet, WIA is the best option to use. In the last scenario WIA delivers the best SSO experience for the user. To support WIA, the backend, the client and the ADFS server(s) must be configured to support WIA.

[1] To support WIA on the backend the following must be true:

  • The ADFS service account must be configured with a service principal name "HOST/<Federation Service FQDN>" (e.g. HOST/FS.COMPANY.COM)

[2] To support WIA on the client/browser the following must be true:

  • The browser must support JavaScript and have it enabled–> For Chrome this is enabled by default. However, if you have disabled it follow the next steps to re-enable it:
    • Enable it globally"
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Javascript" Section –> Select "Allow all sites to run JavaScript"
      • Click "Done"
    • Enable it specifically for the Federation Service FQDN and any other FQDN requiring it
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Javascript" Section –> Click the "Manage Exceptions" button
      • Specify the Federation Service FQDN and click "Allow"
      • Click "Done" 2x
  • The browser must support and enable the use of cookies –> For Chrome this is enabled by default. However, if you have disabled the use of cookies, you can follow the next steps to re-enable it:
    • Enable it globally"
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Cookies" Section –> Select "Allow local data to be set (recommended)"
      • Click "Done"
    • Enable it specifically for the Federation Service FQDN and any other FQDN requiring it
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Cookies" Section –> Click the "Manage Exceptions" button
      • Specify the Federation Service FQDN and click "Allow"
      • Click "Done" 2
  • WIA is enabled in the browser –> For Chrome this is disabled by default. However, if you have it disabled follow the next steps to enable it:
    • Start Registry Editor
    • Navigate to the key "HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome"
    • If the key "AuthSchemes" does not exist, create it
    • In the key "AuthSchemes" create a string value (REG_SZ) named "AuthSchemes"
    • Assign the string value (REG_SZ) named "AuthSchemes", the values "ntlm,negotiate"
      REMARK: Specifies which HTTP Authentication schemes are supported by Google Chrome. Possible values are ‘basic’, ‘digest’, ‘ntlm’ and ‘negotiate’. Separate multiple values with commas. If this policy is left not set, all four schemes will be use
  • The federation service FQDN must be trusted –> For Chrome this is disabled by default for any FQDN on the internet and enabled for the intranet if detected. However, if you have it disabled follow the next steps to enable it for specific FQDNs (in this case the federation service FQDN must be trusted):
    • Start Registry Editor
    • Navigate to the key "HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome"
    • If the key "AuthSchemes" does not exist, create it
    • In the key "AuthServerWhitelist" create a string value (REG_SZ) named "AuthServerWhitelist"
    • Assign the string value (REG_SZ) named "AuthServerWhitelist", the Federation Service FQDN as the value
      REMARK: Specifies which servers should be whitelisted for integrated authentication. Integrated authentication is only enabled when Google Chrome receives an authentication challenge from a proxy or from a server which is in this permitted list. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will try to detect if a server is on the Intranet and only then will it respond to IWA requests. If a server is detected as Internet then IWA requests from it will be ignored by Chrome

[3] To support WIA against the ADFS STS server(s) the following must be true:

  • WIA must be enabled as an authentication method on the intranet
  • The user agent of the browser must be known to ADFS. By default ADFS v3.0 and higher, the following user agent strings are supported (retrieved through "(Get-AdfsProperties).WIASupportedUserAgents")
    • MSAuthHost/1.0/In-Domain <– ADFS v4.0 and higher
    • MSIE 6.0 <– ADFS v3.0 and higher
    • MSIE 7.0 <– ADFS v3.0 and higher
    • MSIE 8.0 <– ADFS v3.0 and higher
    • MSIE 9.0 <– ADFS v3.0 and higher
    • MSIE 10.0 <– ADFS v3.0 and higher
    • Trident/7.0 <– ADFS v3.0 and higher
    • MSIPC <– ADFS v3.0 and higher
    • Windows Rights Management Client <– ADFS v3.0 and higher
    • MS_WorkFoldersClient <– ADFS v4.0 and higher
  • UPDATE 2016-07-05: You need to disable extended protection in ADFS if you still keep being prompted for credentials while configured all of the above. You are then most likely using a Chrome version lower than v51.*. For any Chrome version lower than v51.* you must disable Extended Protection to get WIA working in Chrome against ADFS!

  • UPDATE 2016-07-05: You do not need to disable extended protection in ADFS if you are using a Chrome version equal to or higher than v51.*. I can confirm that Chrome v51.0.2704.103 and Chrome v51.0.2704.106 supports WIA against ADFS without disabling Extended Protection!
    REMARK: "ExtendedProtectionTokenCheck" –> Specifies the level of extended protection for authentication supported by the federation server. Extended Protection for Authentication helps protect against man-in-the-middle (MITM) attacks, in which an attacker intercepts a client’s credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed or not required by the server when establishing communications with clients.

    Possible values for this setting are: as follows "Require" (server is full hardened, extended protection is enforced), "Allow" (server is partially hardened, extended protection is enforced where systems involved have been patched to support it) and "None" (Server is vulnerable, extended protection is not enforced). The default setting is "Allow". If lowering this protection is not acceptable, then use Forms-Based Authentication!

    • To disable ExtendedProtectionCheck on the ADFS server execute on the (primary) ADFS server: Set-AdfsProperties -ExtendedProtectionTokenCheck None
    • On every ADFS farm member, restart the ADFS service: Restart-Service ADFSSRV

So how do you know the state of your browser? Check it out yourself and just navigate to the website What’s My User Agent?

In my case the browser I was using, Chrome v51.0.2704.106, provided the shown user agent string and the yellow marked part matched what already was configured in ADFS

image

Figure 1: The User Agent String And Status Of Chrome v51.0.2704.106

The following is an analysis of the provided user agent string

image

Figure 2: Analysis Of The Provided User Agent String

So, for Chrome you need to meet the prerequisites as mentioned in [1], [2] and [3].

To configure a new supported user agent string in ADFS, while taking the existing user agent strings into account, use the following PowerShell commands on (primary) ADFS server:

Import-Module ADFS

Set-ADFSProperties -WIASupportedUserAgents $((Get-ADFSProperties).WIASupportedUserAgents + "<Required User Agent String>")

In this case the command is:

Import-Module ADFS

Set-ADFSProperties -WIASupportedUserAgents $((Get-ADFSProperties).WIASupportedUserAgents + "Mozilla/5.0")

That’s it! You should now be able to use Chrome and experience seamless SSO!

For other user agent strings also see:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

One Response to “(2015-05-19) Configuring Windows Integrated AuthN For Chrome Against ADFS v3.0 And Higher”

  1. […] (2015-05-19) Configuring Windows Integrated AuthN For Chrome Against ADFS v3.0 And Higher […]

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: