Issue with SSO and Extended Protection (Channel Binding) for OWA/Exchange in Firefox

[Florian Singer]

 

Hi,

 

we recently enabled the "Extended Protection" security feature on our Exchange servers to defend against authentication relay and man-in-the-middle (MitM) attacks (see: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21410).

Since enabling this feature, SSO login (Single Sign-On) with Firefox is no longer working. Instead of automatic login, we are always prompted for Basic Authentication credentials:

 

 

With Chrome and Edge, SSO continues to work as expected.

 

Our assumption is that this may be due to missing support for channel binding in Firefox, or perhaps there is an unknown configuration option we missed.

Can you confirm whether this behavior in Firefox is known? Is there any configuration or planned change to support channel binding?

 

We would appreciate any feedback or advice you can provide.

 

Thank you very much and best regards,

 

 

Florian Singer

-- 

 

Landeshauptstadt München

IT-Referat

it@M

 

Geschäftsfeld Infrastruktur, Basisservices und Support

Stadtweite Basisanwendungen

Serviceteam Kommunikation & Kollaboration

Browser (Chrome, Edge, Firefox), VLC Media Player

 

 

[Mike Kaply]

What version of Firefox are you using?

Are you using NTLM or Kerberos?

We did fix something similar a while back.

https://bugzilla.mozilla.org/show_bug.cgi?id=1895277

This is something that would probably best be opened as a bugzilla bug.

Mike

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/ecb6cff1f24e458cb825927876eeca73%40muenchen.de.

[Florian Singer]

Hi,

 

thank you for your quick response!

We have tested with Firefox versions 140.13esr and 153.0esr.

 

We are using Negotiate authentication (Kerberos or NTLM, depending on the environment) for SSO with our Exchange OWA/EWS setup. In both cases, the issue occurs as soon as Extended Protection (Channel Binding) is enabled on the server.

 

We have seen Bug 1895277 and wanted to check with you first. If you do not have any further suggestions or ideas, we will open a new Bugzilla entry for this issue in the near future.

 

Thank you very much for your support!

 

Best regards,

[Mike Kaply]

And it failed in both 140 and 153?

I think we definitely want a new bug for this. 

Please let me know the bug when it is opened.

Thank you

Mike Kaply

[Mike Kaply]

Could you try one quick test on a single client machine? This will tell us a lot about where the problem is.

In `about:config`:

1. Find `network.negotiate-auth.trusted-uris` and remove your OWA/EWS host from it (save the current value first so you can put it back).
2. Find `network.automatic-ntlm-auth.trusted-uris` and add that same host to it.
3. Confirm `network.auth.force-generic-ntlm` is set to `false` (this is the default).
4. Restart Firefox and try logging in to OWA.

Does SSO work now, with Extended Protection still enabled on the server?

If yes, that confirms our theory: Firefox sends the channel binding token correctly when it authenticates over NTLM, but not when it authenticates over Negotiate/Kerberos. That's a concrete missing feature we can point at.

This is a diagnostic, not a recommended configuration — it means your users authenticate with NTLMv2 instead of Kerberos. The channel binding is still sent, so the relay attack Extended Protection guards against is still blocked, but Kerberos is the better option and we'd want to get you back to it.

Mike

[Florian Singer]

Hi,

 

thank you for the detailed instructions.

 

I have performed the test as described:

 

• Removed our OWA/EWS host from network.negotiate-auth.trusted-uris
• Verified that our domain was already present in network.automatic-ntlm-auth.trusted-uris (no change was necessary)
• Confirmed that network.auth.force-generic-ntlm is set to false
• Restarted Firefox and attempted to log in to OWA

 

Unfortunately, SSO still does not work in Firefox with Extended Protection enabled on the server.

 

We have now created a Bugzilla entry for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=2060492

 

Best regards,

 

Florian

-- 

[Mike Kaply]

Thanks for testing that. Before we conclude anything, I think we may have run into a configuration subtlety rather than a real result, so there are two things I'd like to check.

The first is that those trusted-uris preferences match on domain suffix, not on exact hostname. If network.negotiate-auth.trusted-uris contains an entry like company.com or .company.com, then removing just the specific OWA hostname wouldn't have changed anything, because the domain entry still matches. Your note said you removed the host from the negotiate list but that the NTLM list already contained your domain, which makes me suspect both lists are configured at the domain level and Firefox stayed on the Negotiate path throughout the test.

Could you try again on one machine, this time clearing network.negotiate-auth.trusted-uris completely so the value is empty, rather than removing a single entry? Leave the NTLM preference alone. It's also worth confirming that network.negotiate-auth.allow-non-fqdn is set to false, since that can put Firefox back on the Negotiate path on its own.

The second thing is whether your Exchange servers still offer NTLM at all. A lot of organisations disable NTLM at the same time as enabling Extended Protection, since both are part of the same hardening effort. If yours has, then the test can't succeed no matter how the preferences are set, and there's no point retesting.

Your Exchange administrator can check with this:

Get-WebConfiguration -Filter '/system.webServer/security/authentication/windowsAuthentication' -PSPath 'IIS:\Sites\Default Web Site\owa' | Select -ExpandProperty providers

Or you can check from the browser without involving anyone. Press F12 in Firefox to open the developer tools, switch to the Network tab, reload the OWA page, click on the request that comes back with a 401, and look at the response headers for WWW-Authenticate. Just let us know which authentication schemes are listed there.

If NTLM isn't among them, that answers the question and you can skip the retest.

Thank you!

Mike Kaply

[Florian Singer]

Thank you for your detailed explanation and suggestions.

 

I checked which authentication methods are offered by our Exchange server using Firefox’s developer tools. The response headers for the OWA site show:

• WWW-Authenticate: Negotiate
• WWW-Authenticate: Basic realm="owa.ourdomain.de"

 

NTLM is not listed as an available authentication method.

 

Nevertheless, I proceeded with the test as you described:

• network.negotiate-auth.trusted-uris was set to (empty)
• network.automatic-ntlm-auth.trusted-uris was set to .ourdomain.de
• network.negotiate-auth.allow-non-fqdn was set to false

 

Unfortunately, the issue remains unchanged. SSO does not work in Firefox when Extended Protection is enabled on the server.

 

Thank you again for your support!

[Mike Kaply]

Just for everyone's information, this fix landed in all versions of Firefox (including 140ESR and 153ESR) and will release next week.

Mike