ADFS v3 on Server 2012 R2 - Allow Chrome to automatically sign-in internally

21 Replies

Symptom: When upgrading from ADFS v2.0 to ADFS v3 built natively into Server 2012 R2, I noticed Chrome stopped auto-logging in people when trying to hit the ADFS server from inside the corporate network.

Solution: We need to allow NTLM authentication for the Google Chrome useragent.

  1. Login to your primary ADFS server
  2. NOTE: This step is no longer applicable on newer versions of Chrome.
    This is only applicable if running extremely old versions of Chrome (v50 or lower) -- the fix has been added in Chrome v51 and higher.
    Execute the following command to disable Extended Protection TokenCheck (See notes for what this is at the bottom of this article)

    1. Set-ADFSProperties –ExtendedProtectionTokenCheck None
      Set-ADFSProperties -ExtendedProtectionTokenCheck None
  3. Execute the following command to get the current list of supported user-agents for NTLM authentication
    1. [System.Collections.ArrayList]$UserAgents = Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents

  4. Execute the following command to inject the user agent into a temporary array of user agents already added to ADFS.
    1. $UserAgents.Add("Mozilla/5.0")
  5. Execute the following command to commit the change.
    1. Set-ADFSProperties -WIASupportedUserAgents $UserAgents
  6. Restart the Active Directory Federation Services service on each of the ADFS farm servers for the changes to take effect.  You do not need to make any changes to the proxy servers.
    Restart Active Directory Federation Services - Restart

Notes

Shout out to Jon Payne in the comments section below for the idea of putting all the values into an ArrayList and then committing the arraylist to ADFS vs adding in all the strings manually.

ExtendedProtectionTokenCheck - Copied directly from technet - 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.  http://technet.microsoft.com/en-us/library/ee892317.aspx

21 thoughts on “ADFS v3 on Server 2012 R2 - Allow Chrome to automatically sign-in internally”

  1. Pingback: ADFS for SharePoint | Tom Zhang's Blog

  2. Dan Tucny

    Nice catch and solution. One thing that would be good to update: The command "Set-ADFSProperties -WIASupportedUserAgents @(“MSIE 6.0″, “MSIE 7.0″, “MSIE 8.0″, “MSIE 9.0″, “MSIE 10.0″, “Trident/7.0″, “MSIPC”, “Windows Rights Management Client”, “Mozilla/5.0″)" contains fancy double quotes and needs to be entered with non-fancy double quotes, i.e. Set-ADFSProperties -WIASupportedUserAgents @("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")

    Thanks...

    Reply ↓
    1. Jack Post author

      Hi Dan,

      I have updated the guide to use the normal characters. Looks like wordpress encodes them by default :/

      Sorry about that!
      Jack

      Reply ↓
  3. PEB

    Thanks for the tip!

    I modified the command a bit, and ran it like this:
    # Add support for Chrome/Chromium/Chrome for Work
    Set-ADFSProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select-Object -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0")
    # Disable Extended Protection TokenCheck. Default value Allow
    Set-ADFSProperties –ExtendedProtectionTokenCheck None
    # Restart Active Directory Federation Service
    Restart-Service -Name adfssrv

    Reply ↓
  4. Sami Lamppu

    Great post Jack, thank!

    One question regarding Set-ADFSProperties -WIASupportedUserAgents. Do I need to keep "MSAuthHost/1.0/In-Domain" included at WIASupportedUserAgent set? It's included on the list by default after ADFS installation but it's not on your command.

    Reply ↓
  5. Rumpole

    Hi,
    Just an FYI I've found that if you add the extra browsers like you have, you don't need to follow it up by disabling the extended protection...Just leave it enabled since now the browsers are enabled to use it.

    Reply ↓
  9. Jon Payne

    Seems to work great for Firefox and Edge even without disabling Extended Protection, but not for Chrome (in our environment) for some reason. I ended up having to remove it for the time being.

    It was quite simple adding it using the method provided by @PEB but removing the additional entry required the method @Jack originally posted. I did, however, figure out a way add and remove items more consistently:


    # Collect existing User Agents
    [System.Collections.ArrayList]$UserAgents = Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents
    # Add User Agent to the list
    $UserAgents.Add("Mozilla/5.0")
    # Remove User Agent from the list
    $UserAgent.Remove("Mozilla/5.0")
    # Apply the updated list to the ADFS Windows Integrated Authentication Supported User Agents property
    Set-ADFSProperties -WIASupportedUserAgents $UserAgents

    Reply ↓
    2. Danny

      Bit late but should help future googlers. Google has fixed the issue that was causing Extended Protection to need disabling. The fix made it into Chrome 51 and later.

      If you have Chrome 51 or newer, you only need to enable the Mozilla/5.0 UserAgent.

      Reply ↓
  10. Thomas

    Hello
    Thanks for the Information thats a really good description but is it possible thats not working with Chrome Versions 49.xx

    Both Options are configured and the Service are restartet but it will be prompt Username and Passoword again

    Thanks

    Reply ↓
  13. Alex Dean

    great post, but no need to disable the security check. That check is a critical safeguard against MiM attacks and should never be disabled unless ABSOLUTELY necessary.
    here is my snippet, using += to add a new item to the array which bypasses the immutable array issue.
    $agents = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    Write-Host "adding Mozilla to the list of SSO user agents..." -NoNewline
    if ($agents -notcontains 'Mozilla/5.0')
    {
    $agents += 'Mozilla/5.0'
    Set-ADFSProperties -WIASupportedUserAgents $agents
    net stop adfssrv
    net start adfssrv
    Write-Host "Done" -ForegroundColor Green
    }else{
    Write-Host "Already Exists" -ForegroundColor Yellow
    }

    Reply ↓
    1. Jack Post author

      You are correct; however, when I wrote this article way back Chrome did not support these options, in which we had to disable ExtendedProtectionTokenCheck.

      I'll try to update the article for the latest version.

      Reply ↓

  15. Pingback: Chrome For Windows Single Sign On

Leave a Reply

Your email address will not be published. Required fields are marked *