New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 270219 link

Starred by 64 users

Issue metadata

Status: Fixed
Closed: Mar 2016
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug

Sign in to add a comment

Logging into Office365 from Chrome content area fails in ADFS 2.0 SSO setup with Extended Protection

Reported by, Aug 8 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

Steps to reproduce the problem:
1. Use Chrome to browse to
2. Have ADFS 2.0 configured properly
3. Login with my credentials and receive repeated prompts to login.

What is the expected behavior?
I would expect that when I use Chrome I would be able to login to my Office 365 implementation.  I am using SSO and have Extended protection enabled in the adfs/ls node in IIS.  I have read countless pages that say the way to fix the problem is to turn off Extended Protection in IIS but, that doesn't seem like a very good solution.  I am not willing to lower my security stance just to use Chrome.

What went wrong?
Ideally, I could use the group policy settings provided in the ADM/ADMX files to push settings to my domain joined computers to make this all work properly.  I would love it if the devs could provide me with a set of GPO settings that will make Chrome work properly with my (very standard) ADFS implementation.  Also, I would be very interested in hearing why it hasn't worked in the past. 

Of course, this all works properly in IE (but then we expect MS products to work together, at least most of the time).  I have a large number of users that use Chrome and love it (including me) and we would like to not have to switch back to IE just because our Office 365 requires it.  

Did this work before? No 

Chrome version: 28.0.1500.95  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 11.8 r800

Comment 1 by, Oct 1 2013

I have the exact same problem.
You can see how much the devs care about this issue...

I posted it about two months ago and it received absolutely no reponse.  I ended up turning off Extended protection so my users could use Chrome.  I did see recently that Firefox has fixed this issue so now Chrome is the only browser that does not support Extended protection.  

Comment 3 by Deleted ...@, Oct 10 2013


Please fix it!
Julian, do you know what has to be done here?
Can you please post the results of using the ADFS/SSO test from when the advanced protection mechanism is turned on?
I'm sorry guys, I started this thread when I was in testing but, now I'm in production.  I can't change the settings without an outage window.  If anyone else has the ability to post their test results, please do so.  
If anyone else can get to this before I can, the test they are requesting is on the Office 365 tab, third one down "Office 365 Single Sign-On Test"

I'm a little surprised the Dev team needs any further information.  When I did a quick search on "chrome doesn't support extended protection" I got hits going back as far as 2011. This is not a new issue.  It is well known that to support Chrome in an enterprise environment we have to reduce our security posture.  

I could understand if this was something that Microsft had just changed but, it's been an issue since the release of Server 2008R2 .
This is still an issue depending on your version of ADFS.
Labels: Enterprise-Triaged Needs-Feedback
Summary: Logging into Office365 from Chrome content area fails in ADFS 2.0 SSO setup with Extended Protection (was: Using ADFS 2.0 and Chrome fails)
gradyduncan, do you mean that in more recent version of ADFS this is not a problem? If you have the problem set up could you please share the results of the ask in #5?

changed summary to better reflect my understanding of the problem. Please suggest edits if I am mistaken.

Adding to Cc folks to are working in related areas, but need more info to proceed.

Comment 10 by Deleted ...@, Jun 12 2014

I seem to have the same issue.
Previously, I was asked to login *twice* but then it went through.
Since a chromium update, I cannot login unless I delete my cache and cookies.

That is: I can only login once after every cache reset. If I logout or my session expires, I am repeatedly prompted for login, to no end.

Comment 11 Deleted

I have the same issue (repetead prompts) with Chrome 38. We tried with Firefox 33 and Safari 8.0 (Mac) and works fine. 
I can confirm that this is an issue only on the desktop version of Chrome.  With Extended Protection enabled, and set to 'Accept' (as opposed to 'Required') on our ADFS 2.0 server, Office365 authentication works on Chrome for Android, but not on Chrome for Desktop (Windows).  

Is there any progress on this issue?  Can whatever code that enables the mobile version to work be added to the desktop version easily?

Comment 14 by Deleted ...@, Jan 26 2015

I have also confirmed with #13, furthermore

- It works OK with Mac Chrome
- Firefox and IE 10 does not have this issue
- It is only broken on the desktop version of Chrome

Comment 15 by Deleted ...@, Jan 26 2015

