1303314 - network.automatic-ntlm-auth.allow-non-fqdn does not work

Status: RESOLVED INVALID

(Core :: Networking, defect, P2)

Description

[Dennis Jakobsen]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160421124000

Steps to reproduce:

set network.automatic-ntlm-auth.allow-non-fqdn to true


Actual results:

I am prompted for login credentials


Expected results:

Firefox should just use my credentials and log me in.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

Can you tell us which version of Firefox are you using?
Can you check if it also happens with the latest nightly? http://nightly.mozilla.org/

Comment 2

[Ilguiz Latypov]

Attachment: loading-ntlm-short-hostname-stalls.png

Comment 3

[Ilguiz Latypov]

Attachment: about-config-ntlm.png

Comment 4

[Ilguiz Latypov]

Loading a short-host-name NTLM page in Nightly 56.0a1 (2017-07-04) (32-bit) for Windows always stalls after replacing my long list of trusted-uris with a couple domain names.  The "loading-ntlm-short-hostname-stalls.png" screenshot shows that the browsers does not receive and/or display responses to requests for some of the page's resources where a 401 Unauthorized followed by an NTLM negotiation would normally take place.

Opening the same page under the full host name worked.

Comment 5

[Ilguiz Latypov]

Attachment: loading-fqdn-hostname-stalls.png

Loading another page in the NTLM-protected sharepoint site just stalled on me again, despite my using a fully qualified domain name of the site.

Comment 6

[Ilguiz Latypov]

The previous comment with a stalled FQDN hostname turned due to the site's database malfunctioning.  I just got a response to my page load attempt:

    Unable to connect to database.  Check database connection information and make sure the database server is running. 

Please ignore the previous comment. I figure only opening short host names after setting non-fqdn to true results in unexpected stalls.  Thanks for understanding.

Comment 7

[Firefox Bug Husbandry Bot]

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

Comment 8

[Valentin Gosu [:valentin] (he/him)]

Closing as incomplete since we've received no input since the initial report.

Comment 9

[Dennis Jakobsen]

No URI's work. FQDN or non-FQDN both broken. Always prompted for credentials.

Comment 10

[Kershaw Chang [:kershaw]]

Hi Dennis,

Could you try to capture a HTTP log for us?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Thanks.

Comment 11

[Dennis Jakobsen]

Yes, ofcourse

Comment 12

[Dennis Jakobsen]

Attachment: log-main.12648.txt.zip

Http log from visiting lan webserver with auth(saved credentials are prompted).

Comment 13

[Dennis Jakobsen]

Attachment: ff-winauth-sharepoint2013-failure.zip

Http log for a winauth attempt against sharepoint 2013 with screenshot of a 401 in the network panel. Here it automatically authorizes, but apparently with some credentials that dont work.

Comment 14

[Kershaw Chang [:kershaw]]

Honza, could you take a look at the log?

Thanks.

Comment 15

[Honza Bambas (:mayhemer)]

Yup, fresh info available, thanks for it!

Comment 16

[Honza Bambas (:mayhemer)]

Finally got back to this bug.  Apparently, as seen in the log, we are failing somewhere at [1].

Dennis, I will ask you to capture the log once again with an added modules like this:
negotiateauth:5,NTLM:5

it will hopefully help to spot the issue.

Thanks!

[1] https://searchfox.org/mozilla-central/rev/7f7c353e969e61a6a85201cc8ad3c3de12ac30d8/netwerk/protocol/http/nsHttpNTLMAuth.cpp#277-428


