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.
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.
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6beta
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.
Attachment #136222 - Attachment is obsolete: true
Myk has removed the content of attachment 136222 [details]. removing the security flag.
Created attachment 136257 [details] [diff] [review] 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 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.
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 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.
Attachment #136257 - Flags: approval1.6b?
Attachment #136257 - Flags: approval1.6b? → approval1.6b+
fixed on trunk for 1.6 beta :)
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.