Since this only occurs on Chrome, I regard this as a bug on Chrome and not on the Office 365, On-Prem.
1. Could you guys please post the test results request in #5? 
2. Could you perhaps share some test credentials, that we can use to reproduce the problem?
I've attached test results for both IE and Chrome.  I get the same result from both browsers, so that particular test doesn't seem to hit whatever the bug is affecting.  I've emailed you test credentials for our environment, and I've confirmed that they work on IE, Firefox, Safari (iPad), and Chrome mobile (both Android and iPad), and that they don't work on Chrome Desktop PC.

83.8 KB Download
83.8 KB Download
Labels: -Needs-Feedback
Status: Assigned
Tylor, thanks for the helpful test results & the credentials. We have the reproduction of the success & the fail cases. So we should be able to get to the bottom of this soon, but have not managed yet.
Thanks for the update.  Let me know if there's anything more I can do to help!
I have an environment that I can test with right now as we implement SSO with ADFS 2.0 and Salesforce. If you need more data to fix this, please let me know. We have a large userbase that uses Chrome because of the good performance when using Salesforce, and we will have to move to Firefox if we can't implement SSO with extended protection enabled.
Still an issue for us also
Any idea when this issue will be resolved? Any feedback from the development team?

Comment 26 by, Apr 20 2015


Comment 27 by, Apr 21 2015

Labels: M-44

Comment 28 by, Apr 26 2015

This issue also affects a network I manage, however, there appears to be some conflicting information in the subsequent comments as well as a lack of concrete detail on the technical aspects of the issue so I'm chipping in with what's hopefully useful information.

Firstly, the precise issue here is that Chrome lacks support for EPA (Extended Protection for Authentication). What is EPA? It's a Microsoft Implementation of RFC 5056: On the Use of Channel Bindings to Secure Channels. In short, it's an enhancement for the IWA (Integrated Windows Authentication) mechanism to protect against man-in-the-middle attacks. When IWA authentication is performed the client communicates with the server over a TLS channel and receives a session key from the server after successful authentication. In fact, two session keys are generated: the "outer" session key specific to the TLS session and the "inner" session key from the IWA authentication itself (which was encapsulated in the TLS session). The issue which EPA seeks to address is that this is vulnerable to credential relaying via a MITM attack as the server does not verify that the authentication session credentials were communicated over the same TLS session that they were originally transmitted over. This is because there is no association between the "outer" TLS channel and the "inner" authentication channel and the session key it generates from a successful authentication. EPA aims to prevent this by tying the session key generated from a successful authentication to the TLS channel it was made over. This is done via the usage of a CBT (Channel Binding Token) which binds the "outer" TLS channel to the "inner" authentication channel. Microsoft has been rolling out EPA support for their products for the last several years. For EPA to work the server and the client require support.

Tying this back to the original issue with authenticating to Office 365, for organisations wanting SSO, IWA is very frequently used in Windows networks to allow the client to transparently authenticate to the server. For SSO authentication to resources outside of the corporate network, a common approach is federated login using SAML (Security Assertion Markup Language) via a federated login server. Microsoft offers one such server via ADFS (Active Directory Federation Services), though there are plenty of 3rd-party options as well. ADFS by default supports EPA. If ADFS detects a browser user-agent which it believes supports IWA (based on the server configuration) and EPA is also enabled then Chrome will completely fail to login.

It's important to note that there are three options for enabling EPA server-side and one of them is somewhat counter-intuitive:
 - None: EPA is not used.
 - Require: EPA is required.
 - Allow (default): EPA is used *if* the client system supports it. That is, EPA is required if the client authentication libraries have been patched to support EPA. Presumably Chrome uses the Windows SSPI (Security Support Provider Interface) for IWA, which uses such libraries, but doesn't use EPA. As such, the authentication fails, as the server expects EPA to be used in this scenario.

As there's no setting akin to "Optional EPA", ie. use EPA if it's provided but allow authentication if not, it has to be *globally* disabled on the server in order to support clients like Chrome, reducing the security of the network for all clients.

