6

When using NTLM authentication to AD FS 2.0, from Google Chrome or Firefox 3.5+ running on Windows, then this results in a repeated sign-in dialog and finally sign-in failure, with 'Audit Failure' events with "Status: 0xc000035b".

This can be 'solved' by switching off 'Extended Protection' for the "/adfs/ls" web application in IIS. This is documented in several places; see my answer to another StackOverflow question for details.

My question is: How can one make NTLM authentication to AD FS work for these browsers without switching off 'Extended Protection'? I mean, in Internet Explorer this works fine with 'Extended Protection' on, 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?

Update: I should have mentioned that I'd like to do this without forcing people to make changes in their browser settings.

Community
  • 1
  • 1
MarnixKlooster ReinstateMonica
  • 9,640
  • 14
  • 54
  • 108

2 Answers2

10

According to

this is a Chrome / Firefox / Safari implementation restriction if

  • the client is running Windows 7 and the server has ExtendedProtectionTokenCheck set to Require or Allow
  • the client is running Windows XP or Vista - without appropriate updates(!) and the server has ExtendedProtectionTokenCheck set to Require

Maybe you can suppress Extended Protection on your clients with this: http://support.microsoft.com/kb/976918/en-us

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

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.

[...]

oleschri
  • 2,012
  • 11
  • 21
  • And the bounty is coming your way. Thanks!! – MarnixKlooster ReinstateMonica Jul 27 '11 at 14:33
  • @Marnix Cool, thx :) - Did the registry hack work for you then? – oleschri Jul 27 '11 at 14:54
  • Haven't been able to check the registry hack yet, but I was looking for a server-side setting, and that's what the linked docs provide. This way we can tell our customers: "Sorry, non-IE doesn't work without this server side setting, see here for MSFT's information." But when I try the registry hack, I'll comment on that here. – MarnixKlooster ReinstateMonica Jul 27 '11 at 16:12
  • 1
    @Marnix: The registry hack worked for me with Chrome. Immediately after creating the SuppressExtendedProtection=0x1 value, I was able to sign in to office365.com after just one password dialog, whereas before it would repeatedly ask for credentials until failing. – mattgately Mar 04 '14 at 16:44
0

Extended Protection was designed to prevent kerberos ticket replay attacks.

As I understand it, it works in IE because the default for ADFS is Windows Integrated Authentication which IE handles "under the hood".

When I investigated this a while back, if I remember correctly, there is a workaround for Firefox.

rbrayb
  • 46,440
  • 34
  • 114
  • 174
  • 1
    This doesn't really answer my question, I think, which is more about _why_ IWA (Integrated Windows Authentication) behaves differently between IE and Firefox/Chrome. But I would be interested to know what one would need to change on the client side to make Firefox work. – MarnixKlooster ReinstateMonica Jul 23 '11 at 20:25