NTLM authentication to AD FS for non-IE browser without 'Extended Protection' switched off?

Question

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.

Solution

According to

• http://technet.microsoft.com/en-us/library/hh237448(v=ws.10).aspx
• http://support.microsoft.com/kb/2461628/en-us

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.

[...]

Comments

[MarnixKlooster ReinstateMonica]

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]

And the bounty is coming your way. Thanks!!

[oleschri]

@Marnix Cool, thx :) - Did the registry hack work for you then?

[MarnixKlooster ReinstateMonica]

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.

[mattgately]

@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.