1179722 - kerberos-sspi authentication on windows with extended protection does not work. (Enable Extended Protection (channel and service binding) for Kerberos SSPI authentication)

Status: RESOLVED DUPLICATE of bug 1895277

(Core :: Networking, defect, P2)

Description

[William]

Attachment: firefox_log.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Steps to reproduce:

On our site we use kerberos authentication to our intranet websites. This works ok when I enable NTLM or use the gssapi32.dll from MIT kerberos but not with sspi on windows.

the output from negotiateauth is attached for a session with extended protection on and off.

Also when i disable the extended protection it works see: https://support.microsoft.com/en-us/kb/976918/en-us




Actual results:

I get a popup where i have to logon to the website.


Expected results:

It should have logged me in sso.

Comment 1

[William]

This is fixed for ntlm but seems not to work for sspi kerberos.

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

Comment 2

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 3

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 4

[Mike Kaply [:mkaply]]

Documentation is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1179722 (I think)

Here's another detailed scenario:

https://support.mozilla.org/en-US/questions/1296796

chrome added this support in 51.

Comment 5

[Johan Corveleyn]

Just ran into this problem while trying to enable the ExtendedProtectionTokenCheck setting on an ADFS that was used for authentication for one of our internal web services. Though our Chrome users had no problem with it, FireFox users could no longer authenticate, so we had to disable the setting again, unfortunately.

This is an important security feature for hardening the authentication interaction. Please, could someone of the developers take a closer look and try to tackle this issue?

Comment 6

[Rende]

