226639 - [NTLM] Can't access host in NTLM mode

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Olivier Cahagne]

build ID: FB 20031123 Win2k

Just tried accessing a host using HTTP NTLM authentication after final checkins
for new NTLM code landed a week ago (bug 224653).

Accessing the host doesn't work anymore when replying to the first NTLM auth box
(screenshot is the same as attachment 118760 [details]). It works (see log) when pressing
Escape and getting the second auth. popup (with the realm as it's Basic auth)
and then entering domain\username + password.

I tested FB 20031116-08 on same machine and it passes the first auth. dialog
successfully with the same domain\username + password.

Server is a NetApp 6.2.2.

Comment 1

[Olivier Cahagne]

Attachment: FB 20031123 HTTP log (nsHttp:5)

Comment 2

[Olivier Cahagne]

Attachment: FB 20031116 HTTP log (nsHttp:5)

Comment 3

[Olivier Cahagne]

setting Blocking 1.6b flag, eventhough 1.6b freezes tomorrow, I think this is an
important regression that may affect many people because it's not been tested by
enough nightly users since 1 week.

Comment 4

[Malcolm Rowe]

Both logs show that we receive a 401 from the server, then send an NTLM 
initiation. In 20031123 (attachment 136222 [details]), we then get an NTLM challenge, 
whereas in 20031116 (attachment 136221 [details]), we get a repeated 401 Unauthorised, 
with no challenge.

One difference is that the working one is using a FQDN to access the host, 
while the broken one is using just the hostname, though I guess this probably 
shouldn't matter.

Comment 5

[Darin Fisher]

investigating...

Comment 6

[Darin Fisher]

ok, this is very interesting.  it seems that the server is rejecting our first
NTLM message.  that is purely an informational message, where some flags are
sent to the server to tell it what the client is capable of.  clearly, the
server is unhappy with what is being sent.  unfortunately, the log file for the
later build does not include the credentials sent by mozilla.  (they've been
excluded to protect folks passwords.)

olivier: two things, 1) the contents of attachment 136222 [details] could be used to
determine your password, and 2) can you capture a ethereal trace of the newer
browser so that i might see what it is sending to the server, but please do not
post that log file here.  instead, please send it to me over a private email.

if you want me to have attachment 136222 [details] removed, please let me know and i will
do so.  if you do not care, then let me know also, and i'll remove the
security-sensitive flag.

Comment 7

[Dave Miller [:justdave]]

Myk has removed the content of attachment 136222 [details].  removing the security flag.

Comment 8

[Darin Fisher]

Attachment: v1 patch

ok, according to wolruf this patch does the trick.  the solution is to add the
NegotiateAlwaysSign flag to our Type1 request.	i did not expect this flag to
be required, and i suspect that NetApp is being overly picky here.  although,
Eric Glass (author of the NTLM Authentication Protocol documentation available
at http://davenport.sourceforge.net/ntlm.html, on which our implementation is
based) had this to say:

  NegotiateAlwaysSign -- This indicates that even if signing has not been
  established, dummy signatures should be supported.  This is kind of obscure,
  but basically if this isn't negotiated calls to MakeSignature will fail if
  signing isn't negotiated.  If this is established, it will succeed with
  a "dummy" signature being applied to the message (consisting of all zeros).
  This is usually present in all cases; I've only been able to disable it
  artificially by tweaking the messages.

so, hopefully it doesn't hurt to add this flag ;-)

i've also added some extra DEBUG-only logging to nsNTLMAuthModule.cpp.

Comment 9

[Darin Fisher]

Comment on attachment 136257 [details] [diff] [review]
v1 patch

since this is such a simple patch (only adding in a new flag), i'm just going
to ask bryner for r+sr.  he was one of the original reviewers for this code.

Comment 10

[Olivier Cahagne]

thanks for this patch, this enables us not to lose NTLM-capability on the NetApp
filers (NetApp is one of the major SAN companies: http://www.netapp.com/ ) which
we got used to with Mozilla 1.4/1.5 on Win32 (with SSPI). This should enable
Unix/Mac users to also access such filers.

Comment 11

[Darin Fisher]

Comment on attachment 136257 [details] [diff] [review]
v1 patch

NetApp is widely deployed.  we shouldn't ship 1.6 beta without this patch. 
this bug is a significant regression.

Comment 12

[Darin Fisher]

fixed on trunk for 1.6 beta :)