2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::ProcessAuthentication [this=000001E0E685EC40 channel=000001E0E61E26F0 code=401 SSLConnectFailed=0]
nsHttpChannel @1e0e61e2000 --> nsHttpChannelAuthProvider @1e0e685ec40
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::PrepareForAuthentication [this=000001E0E685EC40 channel=000001E0E61E26F0]
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp   proxy continuation state has been reset
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetAuthenticator [this=000001E0E685EC40 channel=000001E0E61E26F0]
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=000001E0E685EC40 channel=000001E0E61E26F0 proxyAuth=0 challenges=NTLM TlRMTVNTUAACAAAACAAIADgAAAAFgomi42fXUfxbUsMAAAAAAAAAAMgAyABAAAAABgGxHQAAAA9QAFIATwBEAAIACABQAFIATwBEAAEAGgBJAE4ATgBPAE0AQQBUAEUAUwBSAFYAMAAxAAQAIgBwAHIAbwBkAC4AaQBuAG4AbwBtAGEAdABlAC4AYwBvAG0AAwA+AEkATgBOAE8ATQBBAFQARQBTAFIAVgAwADEALgBwAHIAbwBkAC4AaQBuAG4AbwBtAGEAdABlAC4AYwBvAG0ABQAiAHAAcgBvAGQALgBpAG4AbgBvAG0AYQB0AGUALgBjAG8AbQAHAAgAXBDWtQVx1AEAAAAA]
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetIdentityFromURI [this=000001E0E685EC40 channel=000001E0E61E26F0]
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp nsHttpAuthCache::GetAuthEntryForDomain [key=https://sp.innomate.com:-1 realm=]
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: V/nsHttp nsHttpNTLMAuth::ChallengeReceived [ss=0000000000000000 cs=000001E0CDE06480]
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp   identity invalid = 0
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: D/nsHttp nsHttpChannel::ConnectionRestartable this=000001E0E61E2000, restartable=0
2018-10-31 10:37:24.756000 UTC - [Parent 12648: Main Thread]: V/nsHttp nsHttpNTLMAuth::GenerateCredentials
2018-10-31 10:37:24.760000 UTC - [Parent 12648: Main Thread]: D/nsHttp unable to authenticate
2018-10-31 10:37:24.760000 UTC - [Parent 12648: Main Thread]: D/nsHttp ProcessAuthentication failed [rv=80004005]

Comment 17

[Dennis Jakobsen]

Attachment: log-main.5280.txt.zip

fresh sharepoint auth attempt, with negotiateauth:5,NTLM:5

Comment 18

[Honza Bambas (:mayhemer)]

(In reply to Dennis Jakobsen from comment #17)
> Created attachment 9024652 [details]
> log-main.5280.txt.zip
> 
> fresh sharepoint auth attempt, with negotiateauth:5,NTLM:5

OK, I don't see any newly added lines from those two modules in the log.  Anyway, looking deeper into the code tells me there are number of possible code paths leading to the error (NS_ERROR_FAILURE).  Logs would probably narrow this down only marginally.

I will need either of those to move on:
- if this has worked on any older version of Firefox, please use mozregression to try to find the change that caused this bug, see [1]
- provide a publicly available use case (probably not an option)
- I will produce an instrumented build of Firefox with more logging added and ask you to run it in your environment

[1] https://mozilla.github.io/mozregression/

Comment 19

[Dennis Jakobsen]

(In reply to Honza Bambas (:mayhemer) from comment #18)
> (In reply to Dennis Jakobsen from comment #17)
> > Created attachment 9024652 [details]
> > log-main.5280.txt.zip
> > 
> > fresh sharepoint auth attempt, with negotiateauth:5,NTLM:5
> 
> OK, I don't see any newly added lines from those two modules in the log. 
> Anyway, looking deeper into the code tells me there are number of possible
> code paths leading to the error (NS_ERROR_FAILURE).  Logs would probably
> narrow this down only marginally.
> 
> I will need either of those to move on:
> - if this has worked on any older version of Firefox, please use
> mozregression to try to find the change that caused this bug, see [1]
> - provide a publicly available use case (probably not an option)
> - I will produce an instrumented build of Firefox with more logging added
> and ask you to run it in your environment
> 
> [1] https://mozilla.github.io/mozregression/

Me neither, i was seeing less detail and no mention of the hostname i was resolving/visiting.

Could probably file 10 bugs for that about:network interface alone..

Comment 20

[Dennis Jakobsen]

Attachment: log-main.11496.txt.zip

Comment 21

[Honza Bambas (:mayhemer)]

(In reply to Dennis Jakobsen from comment #19)
> Could probably file 10 bugs for that about:network interface alone..

:D

(In reply to Dennis Jakobsen from comment #20)
> Created attachment 9025868 [details]
> log-main.11496.txt.zip

Thanks!  This actually shows the origin of the problem: InitializeSecurityContext fails with SEC_E_TARGET_UNKNOWN, -2146893053 = 0x80090303.  I think the solution is here:

https://social.technet.microsoft.com/Forums/en-US/d8d9766c-fc4d-43ea-a8b4-762347f6844c/initialisesecuritycontext-failed-error-code-2146893053-secetargetunknown?forum=winserverDS

"""
i have finally found the missing bit. All i had to do was register an SPN for the user who is running proxyServer and then give him rights for delegation the client's credentials for RemoteServer.
"""

Please try to fix this on your side and if it works, let's close this bug as INVALID.  Thanks again for the logs.

Comment 22

[Honza Bambas (:mayhemer)]

For ref, the log from comment 20 shows:

2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::PrepareForAuthentication [this=0000020625DF0B50 channel=000002062A2BB6F0]
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetAuthenticator [this=0000020625DF0B50 channel=000002062A2BB6F0]
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=0000020625DF0B50 channel=000002062A2BB6F0 proxyAuth=0 challenges=NTLM <redacted>]
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetIdentityFromURI [this=0000020625DF0B50 channel=000002062A2BB6F0]
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/nsHttp nsHttpAuthCache::GetAuthEntryForDomain [key=https://sp.innomate.com:-1 realm=]
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: V/nsHttp nsHttpNTLMAuth::ChallengeReceived [ss=0000000000000000 cs=0000020625D10920]
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/nsHttp   identity invalid = 0
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/nsHttp nsHttpChannel::ConnectionRestartable this=000002062A2BB000, restartable=0
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: V/nsHttp nsHttpNTLMAuth::GenerateCredentials
2018-11-17 12:13:40.394000 UTC - [Parent 11496: Main Thread]: D/negotiateauth entering nsAuthSSPI::GetNextToken()
2018-11-17 12:13:40.398000 UTC - [Parent 11496: Main Thread]: D/negotiateauth InitializeSecurityContext failed [rc=-2146893053:] *)
2018-11-17 12:13:40.398000 UTC - [Parent 11496: Main Thread]: D/nsHttp unable to authenticate
2018-11-17 12:13:40.398000 UTC - [Parent 11496: Main Thread]: D/nsHttp ProcessAuthentication failed [rv=80004005]

*) https://searchfox.org/mozilla-central/rev/5117a4c4e29fcf80a627fecf899a62f117368abf/extensions/auth/nsAuthSSPI.cpp#498

Comment 23

[Honza Bambas (:mayhemer)]

Dennis, please see comment 21.

Comment 24

[Dennis Jakobsen]

(In reply to Honza Bambas (:mayhemer) from comment #21)
> (In reply to Dennis Jakobsen from comment #19)
> > Could probably file 10 bugs for that about:network interface alone..
> 
> :D
> 
> (In reply to Dennis Jakobsen from comment #20)
> > Created attachment 9025868 [details]
> > log-main.11496.txt.zip
> 
> Thanks!  This actually shows the origin of the problem:
> InitializeSecurityContext fails with SEC_E_TARGET_UNKNOWN, -2146893053 =
> 0x80090303.  I think the solution is here:
> 
> https://social.technet.microsoft.com/Forums/en-US/d8d9766c-fc4d-43ea-a8b4-
> 762347f6844c/initialisesecuritycontext-failed-error-code-2146893053-
> secetargetunknown?forum=winserverDS
> 
> """
> i have finally found the missing bit. All i had to do was register an SPN
> for the user who is running proxyServer and then give him rights for
> delegation the client's credentials for RemoteServer.
> """
> 
> Please try to fix this on your side and if it works, let's close this bug as
> INVALID.  Thanks again for the logs.

Wait, what?

Comment 25

[Honza Bambas (:mayhemer)]

What exactly do you need to explain?

Comment 26

[Honza Bambas (:mayhemer)]

Sorry, maybe the piece that was not clear was that the issue was in the environment (your intranet) and not exactly in Firefox.

Now I recall there is no proxy involved in your case, which the forum post I refer deals with.  I may need to look more in depth for the cause of SEC_E_TARGET_UNKNOWN returned from InitializeSecurityContext then.  Feel free to google as well on that topic or refer this issue (comment 21 of this bug) to your IT department.

Comment 27

[Dennis Jakobsen]

(In reply to Honza Bambas (:mayhemer) from comment #26)
> Sorry, maybe the piece that was not clear was that the issue was in the
> environment (your intranet) and not exactly in Firefox.
> 
> Now I recall there is no proxy involved in your case, which the forum post I
> refer deals with.  I may need to look more in depth for the cause of
> SEC_E_TARGET_UNKNOWN returned from InitializeSecurityContext then.  Feel
> free to google as well on that topic or refer this issue (comment 21 of this
> bug) to your IT department.

I dont have an IT department. I'm just here with my trusty desktop pc connected directly to my fiber provider's modem. No proxy settings in Firefox or any other browser.

I was a bit hazy on how we could make Firefox work by sorting out a  .NET remoting coding problem locally?

Comment 28

[Honza Bambas (:mayhemer)]

I'm not sure I can help more soon.  I'm not a deep expert to Kerbereos/NTLM and SSPI and how to handle SPN in this case.

Few related articles I have found:
https://groups.google.com/d/msg/jabber-net/oB4bpArmkZI/VI_FjayR3wYJ
https://github.com/requests/requests-kerberos/issues/96
https://stackoverflow.com/questions/6623711/using-sample-code-in-rfc-4777-initializesecuritycontext-returns-error

Comment 29

[Honza Bambas (:mayhemer)]

Andrew, in case it's easy for you, can you quickly overlook this and maybe have a clue or tip?  

I think this has something to do with SPN.  The error is: InitializeSecurityContext fails with SEC_E_TARGET_UNKNOWN, -2146893053 = 0x80090303 while processing Type 2 message:

WWW-Authenticate: NTLM TlRMTVNTUAACAAAACAAIADgAAAAFgomi2VKeFIvY5Z4AAAAAAAAAAMgAyABAAAAABgGxHQAAAA9QAFIATwBEAAIACABQAFIATwBEAAEAGgBJAE4ATgBPAE0AQQBUAEUAUwBSAFYAMAAxAAQAIgBwAHIAbwBkAC4AaQBuAG4AbwBtAGEAdABlAC4AYwBvAG0AAwA+AEkATgBOAE8ATQBBAFQARQBTAFIAVgAwADEALgBwAHIAbwBkAC4AaQBuAG4AbwBtAGEAdABlAC4AYwBvAG0ABQAiAHAAcgBvAGQALgBpAG4AbgBvAG0AYQB0AGUALgBjAG8AbQAHAAgARU45+m5+1AEAAAAA

from https://sp.innomate.com/default.aspx



Dennis, I'm not sure why you change the pref network.automatic-ntlm-auth.allow-non-fqdn to true to allow authentication to this particular domain.  The sp.innomate.com is a fqdn.  Maybe add the domain to the list of network.automatic-ntlm-auth.trusted-uris if you really trust that domain to know the credentials you log in to your Windows local account?  This is actually a pretty dangerous thing to do, do you actually know what you are doing?

Also your report says you get a credentials prompt instead of automatically logging you in with your local credentials.  But in any of the logs I don't see anything like that happening.

Comment 30

[Dennis Jakobsen]

(In reply to Honza Bambas (:mayhemer) from comment #29)
> Dennis, I'm not sure why you change the pref
> network.automatic-ntlm-auth.allow-non-fqdn to true to allow authentication
> to this particular domain.  The sp.innomate.com is a fqdn.  Maybe add the
> domain to the list of network.automatic-ntlm-auth.trusted-uris if you really
> trust that domain to know the credentials you log in to your Windows local
> account?  This is actually a pretty dangerous thing to do, do you actually
> know what you are doing?
> 
> Also your report says you get a credentials prompt instead of automatically
> logging you in with your local credentials.  But in any of the logs I don't
> see anything like that happening.

Yes, i know what i'm doing. I'm employed at Innomate and i'm the system administrator there. It's not a big deal, i just noticed that setting was broken, so i reported it.

I *have* that hostname in trusted uri's, it still prompts. Allowing non-fqdn's used to make the prompt disappear and just fail. That is the whole issue. Maybe i explained it poorly? In latest nightly it always prompts now.

I'll file a seperate bug for network.automatic-ntlm-auth.trusted-uris, because that is broken too.

I apologize i was distracted and gave you an fqdn example when this particular bug was about non-fqdn auto signin.

I'll trace another example from the lan.

Comment 31

[Dennis Jakobsen]

Attachment: log-main.4996.txt.zip

Visiting http://linaro:9091 (Transmission Web with auth), having both non-fqdn enabled and http://linaro in trusted uri's .. still prompts.

Comment 32

[Andrew Bartlett]

This looks like interactions of the windows 'trusted sites' rather than a firefox restriction. InitializeSecurityContext is the Windows API that Firefox uses to get single sign on NTLM (in particular).

Comment 33

[Honza Bambas (:mayhemer)]

Thanks Andrew.  This less and less looks like a Firefox issue to me.

Closing as invalid.