(In reply to Johan Corveleyn from comment #5)

Just ran into this problem while trying to enable the ExtendedProtectionTokenCheck setting on an ADFS that was used for authentication for one of our internal web services. Though our Chrome users had no problem with it, FireFox users could no longer authenticate, so we had to disable the setting again, unfortunately.

This is an important security feature for hardening the authentication interaction. Please, could someone of the developers take a closer look and try to tackle this issue?

Hi Johan,

Did you set 'ExtendedProtectionTokenCheck ' from None to Allow or from Allow to Require?
This setting is here set to "Allow" and gives no authentication issues.

Did you install the following security patch?
Maybe related to the issue you described, we enabled a security patch (https://support.microsoft.com/nl-nl/topic/managing-deployment-of-kerberos-s4u-changes-for-cve-2020-17049-569d60b7-3267-e2b0-7d9b-e46d770332ab) and perform the second step (set the registerkey 'PerformTicketSignature' to 1), after some time our Firefox users cannot signin anymore into sites through ADFS.

Comment 7

[Mike Kaply [:mkaply]]

Here's where the patch went in for Chrome - https://bugs.chromium.org/p/chromium/issues/detail?id=270219#c66

Here's the actual patchset:

https://codereview.chromium.org/1408433006/#ps1

Unfortunately I pasted the wrong thing in my comment and I can't find the documentation anymore.

I'm not sure about prioritization, but I'll put this on folks radar.

Can anyone seeing this tell me how pervasive this is? Like do a lot of people use this and can't use Firefox?

Comment 8

[Mike Kaply [:mkaply]]

The specific SSPI change in question for Chrome is here:

https://codereview.chromium.org/1408433006/patch/100001/110039

I think this is the documentation

https://msrc-blog.microsoft.com/2009/12/08/extended-protection-for-authentication/
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rpce/6b733b95-3fd9-4ad5-ba4f-28e548db1c24?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/windows/win32/api/sspi/ns-sspi-sec_channel_bindings?redirectedfrom=MSDN

Comment 9

[Rende]

(In reply to Mike Kaply [:mkaply] from comment #7)

Here's where the patch went in for Chrome - https://bugs.chromium.org/p/chromium/issues/detail?id=270219#c66

Here's the actual patchset:

https://codereview.chromium.org/1408433006/#ps1

Unfortunately I pasted the wrong thing in my comment and I can't find the documentation anymore.

I'm not sure about prioritization, but I'll put this on folks radar.

Can anyone seeing this tell me how pervasive this is? Like do a lot of people use this and can't use Firefox?

This is the combination in our environment:

• Firefox installed on a domain-joined pc
• ADFS server configured in the about:config setting : Network.automatic-ntlm-auth.trusted-uris
• "Mozilla/5.0" is added (default(?)) in ADFS WIASupportedUserAgents
• 2nd phase of the patch "cve-2020-17049" installed on all DC's (https://support.microsoft.com/nl-nl/topic/managing-deployment-of-kerberos-s4u-changes-for-cve-2020-17049-569d60b7-3267-e2b0-7d9b-e46d770332ab)

Comment 10

[Johan Corveleyn]

(In reply to Rende from comment #6, and Mike Kaply)

Hi Johan,

Did you set 'ExtendedProtectionTokenCheck ' from None to Allow or from Allow to Require?
This setting is here set to "Allow" and gives no authentication issues.

Did you install the following security patch?
Maybe related to the issue you described, we enabled a security patch (https://support.microsoft.com/nl-nl/topic/managing-deployment-of-kerberos-s4u-changes-for-cve-2020-17049-569d60b7-3267-e2b0-7d9b-e46d770332ab) and perform the second step (set the registerkey 'PerformTicketSignature' to 1), after some time our Firefox users cannot signin anymore into sites through ADFS.

Sorry for the late response. I have received some more details from our sysadmin:

'ExtendedProtectionTokenCheck ' was changed from None to Allow (the Require option has not been tested)
The security patch mentioned was installed, but the registry keys are not created.

These two bullets in Rende's list also apply to our situation:

• Firefox installed on a domain-joined pc
• "Mozilla/5.0" is added (default(?)) in ADFS WIASupportedUserAgents

Comment 11

[simon.knaggs]

I can confirm this bug still exists, and that as per the timings of the CVE, this setting is now set to enforced, with no way around it: https://support.microsoft.com/en-us/topic/kb4598347-managing-deployment-of-kerberos-s4u-changes-for-cve-2020-17049-569d60b7-3267-e2b0-7d9b-e46d770332ab

In our case it was enforcing kerberos auth only on the ADFS server that resulted in Firefox users getting broken authentication. The firefox client simply sits on the adfs page with the response in the URL in this format:

https://adfsservername.domain.com/adfs/ls/wia?SAMLRequest=CLOBBER&RelayState=%2F&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=CLOBBER&client-request-id=CLOBBER

It would be nice to allow our firefox preferring folks to be able to use their preferred browser again - we use ADFS for authenticating various systems. They currently have to use Chrome or Edge Chromium. The thing that makes me especially sad is that this even works in IE.

Happy to help test and updates to this if someone wants to progress this one.

Comment 12

[Dragana Damjanovic [:dragana]]

Mike, should we change priority for this?

Comment 13

[Mike Kaply [:mkaply]]

(In reply to Dragana Damjanovic [:dragana] from comment #12)

Mike, should we change priority for this?

Definitely. I tried to get some traction on it earlier this year but couldn't find the right people.

Comment 14

[Dragana Damjanovic [:dragana]]

Jens, can you find someone to look into this? We might be able to reuse most of the code from bug 573043, but I have not look very closely.

Comment 15

[Jens Stutte [:jstutte]]

Christoph, can you?

Comment 16

[simon.knaggs]

Hey folks, any movement on this? In addition to our internal users experiencing this issue, we develop a web app and have now had reports from customers of similar issues with Firefox + ADFS, and have sadly had to let them know of this bug and that they'll need to use a browser other than Firefox if authenticating against ADFS. As I say, very happy to help in any testing, as would a number of our devs who greatly prefer Firefox.

Comment 17

[Max Faxälv]

We are also running into this at my workplace. A specific site works fine in Chrome but does not work at all in Firefox. Would be really sad to recommend people to switch.

I'd love to help testing if I can be of assistance.

Comment 18

[matt.keating]

I am also running into this at my workplace. +1 for fixing this issue.

Comment 19

[Christoph Kerschbaumer [:ckerschb]]

Martinho offered to take a look.

Comment 20

[edgul]

Hi all,
Can anyone provide me access to or point to an example server (ideally pre-configured) to replicate this issue?
Also a mozregression range may be useful (?)

Comment 21

[Mervyn Morris]

I have experienced this similar issue with Firefox after changing the ADFS SSL certificate to a SHA384 certificate. It seems like the issue was resolved for SHA256 SSL cert on the ADFS server.

Comment 22

[Tim van Dijen]

(In reply to Dragana Damjanovic [:dragana] from comment #14)

Jens, can you find someone to look into this? We might be able to reuse most of the code from bug 573043, but I have not look very closely.

Looking at that code, it seems exactly what has to happen!

Comment 23

[Kershaw Chang [:kershaw]]

(In reply to Mervyn Morris from comment #21)

I have experienced this similar issue with Firefox after changing the ADFS SSL certificate to a SHA384 certificate. It seems like the issue was resolved for SHA256 SSL cert on the ADFS server.

Hi, could you try to capture a http log that shows this issue?
In about:logging, please select Logging to file and send the log file to [e-mail].
Thanks.

Comment 24

[Mervyn Morris]

(In reply to Kershaw Chang [:kershaw] from comment #23)

(In reply to Mervyn Morris from comment #21)

I have experienced this similar issue with Firefox after changing the ADFS SSL certificate to a SHA384 certificate. It seems like the issue was resolved for SHA256 SSL cert on the ADFS server.

Hi, could you try to capture a http log that shows this issue?
In about:logging, please select Logging to file and send the log file to [e-mail].
Thanks.

Good day,

I do apologize but because this was our production environment we were forced to revert to a SHA256 SSL Cert which has allowed functionality for at least another year. I wouldn't be able to reproduce the issue at this moment.

Comment 25

[Tim van Dijen]

Probably because the NTLM code for channel binding uses a fixed size for the hash; https://hg.mozilla.org/integration/mozilla-inbound/rev/e01dbdb4c7e1#l1.125
It's not necessarily related to this specific issue.

Comment 26

[Kershaw Chang [:kershaw]]

We will try to fix this in bug 1895277.