so, have web-site configured for ADFS 2.0 authentication...
for IE - it works fine and did authentication correct
for Chrome - it reaches redirect to AD FS server... ask to authenticate but could not authenticate.
I try to requests using fiddler but it show nothing interesting - so show that we redirect to adfs for authentication but nothing more
what it could be? why it is impossible to authenticate for chrome
thanks
In the event viewer you will see an 'Audit Failure' event with "Status: 0xc000035b". You can circumvent this problem by switching off 'Extended Protection' for the adfs/ls web application.
There are several articles on the Web on this, for example the "0xc000035b error during windows integrated login" thread on Microsoft's AD FS forum. Quoting:
To turn Extended Protection off, on the AD FS server, launch IIS Manager, then, on the left side tree view, access Sites -> Default Web Site -> adfs -> ls. Once you’ve selected the "/adfs/ls" folder, double-click the Authentication icon, then right-click Windows Authentication and select Advanced Settings… On the Advanced Settings dialog, choose Off for Extended Protection.
This issue occurs in several situations that I know of: when using Firefox 3.5+ or Chrome, using some specific NTLM configuration for which I don't have the details at hand, and when using Fiddler (see the "AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger" TechNet article post, and the "Fiddler and Channel-Binding-Tokens" blog post which contains more technical background information).
(Note that nowhere I could find any information how to make NTLM authentication to AD FS from, e.g., Google Chrome and Firefox 3.5+ work without switching off 'Extended Protection'. I mean, Internet Explorer works with 'Extended Protection', why don't Chrome or Firefox? Or is this a Chrome/Firefox implementation bug/restriction, e.g., in their use of the Windows NTLM library?)
From Microsoft: http://technet.microsoft.com/en-us/library/hh852537.aspx
Unless and until Firefox, Google Chrome, and Safari support Extended Protection for Authentication, the recommended option is to install and use Internet Explorer 10 or later. If you want to use single sign-on for Office 365 with Firefox, Google Chrome, or Safari, there are two other solutions: (1) Uninstall the Extended Protection patches from your computer. (2) Change the Extended Protection setting on the Active Directory Federation Services 2.0 server. See “ExtendedProtectionTokenCheck” on the TechNet Set-ADFSProperties page for details.
Switching off extended protection is not the answer. You add chrome as so adfs can recognize it and then add the site to the trusted list.
Make sure chrome is supported by adfs. So, if you run the following commands:
$a=Get-Adfsproperties
$a.WIASupportedUserAgents
Then you add chrome to the list.
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")
Now, we will need to tell the Chrome that it should allow Windows Integrated Auth for the site.
To do this, you will need to go to the settings: Click on Advanced Click on Proxy settings It should open your IE Properties. Click on Security & Select "Local Intranet" and add the Federation service name of your ADFS here. Click close and Apply under IE Properties. Restart Chrome and next time when you try to access the site, it won't ask you for credentials.
This was a solution presented at work to allow SSO with Chrome WITHOUT disabling Extended Protection. Cheers for MS support.
