Open Bug 1179722 Opened 9 years ago Updated 4 months ago

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

Categories

(Core :: Networking, defect, P2)

38 Branch
x86
Unspecified
defect

Tracking

()

People

(Reporter: kc, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-backlog][ntlm])

Attachments

(1 file)

899 bytes, application/zip
Details
Attached file 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.
This is fixed for ntlm but seems not to work for sspi kerberos.

https://bugzilla.mozilla.org/show_bug.cgi?id=573043
Component: Untriaged → Security
Hardware: Unspecified → x86
Component: Security → Networking
Product: Firefox → Core
Whiteboard: [necko-backlog][ntlm]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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?

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

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?

(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:

(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

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.

Mike, should we change priority for this?

Flags: needinfo?(mozilla)

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

Flags: needinfo?(mozilla)

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.

Flags: needinfo?(jstutte)

Christoph, can you?

Flags: needinfo?(jstutte) → needinfo?(ckerschb)

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.

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.

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

Martinho offered to take a look.

Assignee: nobody → bugs
Status: NEW → ASSIGNED
Flags: needinfo?(ckerschb)
Priority: P3 → P2
Assignee: bugs → eguloien

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 (?)

See Also: → 1781743
Severity: normal → S3
Assignee: edgul → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: