42.86 KB, text/plain
14.12 KB, text/plain
1.01 KB, patch
|Details | Diff | Splinter Review|
12.79 KB, text/plain
26.82 KB, text/plain
15.72 KB, application/zip
385 bytes, text/plain
15.79 KB, application/zip
5.07 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624 I type in the address of a server on the intranet that is running Windows NT4, accessing a Virtual Directory that has Anonymous Authentication turned off, leaving only Integrated Windows Authentication. According to the release notes, Mozilla 1.4 supports NTLM Authentication. However, when I attempt to access the page, it returns the 401.2 error, "Unauthorized: Logon Failed due to server configuration" However, using Live HTTP Headers, I see that the WWW-Authenticate header field does have NTLM... Also, I can access the same URL using IE and it authenticates. Reproducible: Always Steps to Reproduce: 1. Type in a URL that goes to a folder or page that requires NTLM authentication. 2. Do this from a workstation that has an authorized person logged in. Actual Results: A page loads with the following text: HTTP Error 401 401.2 Unauthorized: Logon Failed due to server configuration This error indicates that the credentials passed to the server do not match the credentials required to log on to the server. This is usually caused by not sending the proper WWW-Authenticate header field. Please contact the Web server's administrator to verify that you have permission to access to requested resource. Expected Results: Performed the appropriate authentication and displayed the web page. Here's what Live HTTP Headers reports (names have been changed): ---------------------------------------------------------- http://intranet.example.com/VirtualDirectory/ GET http://intranet.example.com/VirtualDirectory/ HTTP/1.1 Host: intranet.example.com User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: http://intranet.example.com/ Cookie: ASPSESSIONIDQQGQGHWL=EPBPOKPBLBPCNHNPBFDHAICK HTTP/1.x 401 Unauthorized WWW-Authenticate: NTLM Content-Length: 644 Content-Type: text/html X-Cache: MISS from cache.example.com ----------------------------------------------------------
reporter: can you please generate a HTTP log using the directions from here: http://www.mozilla.org/projects/netlib/http/http-debugging.html thx!
also make sure to send user/password as: user: DOMAIN\user password: password
Created attachment 127510 [details] http log as requested of attempt to attach to specified site using NTLM
Confirmed with 1.4 Final I don't know if it is because of an https:// connection (which this attempt was), or IIS6, or something else. I have created an attachment of an HTTP log of my attempt to connect. Actions: Enter Site address in browser address bar Results: Not authorized screen -- no login box pops up.
>0[781e70]: nsHttpChannel::GetAuthenticator [this=2625620 scheme=ntlm] >0[781e70]: authentication type not supported >0[781e70]: ProcessAuthentication failed [rv=80004005] that's the significant snipet from the log file. for some reason the NTLM authentication module cannot be found. reporter: do you have FIPS mode enabled? if you do not have it enabled (or if you don't know what it is) can you instead then try re-installing mozilla after completely uninstalling your existing copy? also, try a new user profile. thx!
Created attachment 127542 [details] HTTP log of failed NTLM Authentication Here's the result of following the instructions indicated above. I am not using SSL in my environment. HTH, Mike
Well, I don't know what FIPS mode is, so I uninstalled and reinstalled Mozilla, creating a new profile on startup. I received the same error. It never shows a prompt for username/password. Note: that last log was made with the previous installation of Mozilla. I'll try to create another with this one... Thanks.
Created attachment 127580 [details] Yet another HTTP log of NTLM authentication This log was created after uninstalling and reinstalling Mozilla 1.4 on Win95. Also created a new profile and set the default home page to about:blank. HTH, Mike
Attachment #127542 - Attachment is obsolete: true
*** Bug 213086 has been marked as a duplicate of this bug. ***
Severity: normal → major
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: HTTP Error 401.2 on NTLM Authentication to intranet site → NTLM authenticator cannot be loaded under Win9x (sometimes?)
Target Milestone: --- → mozilla1.5beta
Summary: NTLM authenticator cannot be loaded under Win9x (sometimes?) → NTLM authenticator cannot be loaded under Win9x (security.dll not found)
from a Win98 box: C:\WINDOWS\SYSTEM>dumpbin /exports secur32.dll Microsoft (R) COFF Binary File Dumper Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. Dump of file secur32.dll File Type: DLL Section contains the following exports for Secur32.dll 0 characteristics 353B8DAA time date stamp Mon Apr 20 11:02:18 1998 0.00 version 1 ordinal base 18 number of functions 18 number of names ordinal hint RVA name 1 0 000017AE AcceptSecurityContext 2 1 000016BD AcquireCredentialsHandleA 3 2 00001842 ApplyControlToken 4 3 0000181D DeleteSecurityContext 5 4 0000186B EnumerateSecurityPackagesA 6 5 00001A61 FreeContextBuffer 7 6 0000171D FreeCredentialsHandle 8 7 00001A8E ImpersonateSecurityContext 9 8 000016A9 InitSecurityInterfaceA 10 9 00001737 InitializeSecurityContextA 11 A 00001AE2 MakeSignature 12 B 00001A9E QueryContextAttributesA 13 C 00001AC0 QueryCredentialsAttributesA 14 D 00001A33 QuerySecurityPackageInfoA 15 E 00001A96 RevertSecurityContext 16 F 00001B2E SealMessage 17 10 00001B54 UnsealMessage 18 11 00001B08 VerifySignature Summary 1000 .data 1000 .idata 1000 .reloc 1000 .rsrc 5000 .text so, this means we need to load secur32.dll under Win9x and lookup the A-suffixed function names instead. patch should be trivial.
Created attachment 128073 [details] [diff] [review] v1 patch - this works
Attachment #128070 - Attachment is obsolete: true
why are we using the "security.dll"? Can't we just load "secur32.dll" on all window versions? Looking at msdn, it looks like most of the authentication functionality reference the secur32 lib.
dougt: good call... i think i took "security.dll" from some sample code :(
Created attachment 128109 [details] [diff] [review] v2 patch just load secur32.dll on all platforms.
Attachment #128073 - Attachment is obsolete: true
Comment on attachment 128109 [details] [diff] [review] v2 patch r=dougt
Attachment #128109 - Flags: review?(dougt) → review+
Comment on attachment 128109 [details] [diff] [review] v2 patch sr=alecf
Attachment #128109 - Flags: superreview?(alecf) → superreview+
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(security.dll is just a forwarder for secur32.dll - there's no difference between them.)
I downloaded and installed build 2003072204 to check to see if the bug was fixed. I was prompted for a user name and password for our proxy server. After entering it, Mozilla crashed with an invalid page fault error. Here are the details: MOZILLA caused an invalid page fault in module SECUR32.DLL at 0167:7f8737da. Registers: EAX=40b50600 CS=0167 EIP=7f8737da EFLGS=00010202 EBX=00000000 SS=016f ESP=0065f6a8 EBP=0065f72c ECX=00000000 DS=016f ESI=00090312 FS=4cff EDX=01c35035 ES=016f EDI=019fed10 GS=4cee Bytes at CS:EIP: 89 01 8b 45 fc 89 51 04 c7 40 20 01 00 00 00 83 Stack dump: 019f82e0 019f82d8 00000000 00080007 00439018 00000000 00000000 019fed27 00000037 00000008 0065f704 00439710 00430000 00019410 bff7b31d 00430000 I reset my user profile and entered the proxy information again. The problem consistently repeats itself. Based on this, I don't believe this bug has been completely resolved yet (but it's getting close :-) ).
Steve: what version of Windows are you testing?
Severity: major → critical
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Steve: nevermind, you're log file shows that you are on Win98.
based on the log file, it seems that InitializeSecurityContext is the entry point that is crashing. i have access to a Win98 box, but it is going to take me some time to get a testcase ready.
Steve: Something seems really wrong with your windows installation. Other folks have told me that they are not having any trouble with NTLM authentication under Win98. Does NTLM authentication work properly when you use Internet Explorer?
Darin: Absolutely! I have never had problems with accessing the Internet via IE (using both versions 5.5 and 6.0). I'm also not prompted to enter my NT userid and password when trying to access the proxy server which Mozilla expects me to do (Come to think of it, the users who run Mozilla on their NT4 workstations are not prompted for a userid and password when they start up Mozilla as well). Is there a setting that maybe affecting this? Steve
I stand corrected... The NT users needed to enter their userid and password the first time they ran Mozilla in order to access the Proxy Server. Sorry for the confusion. Steve
>Is there a setting that maybe affecting this? no setting. we decided that it is probably not wise to blindly hand out the user's windows logon to any machine that requests it. sure, we're only sending a hash of the user's password, but it is not a very strong hash (MD4). so, i'm really baffled about why your system is having trouble.
I understand. Some more specifics about my environment: O.S.: Windows 98SE Build 4.10.2222 A Directory Entry for secur32.dll: SECUR32 DLL 40,960 04-23-99 10:22p SECUR32.DLL Could the problem be due to me running 98SE instead of 98? Steve
The fact that you are running Win98SE really shouldn't be an issue. It must be the case that Mozilla is passing bad data to Windows, but the log file doesn't indicate any problems, and since the code is working for other people, I'm really not sure what the problem could be. I might try to add some more LOG statements to the code. Maybe that's the way to proceed....
*** Bug 215947 has been marked as a duplicate of this bug. ***
Created attachment 129732 [details] http logfile because talkback won't submit anything I'm coming in from another bug, which duplicates this one (sorry, I did look for security bugs, but my page fault comes from module SECUR32.DLL). I have an HTTP log attachment for this, demonstrating something useful, I suppose. Be advised Mozilla crashes on this, but I can compose HTML pages and even opne up the application, so long as I don't try to browse anything remotely. I've rolled back to 1.4 for now. And I'm not screaming for anyone's head, just take your time and do it right is all anyone should ask. I'm with Mozilla all the way.
thanks Christopher... since many folks with Win98 boxes are unable to reproduce this crash, I may need to enlist your help to test out some things for me, including running a diagnostic program, etc. are you game?
absolutely. it's the least i could do for the team.
I just crashed trying to access the Outlook web interface. IE can access it just fine. Win 98 (4.10.1998) using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030817 Mozilla Firebird/0.6.1+. SECUR32.DLL (version 4.10.2222) 40,960 bytes Friday, April 23, 1999 10:22:00 PM Talkback ID: TB22914777H I am willing to run diagnostic software also.
Created attachment 130147 [details] ntlmdump: diagnostic program ok, here's a little diagnostic program. i'm not sure that it will tell us very much, but maybe it is a good place to start. this attachment is a .zip file containing the executable for the program along with its source. all you need to do is run the executable, save the output into a text file, and upload that output to this bug report (or feel free to email it directly to me). thanks!
Created attachment 130174 [details] ntlmdump.exe Output From My System Let me know if you need anything else. Steve Illgen
The output from ntlmdump.exe on my system matches that of Steve. David
My output, as inline text for those playing at home. D:\ntlmdump>ntlmdump InitSecurityInterfaceA: dwVersion = 0x1 AcquireCredentialsHandle = 7F8716BD FreeCredentialHandle = 7F87171D InitializeSecurityContext = 7F871737 AcceptSecurityContext = 7F8717AE DeleteSecurityContext = 7F87181D QuerySecurityPackageInfo: fCapabilities = 0x77 wVersion = 0x1 wRPCID = 0xa cbMaxToken = 768 Name = NTLM Comment = NTLM Security Package
thanks guys! i'll let you know if it tells me anything...
Status, please? It's a critical sev-1, just wondering if there's been any news.
sorry, no update. this bug is still very perplexing to me. my plan is to write yet another test program for you guys to try and run. i hope to have something next week.
*** Bug 218729 has been marked as a duplicate of this bug. ***
ok, the output of ntlmdump.exe looks perfectly fine. what i'd like from folks is to know what version of SECUR32.DLL you have installed on your WIN98 boxes that crash. i have read some reports about various bad versions of that DLL being installed overtop the good versions. to check the version, you should be able to right click on the DLL from within explorer, and select the "properties" option. from there a popup window should appear with a tab labeled "version". these instructions work on Win2k at any rate, and I unfortunately don't have access to a Win98 box.
Created attachment 131139 [details] dumpver: outputs the version of Secur32.dll installed on the system here's a little program that outputs the version of the secure32.dll that is installed on your system. it'd be great to collect the output of this command on as many different machines as possible, including those machines that crash and those that do not. thanks!!
C:\Stuff\Unzip\dumpver>dumpver 184.108.40.2062 C:\Stuff\Unzip\dumpver> HTH! David
dumpver.exe results: 220.127.116.11 (Win98 and Win98SE default) 18.104.22.168 worked (ran the "Q266772" patch to get it, more info in link below) 22.214.171.124 failed as well http://support.microsoft.com:80/support/kb/articles/q266/7/72.asp&NoWebContent=1
jaciss: awesome! thank you! i think the solution is probably then to not use unicode strings on Win9x. that should be totally do-able since SSPI provides both narrow and wide versions of the API.
Status: REOPENED → ASSIGNED
Summary: NTLM authenticator cannot be loaded under Win9x (security.dll not found) → NTLM sometimes causes crashes under Win9x
Target Milestone: mozilla1.5beta → mozilla1.5final
Comment on attachment 131189 [details] [diff] [review] v3 patch note: in my local tree, i changed |result = PR_FALSE| to |result = 0| so the types match.
Wouldn't block the release but we've got a few days left to get this in so please request approval once the reviews are completed. Thanks.
Flags: blocking1.5? → blocking1.5-
Comment on attachment 131189 [details] [diff] [review] v3 patch the IsWin9x() check differs from what msdev suggests. For example this check, from what i am reading, will also be true for NT. Take a look here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/g etting_the_system_version.asp
dougt: are you sure? it looks correct to me. am i missing something?
Attachment #131189 - Flags: superreview?(bryner) → superreview+
Comment on attachment 131189 [details] [diff] [review] v3 patch missed the switch.
Attachment #131189 - Flags: review?(dougt) → review+
Comment on attachment 131189 [details] [diff] [review] v3 patch please consider this patch for 1.5 final and 1.4.2
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → FIXED
Comment on attachment 131189 [details] [diff] [review] v3 patch a=asa (on behalf of drivers) for checkin to the Mozilla 1.5 branch. Please add the fixed1.5 keyword when this is landed on the branch. Thanks.
Attachment #131189 - Flags: approval1.5? → approval1.5+
sorry, i forgot to mention that this was checked in on the 1.5 branch.
Comment on attachment 131189 [details] [diff] [review] v3 patch a=mkaply for 1.4.2
Attachment #131189 - Flags: approval1.4.2? → approval1.4.2+
You need to log in before you can comment on or make changes to this bug.