I've performed some testing against a fully patched Windows 8.1 system on several browsers to show the current state of support. The browsers user are Internet Explorer 11, Firefox 37.0.2 & Chrome 42.0.2311.90; each the latest stable version at the time of writing. The backend was Active Directory Federation Services on Windows Server 2012 R2 tested against each of the available EPA options. Note that all browsers require some configuration on the client to permit credential delegation to the federation server. In the case of Chrome, the AuthNegotiateDelegateWhitelist and AuthServerWhitelist preferences should be set to the FQDN of the federation server.

=============== EPA: None ================
Internet Explorer: Works seamlessly
Firefox: Works seamlessly
Chrome: Works seamlessly

=============== EPA: Allow ===============
Internet Explorer: Works seamlessly
Firefox: Works seamlessly
Chrome: Pops-up an authentication dialogue and always rejects credentials. User is unable to authenticate at all.

============== EPA: Require ==============
Internet Explorer: Works seamlessly
Firefox: Works but pops-up an authentication dialogue. It does accept valid credentials but sign-on isn't seamless.
Chrome: Pops-up an authentication dialogue and always rejects credentials. User is unable to authenticate at all.

Obviously, it'd be really great to see this issue prioritised as it's pretty unfortunate that network administrators have to reduce their network security for compatibility with Chrome, especially given its usual stellar security!

Hope this is helpful to someone and apologies for the long post.
Labels: Cr-Internals-Network-Auth
#28: Thanks for the details and testing.

It looks like supporting CBT type tls-server-end-point ( should be sufficient. Both GSSAPI and SSPI allow us to set a CBT, but we'll to implement support for calculating the CBT and the necessary plumbing to make it available for the auth handlers.

+davidben: Since I'll bug him later about how best to calculate the CBT.
Asanka: I had patches to do it for NSS, but really, we don't need anything in OpenSSL/NSS - we just need to grab the TLS server certificate from the connection. Feel free to reach out if you have questions.
Labels: -M-44 MovedFrom-44 M-45
[AUTO] Moving all non essential bugs to the next Milestone.  (This decision is based on the labels attached to your ticket.)


Comment 33 by, Jul 20 2015

Any update on this issue? 

Comment 34 Deleted

I see Chrome 45 Beta available for download and I read somewhere that it's going to possibly be released Sep 1st or 8th. Can someone from Chromium please confirm if this fix is or going to be in that release.
Just tested on Chrome v45beta and the issue is still there.
Also tested on Chrome v46Dev, same problem.

Comment 37 by Deleted ...@, Aug 3 2015

Chrome needs to work with ADFS and Extended Protection enabled. I've seen reports of this years ago and it's appalling that Chrome browser still has this issue. Turning off Extended Protection is not an option. We have 60K users and at least a third want to use Chrome and cannot due to these issues with Chrome not supporting Extended Protection being enabled. Everyone else has fixed it in their product. How long will it take for this to be fixed in Chrome?

Comment 38 by Deleted ...@, Aug 6 2015

My company is rolling out Google Apps for Work using ADFS for single sign-on as we are already using ADFS for other 3rd party services we use.  We are experiencing the same issues as post #1 when using Chrome.  Behavior for other browsers is also the same as those described in post #28, meaning we can get to our Google Apps environment successfully, with EPA enabled, using Internet Explorer and Firefox, but not in Chrome.  I've attached the lines pertaining to connecting to ADFS from my chrome_debug.log file, hopefully they will be of help.  I've replaced some identifying items with generic terms.  They are as follows:

<ADFS-SERVER> - FQDN of the company's ADFS server
<CORPDOMAIN> - My company's domain
<SOME LONG KEY x> - 309 character string.  Different each time.

I'm using Chrome Canary version 46.0.2473.0 64-bit.

Thanks for your efforts on looking into this issue.
4.5 KB View Download
We are currently experiencing this issue, exactly the same as post #28.

We are now on ADFS 3.0.  We have over 1000 users that have Chrome as their primary browser but due to this issue they have to constantly switch over to IE.  Are there plans to get this fixed?  
I think it should be fairly obvious at this point that the dev team doesn't give a rip about this issue.  It's been a problem for over 2 years and they don't seem to have any interest in fixing it.  
 Issue 513173  has been merged into this issue.
What needs to be fixed is to **export the CBT from the SSL stack** and **insert the CBT into the SSPI stack**.

Here is how it is working "normally":
The CBT is exported by the Schannel SPI (SSL) with QueryContextAttributes(SECPKG_ATTR_ENDPOINT_BINDINGS). It returns a SecPkgContext_Bindings structure.

Then it is being imported with the function InitializeSecurityContext in a supplemental buffer of the type SECBUFFER_CHANNEL_BINDINGS.

The problem:
Because Chrome doesn't use Schannel for the SSL implementation, the SecPkgContext_Bindings isn't present natively. It has to be constructed manually and imported in InitializeSecurityContext.

A path to a solution:
The file may have to be modified to include the CBT in one of the call of InitializeSecurityContext.

FreeRDP has a working implementation of channel binding.

Here is how the CBT is generated:

Here is how the CBT is imported:

Some comments from its author on how the CBT was generated from OpenSSL:

Someone just need to make the modifications ;-)

