Open Bug 1179722 Opened 6 years ago Updated 1 month 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, P3)

Product:
Core
Component:
Networking
Version:
38 Branch
Platform:
x86
Unspecified
Type:
defect

Tracking

()

People

(Reporter: kc, Unassigned)

References

(Blocks 1 open bug)

Details

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

Attachments

(1 file)

firefox_log.zip
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
You need to log in before you can comment on or make changes to this bug.