Negotiate Auth on Windows (SSPI) does not ask for credentials
Categories
(Core :: Networking: HTTP, enhancement, P3)
Tracking
()
People
(Reporter: bugzilla-mf, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][ntlm])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/82.0.4080.0 Safari/537.36 Edg/82.0.453.2
Steps to reproduce:
Firefox 68.5.0esr (32-Bit)
URL is set in
network.negotiate-auth.trusted-uris
network.negotiate-auth.delegation-uris
Load webpage with required Negotiate Auth on IIS.
Actual results:
There was no means of using other credentials than the current user, who has Firefox launched.
Expected results:
The Firefox instance is run as an account, which does not have the rights for the webpage. So there should be a prompt for user credentials on Windows with SSPI. IE does ask for credentials according to the security zone settings in the internet options.
If the URL is removed from the negotiate-auth.trusted-uris
, Firefox does not react to the Negotiate Authentication header at all. A prompt here COULD be displayed to the user, who can then decide to cancel or enter the credentials.
It seems that the assumption is, that SSPI cannot set the user credentials like GSSAPI. Thus the identityInvalid Flag is always set to false, preventing a prompt for credentials. (https://searchfox.org/mozilla-central/source/extensions/auth/nsHttpNegotiateAuth.cpp#154)
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Updated•5 years ago
|
Comment 3•5 years ago
|
||
// Always set *identityInvalid == FALSE here. This
// will prevent the browser from popping up the authentication
// prompt window. Because GSSAPI does not have an API
// for fetching initial credentials (ex: A Kerberos TGT),
// there is no correct way to get the users credentials.
code.
Docs for AcquireCredentialsHandle and its Negotiate version say we would need to pass a result of SspiPromptForCredentialsW function call to pass credentials.
IIRC, we have a fallback when default credentials don't work with NTLM. We optionally pass credentials to SSPI/NTLM or Kerberos here.
But for Negotiate it's bit more tricky. It would also be great if you could provide an HTTP log to verify your web server is configured properly and the bug is valid. You can send to my bugzilla email.
I'm afraid no one on the Necko team has time to work on this right now, though.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
From privately exchanged data I can see that on failure to authenticate with the default credentials the server responds with 400. Even we had a code to ask for credentials via a dialog as mentioned in comment 3, we would not retry and just render the 400 response.
Possible ways to move forward here:
- implement comment 3 + change the server to re-request authentication properly with 401
- implement a new preference to force asking for credentials for certain host asking for
Negotiate
authentication and use the proposal from comment 3 to open the dialog and grab credentials manually from the user on the first try to authenticate - hybrid of the two: when the server responses with 401 to default credentials, have a preference allowing to certain hosts to ask for credentials manually and retry.
Personal preference is the last option to minimize impact on existing infras.
I'm afraid no one on the necko team has time right now to work on this. Leaving as P3 for now, also as this is quite a corner case use of default credentials.
Updated•2 years ago
|
Hi everyone,
Is there any solution on this? I came to this post with the same issue.
Thank you in advance.
Updated•2 months ago
|
Description
•