Here is my analysis on the code that will be impacted.
(this is the first time I look into the code, so pardon me if what I'm saying in wrong)

The solution needs to forward the server certificate to the InitializeSecurityContext call.
This requires to modify a **lot** of prototypes to be able to forward the SSLInfo class (that I've identified to store the server certificate) from HttpAuthController to the final call. 
Once the forwarding of the server certificate has been done, the implementation effort is relatively low because the algorithms has already being done by FreeRDP and are relatively simple (once known).

Modify all HttpAuthController calls to include SSLInfo (server's certificate information) if it is available.
Modify the HttpAuthController constructor to accept the SSLInfo and save it
Modify the DoGenerateAuthToken call to add the SSLInfo
Modify  DoGenerateAuthToken to forward the SSLInfo to the call of auth_system_.GenerateAuthToken
int HttpAuthSSPI::GenerateAuthToken() to add an optional SSLInfo
int HttpAuthSSPI::GetNextSecurityToken() to add an optional SSLInfo
in GenerateAuthToken, add a flag to know if it is the first round
(using the test if (!SecIsValidHandle(&cred_)) ?)
In this case, forward the SSLInfo to GetNextSecurityToken.
In GetNextSecurityToken, build the SecPkgContext_Bindings structure by using the SSLInfo.cert provided in argument.
(copy / paste the function tls_get_channel_bindings from FreeRDP)
Then (still in GetNextSecurityToken) add the SecPkgContext_Bindings in the in_buffer structure.
(copy / paste the code ntlm_authenticate from FreeRDP to see how this structure is added)
Adapt the HttpAuthGSSAPI class to add the arguments to the prototypes and ignore them because HttpAuthSSPI and HttpAuthGSSAPI are defined as AuthSystem in http_auth_handler_negotiate.h


I am leery to post this workaround as it might reduce the heat on Google to fix this issue but I decided that since so many people are watching this issue, it can help them as it helped me. BTW I want to thank Vincent above for laying out a solution for Google and even doing code analysis. I always held Google's SW developers in high esteem, but stuff like this makes me scratch my head. Here we have an issue that all other browsers support and it is a real nuisance for enterprise users of Chrome and yet they sit on it for years and do nothing. Hopefully Vincent's tips above will help them finally fix it.

Anyways, this StackOverflow question [1] has a solution that worked for me and now our corporate ADFS set on "Require" for extended protection lets me in. From the link:

To control the extended protection behavior, create the following registry subkey:
Key Name: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
Value Name: SuppressExtendedProtection

For Windows clients that support channel binding that are failing to be authenticated by non-Windows Kerberos servers that do not handle the CBT correctly:
1. Set the registry entry value to “0x01.”
This will configure Kerberos not to emit CBT tokens for unpatched applications.
2. If that does not resolve the problem, then set the registry entry value to “0x03.”
This will configure Kerberos never to emit CBT tokens.


I hope it helps others as it helped me.


Vincent: Thanks for the awesome analysis! Hopefully this helps to spur Google into implementing the required changes.

George: Thanks for the above workaround but I feel like I should clarify for everyone's benefit that applying the suggested configuration change will *globally* disable EPA on the system. So while it will enable you to authenticate against an ADFS server that supports CBT using Chrome, any and all other applications that support CBT on your system are now not going to benefit from the additional security it provides. This includes:
 - Server Message Block (ie. Windows File Sharing)
 - Anything that uses WinINET (eg. Internet Explorer)
 - Anything that uses SSPI (Native Win32 apps that are CBT aware)
 - .NET Framework apps (not sure if custom code required)

A full listing can be found here:

It might be workable for some but you should be aware of the full effect of doing so.
If it can speed up the fix, I can develop a win32 unit test to test it.
This unit test will use the Microsoft HTTPAPI (using http.sys as IIS).

The interesting function is HttpSetUrlGroupProperty with the parameter HttpServerChannelBindProperty.
Indeed inside this structure there is a HTTP_AUTHENTICATION_HARDENING_LEVELS enumeration:
* HttpAuthenticationHardeningLegacy
    Server is not hardened and operates without Channel Binding Token (CBT) support.
* HttpAuthenticationHardeningMedium
    Server is partially hardened. Clients that support CBT are serviced appropriately. Legacy clients are also serviced.
* HttpAuthenticationHardeningStrict
    Server is hardened. Only clients that supported CBT are serviced.

The only thing that should be noted is that the test program needs to be run elevated or rights should be granted using netsh (netsh http add urlacl url=http://+:80/MyUri user=DOMAIN\user)

(doing the patch itself represent a lot of work and i do not know enough the chrome code to do it the right way)
Need this for our ADFS implementation. We choose to use Chrome for our business apps, but if they won't authenticate against ADFS, might be time to select a better browser. 
BUMP! 2 Year old post but it is still very much an issue and very much relevant. The fact that the user base is breaking down the code to try and help with a fix boggles the mind. 

Comment 50 by Deleted ...@, Oct 7 2015

Bump. Add another company to the growing list that is experiencing this issue.  Extremely frustrating.
What a revelation finding this issue log was.  Add me to the growing list of admins baffled that Chrome is the last major browser not supporting EPA.  I have a lot of users who are going to be pretty unhappy about being told to use I.E. for a particular WebApp.  When they ask why, I'm going to tell them the truth as far as I know it: Google either can't or won't fix it.  Not going to be good for your PR.
Status: Started
A fix is in the works for enabling CBT.
Gentlemen I just posted a work around. This allows for SSO with Chrome without disabling Extended Protection. We deployed it in a corporate environment.

Any update on the fix? Another new organisation, moved to 365 with SSO issues under Chrome....
I saw the change of owner (again).
Do you need some help to make it work ?

I know very much the internal Windows authentication mechanisms but not the chrome source code (I add to choose ..). If you need help I can provide advices / test / debugging.
Do not hesitate to contact me at vincent[dot]letoux[@]


Comment 57 by, Dec 16 2015

Is there any update on this? It is quite annoying office 365 users can't use chrome...

Labels: -Pri-2 -M-45 Pri-1 M-50
Targeting M50 for Chrome on Windows. Switching owner to asanka@.

Comment 59 by Deleted ...@, Dec 23 2015

Microsoft has posted a solution to this issue. See if this helps. This solved my problem.
I am on Windows 7 64 bit, using Chrome Version 47.0.2526.106 m (64-bit)

1. On the computer where the web browser is experiencing the issue, start Registry Editor (regedit), and locate the following subkey.

2. In the Lsa subkey, locate the SuppressExtendedProtection value. If the value does not exist, you must add it. To add the value, right-click Lsa, point to New, and then click DWORD (32-bit) Value. Type SuppressExtendedProtection, and then press ENTER.

3. Right-click SuppressExtendedProtection, click Modify, and enter 1 (REG_DWORD).

4. Click OK and close Registry Editor.

Sudip Kumar Bhattacharya

Comment 60 by, Dec 23 2015

Sudip: That's not a solution, you're just disabling the security feature that causes the problem discussed in this bug. That may not be a problem in your scenario, but others should be aware of the ramifications of making that change as it will reduce system security and may open clients to exposure to the very attacks that Channel Binding Tokens are meant to mitigate.

See comments #45 & #46 for more details.

Comment 61 by, Feb 18 2016

OMG. Approaching 3 years on a problem and no fix or even hints that they plan to solve this problem. 
At least they should state that they don't care about enterprise users then we'll know to even ban the browser from enterprise infrastructure.
Sorry for how long this has taken and thanks for your patience on this. It is being actively worked on. It is targeted for Chrome 50 or 51.
Another +1 here. Hopefully this gets implemented. My testing mirrors Comment 27. Seamless with IE/Firefox. issues with chrome when EPA required.
Adding myself as well.  We are using ADFS 3.0 and it does not work.  No problems with IE or Firefox.  C'mon Chrome... get this fixed globally!!
Rick from Comment #51.  This does not work with our implementation of ADFS 3.0  I have the same supported user agents as you (even added Edge/12) and it still doesn't work.
Project Member

Comment 66 by, Mar 23 2016

The following revision refers to this bug:

commit 5ffd5d79244e6c9928ed465fcfed8a136d04140a
Author: asanka <>
Date: Wed Mar 23 16:20:49 2016

[net/http auth] Support channel bindings for HTTP authentication.

Start using tls-server-end-point channel bindings for HTTP
authentication if a certificate is available. The current implementation
should work on Windows and Posix. Currently only SHA-256, SHA-384, and
SHA-512 are supported for generating channel bindings.

BUG= 270219,

Review URL:

Cr-Commit-Position: refs/heads/master@{#382858}


Labels: -M-50 M-51
This change is now in Chrome Canary 51.0.2690.0 and later (not on Dev yet). It'd be great if those affected could try it out before things get locked down for  M51 branch.
Chrome Stable channel doesn't let me into my test systems, Canary channel build mention in #67 I get in just fine.
Hi Brock, that is normal. The change is only available in Canary and will roll out to Stable once 51 gets to Stable.

Thanks for verification. For others who were affected by this, as per #67, please give Chrome Canary a try and let us know if it works on that.

Comment 70 by, Mar 25 2016

I just tested with Carany, I confirm it works without any issue and I can login to office365. 

Thanks a lot for doing this! 
Tested with Canary successfully through ADFS integration with Aerohive. Thank you and please provide update when this moves through to stable channel. 

Labels: OS-Linux
Status: Fixed (was: Started)
Cool. Thanks for verifying. The fix will be in Chrome 51.

Comment 73 by, Mar 26 2016

Verified functioning properly with ADFS 2.0 IWA/WIA (Depending on what MS wants to call it today) withing my environment for o365, yardi and Payables Nexus.

Much appreciated.
Labels: OS-Mac
Verified that it is working in my enterprise environment, and even with ADFS integrated apps like MozyEnterprise. Thank you all for the fix!!!!
Thanks all for testing. Can we have more thorough test runs? It's great this is solving the particular problem at hand, but we want to make sure it's not breaking something unexpected.

Before we have enough such input it would be hard to promote this to stable.
I have confirmed Carany works with ADFS 3.0 Integrated Windows Auth!  Much appreciated.  When will this go live in the Chrome?
Interestingly, the 51 canary does *not* solve my login problem, even though it helped many other users here. Is there anything I need to do in addition?

At the moment, I'm still being redirected to a login page ( and need to manually enter my username and password there.

Also, being "only" a user in my company, what is the easiest way for me to find out what exact technology is used for this login page? (I assumed from the URL that it was ADFS, but I might be wrong, which could explain why this fix doesn't help in my case.)
In case anyone missed this, the OS tags are Windows, Mac, and Linux. This is not expected to work on Chrome OS.
birgit, without knowing your system and your environment, it makes it difficult to answer or add guidance.
If you provide your credentials does it actually log you in or re-prompt for credentials immediately?
Are you getting forms based authentication or a pop-up?
Are you communicating with an ADFS server or ADFS Proxy
Which version of ADFS? 
Are you accessing it across the companies private network or externally over the internet?
If access is company internal, is the ADFS server performing FBA fallback?
What kind of device and version?
Are the certs and systems involved in ADFS trusted?
And those are the questions I would start with.
There are few things dependent upon you and there are a few things that are dependent upon your IT department.

Hi g, thanks for the detailed questions!
* If I provide credentials, it actually does log me in (and keeps me logged in until the next time I close Chrome).
* Authentication is forms based with a login site that was obviously customized for our company (containing logo and photo), and contains the attached login form. Login can be done with email + password or domain\username + password.
* How can I find out what ADFS version is used, being only a user? Most informative thing I found so far is when I tried to open a page ("ABC-123") in "view source" mode, and got something like this:

<body><p>Please wait, we're redirecting you...</p><form method="POST" enctype="application/x-www-form-urlencoded" action=""/><input type="HIDDEN" name="SAMLRequest" value="abcabc_OBFUSCATED_abcabc"/><input type="HIDDEN" name="RelayState" value="/browse/ABC-123"></input></form><script type="text/javascript">window.onload = function () { document.forms[0].submit(); }</script></body>

After that, I'm redirected to the login page described above.

* FBA fallback: Probably that's what this is, yes... ? When opening the same page ("ABC-123") in Internet Explorer, I see the same "Please wait, we're redirecting you..." for a second, but are then automatically logged in and forwarded to the page I wanted to view.
* I'm accessing it from within the company's private network.
* Device: Chrome 51.0.2694.0 canary on Windows 7 Enterprise SP 1 64bit.
* All involved sites are added as "Trusted Sites" in Windows' "Internet Options", and once I'm logged in, the certificates look okay too.
* I have no influence on our IT department, which merely tolerates Chrome on company computers but won't put any effort into actively supporting it. So any fix needs to be feasible solely on my side.
8.7 KB View Download
Pinging the thread again. Do we have someone who has performed more extensive testing with this change? We want to ensure we find any bugs while still in dev and beta.
dskaram, what kind of more extensive testing are you looking for? more environments, or specific configurations? Or more SSO implementations?
Mainly across a wider user base that is using different applications on a daily basis. One problem we've had constantly with admins testing on dev and beta is that they only uncover issues in the applications that affect them and not the ones that affect the daily business of their users.

That's why we generally advise that 5% of **all** users, not only of admin users, are placed on the beta channel.

My impression from the comments so far is that this has been checked and verified by admins. But this doesn't tell us much on how this will affect users once it hits stable and users are revved up.
dskaram, I would be willing to deploy this to my 30-some team of users, but I don't think I would want to do it with Canary. If this got promoted to beta, I would be willing to ask them to install the beta channel to test it for a week or so.

Personally though, I have used Canary on just about all of our ADFS integrated apps and the SSO works as expected.

What I'm afraid of is the other quirks and possible issues in canary that would frustrate my general user-base.
Beta is very reasonable and is our regular recommendation for staging. Dev and canary might be disruptive to regular user flow.

The more user-base coverage we get while this is in beta, the higher the chances are to uncover any issues early on.

I will update this thread again when this fix lands in the beta channel.
Birgit, my guess is they are using ADFS 2.1 or 3.0 on 2012R2 but that is only a guess. My next guess would be that you are failing for supported user agent and that the supported useragent list would need to be updated on the ADFS server which isn't going to get you very far if your IT department is unwilling to assist. You might be able to get around it by modifying the UserAgent supplied by chrome, but others would have to go into more detail as to how this is performed as I am not a routine Chrome user but an admin supporting ADFS.

Only a few devs and admins using canary (7 users). Can't get buy off on larger user base for testing on alpha.

Hi g, thanks for the hints! I can confirm now that if I modify the user agent string to IE10 (using "User-Agent Switcher for Chrome"), then I can log in without problems. This in fact even already works with my "old" Chrome 48.0.2564.109 m.

Comment 90 Deleted

Seems to be fixed with Version 52.0.2717.0 canary (64-bit). Now just waiting, that this fix is pushed to stable...
M51 is making its way into Beta. Call out to admins to please roll out this fix by putting more "real" users into Beta. This will help us ensure a smooth transition into Stable.
Hi All - 
I'm not sure who to post this too, but in our testing, we are able to access Office 365 via ADFS which validates this fix, but we are seeing slow page loads in general with this the Beta Build (51.0.2704.36 beta-m (64-bit)).  We have several people at out site testing and seeing similar issues.  Any advice?

The effect on page load speed from this particular change should be minimal. We didn't observe any significant regressions that were attributed to this change on our pre-release channels. If there are general performance issues with M51, it's best to follow the instructions at and filing a performance bug.

In what build of Chrome (non-Canary) might this get released? I still have users calling about this problem and am not sure to tell them to update Chrome or to use a different browser.
#95: Which platform? For Windows clients this should be in stable already.

Comment 97 by, Jun 9 2016

Can confirm, it works fine with latest stable version in Windows. 
Hey, this is great.  I'm the original poster and I'd honestly given up hope that this would ever get fixed after 2.5 years.  Thanks for working this out.  

I have tested "Require Extended Protection" with the latest version of Chrome and it works!
Never give up hope! Google loves admins!

Sign in to add a comment