Closed Bug 23679 Opened 25 years ago Closed 21 years ago

NTLM auth for HTTP

Categories

(Core :: Networking: HTTP, enhancement, P5)

Product:
Core
Component:
Networking: HTTP
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: Francis, Assigned: darin.moz)

References

Details

(Keywords: helpwanted, topembed-, Whiteboard: DO NOT SPAM read comment #162 before posting)

Attachments

(5 files)

An nearly complete implementation of NTLM auth
20.00 KB, text/plain
Details
NTLM Authentication Scheme for HTTP
22.45 KB, text/html
Details
working NTLM support with clean-roomed MD4 and public domain DES
27.46 KB, application/octet-stream
Details
NTLM proxy utility.
579 bytes, text/plain
Details
The NTLM Authentication Protocol
88.16 KB, text/html
Details
Under NT 4.0 (Build 1381: Service Pack 5) the Mozilla browser release M12 is unable to connect to sites that use M$'s proprietary NTLM authentification. A pop up username/password dialogue appears but no combination of username/password, NT_DOMAIN/username/password seems to work. FYI Internet Explorer on UNIX brings up a dialgue with the three components seperated to avoid confusion. I also tried the same site with the same Mozilla release but under FreeBSD 3.3. Mozilla wasn't able to access the site (it just flickered) and didn't pop up an authentification dialogue. No error message appeared.
Assignee: dougt → gagan
Severity: blocker → enhancement
Component: Security → Networking
Summary: NTLM authentification doesn't work. → [enh] NTLM authentication doesn't work.
Even though this bug relates to cryptography stuff, i think it is more related to networking code in \netwerk\protocol\http\src Currently there is only 'Basic' authentication implemented (in nsBasicAuth) I changed severity to 'enhancement' as prior versions of Navigator didn't have this feature (though i think there was a plugin that did it) M$ have a sample named 'HTTPauth' that contains source code illustrating how to implement the NTLM authentication. Here are the two files for that sample: http://msdn.microsoft.com/library/devprods/vs6/visualc/vcsample/sdk_WinBase_Secu rity_WinNT_httpauth.exe http://msdn.microsoft.com/library/devprods/vs6/visualc/vcsample/sdk_WinBase_Secu rity_WinNT_include.exe I've started having a look at the sample code, and am trying to understand how the authentication works currently to see how much cut'n'paste might be done ti add this in. But someone who is faster/better/smarter might want to beat me to it:-) -dave
I have discovered an NTLM authentification plugin for Apache. Source code is newer and easier to understand than the M$ examples... http://www.ozemail.com.au/~timcostello/mod_ntlm/mod_ntlm-0.4.zip A write up can be found under http://www.ozemail.com.au/~timcostello/mod_ntlm.
Target Milestone: M15
Depends on: 14610
NTLM requires a Keep-Alive connection
Depends on: 10738
No longer depends on: 14610
Summary: [enh] NTLM authentication doesn't work. → NTLM authentication doesn't work.
*** Bug 29810 has been marked as a duplicate of this bug. ***
->help
Assignee: gagan → nobody
Keywords: helpwanted
This certainly sounds like cool stuff... but since it is not assigned to anyone, it can't be an M15 stopper. I'm changing its target to --- until someone steps up to the plate with a delivery plan.
Target Milestone: M15 → ---
*** Bug 35159 has been marked as a duplicate of this bug. ***
Netscape 4.x has the same problem, but Internet Explorer 4+ works fine. Theres a MS Knowledge base page on it which gives the only work around for Netscape 4 here: http://support.microsoft.com/support/kb/articles/Q218/4/84.asp Microsofts own Knowledge base article id is Q218484.
The fetchmail source code may be a fruitful resource for figuring this NTLM problem out. It supports using NTLM to authenticate for IMAP. ntlm.h provides the definitions, and is included in imap.c, smbencrypt.c, and smbutil.c -- in the <a href="http://www.tuxedo.org/~esr/fetchmail/fetchmail-5.4.3.tar.gz">fetchmail source</a>, of course.
The NTLM auth is pretty simple (and, of course, violates multiple RFCs), but should not be difficult to add. The only things I'm not sure about are getting DES and MD4 encryption. For the Digest auth patch, I added MD5 into netwerk. I don't want to keep adding crypto functions to netwerk, but I'm not sure where else to get them. The NSS service?
The above patch is a tar file with two files (nsNTLMAuth.[cpp|h]). It implements the guts of NTLM protocol, but until we have DES and MD4 support in mozilla, it's not going to run. Basically, only the crypto parts need to be changed. However, there are a number of unknown fields (to me, at least), which some of the other implementations may show how to properly use. Also, my storage of domain, username, and password between auth "sessions" leaves a bit to be desired (they're global statics). I couldn't think of a substantially better solution, but if others have ideas, I'll improve that. And one more thing, I don't actually have a server using NTLM authentication, so once the crypto code is in place, to test it I'll need access to one. Perhaps one of the people watching this bug could provide me some simple test access account?
*** Bug 48469 has been marked as a duplicate of this bug. ***
I can supply a server testsite for NTLM testing. How close is this to completation (don't know what DES and MD4 is). Also how will the authentication work, will be possible to get automatic login the same way IE does when logged to a Windows system?
Microsoft IIS gives the choice to enable NTLM auth, Basic auth, or Both. Currently mozilla gives up immediately if both are enabled (Instead of using Basic Auth) This is a problem against both NT4 and Win2000 servers. IIS 5: HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.0 Date: Mon, 21 Aug 2000 13:49:19 GMT WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="xxxxx" IIS 4: HTTP/1.1 401 Access Denied WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="xxxxx" Mozilla will not view either of these pages as long as NTLM is an option.
Joel Roller: The problem with multiple Auth lines you describe is Bug 44041, for which I've posted a patch. As for NTLM, I need DES and MD4, which, as far as I can tell, are not available in mozilla currently. They might be hidden somewhere in NSS, but I can't find them. My plan is to write a (simple) crypto module to run in-process, which would provide DES, MD4, MD5, and possibly others. Once that is written, NTLM would be functional. Due to the broken nature of NTLM, however, it might not work as smoothly as some would desire (ie. not automatic, and it will likely prompt you for the domain/username/password a lot [once per HTTP connection]). Both of those could be fixed, however. I'll try to finish this as soon as possible, but since I'll never use this feature, it's not a top priority of mine.
*** Bug 52770 has been marked as a duplicate of this bug. ***
DES is enabled in the latest PSM. Is there ANY chance this will get into NS6?
Adding a whole bunch of keywords to move this alone, especially since there's a patch here.
Keywords: approval, mozilla0.9, patch, review
This needs to be reviewed by someone, so I'm going to try to add gagan to cc and ask if he can assign this to someone. This patch will languish in unholy darkness forever if someone doesn't pick it up.
Gagan: I added you to cc: to see if you could move this patch to some reviewers. (and since this has been assigned to component "Networking".)
Reassinging to gagan.
Assignee: nobody → gagan
QA Contact: junruh → tever
cc to self
Take a look at ftp://ftp.visi.com/users/grante/stuff/libntlm-0.21.tar.gz which would make fixing this much easier. There are patches for both mutt and pine which use libntlm. However, because of licensing issues, I think this would only help if the user compiled libntlm into mozilla himself, since it couldn't be included in the official distribution.
Target Milestone: --- → mozilla1.0
*** Bug 60784 has been marked as a duplicate of this bug. ***
The attachment seems to be going in the direction of a full NTLM implementation. Would it make sense to solve this in a windows-only way? Windows provides a library called SSPI that generates the packets required for NTLM authentication (and microsoft's kerebos implementation) with jusy a few lines of code. I had a brief look at the examples that david gardiner pointed to, and it sends uuencoded SSPI packets across to make the authentication happen. The advantage of using SSPI would be that mozilla could authenticate using the logged in user account by default (i.e. not ask for user/password/domain), great for intranet apps. If have some code lying around for another project that does something similar. If someone would be so kind to provide me with a couple of pointers to where this (windows only) stuff would go, it's probably something that could be done on a rainy evening.
Although cross-platform is probably the ideal solution, i would agree that the 'low hanging fruit' in this instance is the Windows-only solution. If we can knock off the SSPI stuff, then someone with more enthusiasm can look at the public implementations of NTLM at a later date. -dave
While I agree that a Windows-only implementation is probably "low-hanging fruit," in my opinion there is infintely more value in a cross-platform solution. Consider this: there is current NO browser on UNIX that supports NTLM authentication. An example of the potential value (at least for me): my company is very Microsoft-focused; many of the internal web servers run on IIS. The corporate security policy is to use only NTLM authentication, therefore I can't access things like our intranet, phonebook, etc. without running IE inside vmware on my Linux box. It would be amazing if Mozilla would be the first UNIX browser to support NTLM.
NTLM on intranet servers is a wedge that it used to drive other operating systems off of the enterprise desktop. I will name my first loinfruit after the programmer that delivers a cross-platform solution, even if that means I end up with a daughter named Festus.
The patch I posted last summer does most of what is required. The thing that prevented me from completing it at the time was simply that I did not know how to access DES and MD4 routines. Once you put the right code in for that, it should work. Of course, it might be a bit annoying to use, since the authentication only lasts for the specific connection (ie. a keep-alive'd connection to the server), and the authentication token will change with each new connection (it has to do a little negiotiation first [which contains a new salt] for each new connection) and mozilla's auth token cache assumes the same token will work over and over. So you would get lots of username, domain, password prompts. That could be easily fixed by making the auth cache more flexible (note: the original author's of the auth cache stuff are not to blame for this lack of functionality. it's only required because Microsoft horribly abused the auth mechanism)
*** Bug 73332 has been marked as a duplicate of this bug. ***
Depends on: 73439
Depends on: 74246
mass move, v2. qa to me.
QA Contact: tever → benc
Component: Networking → Networking: HTTP
Keywords: qawanted
Summary: NTLM authentication doesn't work. → NTLM auth for HTTP
Blocks: 35159
OS: Windows NT → All
I'd also like to see this implemented, because Mozilla has now IMO duplicated all of Netscape 4.x's functionality, and is moving on to implement IE functionality, such as the -turbo option. While you could argue about the propriety of adding the -turbo option or NTLM support (i.e. letting Microsoft set the rules instead of W3C), NTLM support is really the last reason I would choose IE as an enduser (nobody uses ActiveX or any other IE-only features). Also, and this is NOT intended to provoke anything...should someone logging in via NTLM get a "low grade encryption" warning like with low-grade SSL? I know _nothing_ about cryptography, but if there hasn't been any independent peer review of NTLM security (and I don't know that), should it by default be considered a risk and the user warned?
adding nsenterprise keyword. The reason is that many large companies (at least that I've worked with) use NT-security and then NTLM authorization to make passwords not sent in cleartext. I have in fact worked with quite a few intranet sites that had to drop support for netscape (and mozilla) since NTLM wasn't supported.
Keywords: nsenterprise
This bug is why we won't be able to even have Mozilla or Netscape 6 as an option for our users. Our Intranet needs are forceing us to use IE 5+ only. I assume there are not any outside people that could help us get movement on this?
Nominating for 0.9.4 and 1.0.
Keywords: mozilla0.9.4, mozilla1.0
RELNOTE: NTLM authentication is not supported in this release.
Keywords: relnote
The Patch we have is quite old. Has it bit-rotted? It would be nice to have this feature in (if it doesn't hurt stability for 1.0, else 1.1) I know quite a few companies which use NTLM simply because they want to limit the number of users and want the easiest solution. (Which on an NT machine is NTLM) If this patch is "complete" except for the encryption modules, we should seriously look at how to integrate it into the trunk. I'll ping a few people on IRC. Question about the patch: Justin, when you say "silmultaneous logins" you are referring the different servers correct? It would be upsetting if we couldn't open another page on the server at the same time
the main problem isn't the NTLM stuff itself, it's bug 74246. As far as I've understood
*** Bug 94092 has been marked as a duplicate of this bug. ***
I am working on this in my spare time (while at the same time trying to get group authorization to work under squid with ntlm) but a lot of what i am having to do is just figure out how the protocol works. IF anyone could help me with packet traces of an NTLM authorization session...and better yet if anyone has NTLMv2 running a packet trace of that would be great.. I am having a hard time figuring out if/and how NTLM & NTLM2 authentiate differently....any help would be appreciated (I have been through every documentation/code base i can find so dont bother pointing me to that I have already been there :)
Removing nsenterprise nomination.
Keywords: nsenterprise
Just to clarify, this is what makes a browser able to authenticate to web servers running on Windows based IIS systems...
Of corse I don't know what the requirements for an nsenterprice bug is, but I know that for many large corporations this bug is a showstopper. The reason that many choose to do auth through NTLM is that passwords don't pass in cleartext and you get (in IE) an automatic login that is compleatly transparent for the endusers. I know that there are other solutions that makes it possible to send passwords in non-cleartext (https for example) however that is often more work involved making companies rather drop support for ns/moz. For most users, me included, this isn't really a big deal since next to no sites on the Internet use NTLM. However, as I said, corporations often like to use NTLM
Please do not remove an nsenterprise nomination. nsenterprise is like nsbeta1, it is a +/- keyword. Someone nominates and then the keyword is given a +/- from the enterprise team. From the Keyword Descriptions: "This indicates a bug nominated as a blocker for Enterprise Use. Enterprise Use means the ability for large organizations (500+ users) to deploy the product for daily end-user use. This keyword will be changed to nsenterprise+ or the nsenterprise- keyword to indicate Netscape Enterprise Client Team (ECT) approval/rejection of higher prioritization of this bug." IMHO this is an enterprize blocker. I know of several companies that use NTLM with their intranets. (Including many universities -- with over 5000 users) renominating for nsenterprise
Keywords: nsenterprise
My employer is also dropping support for Netscape on our intranet because of this problem. As more and more of it becomes inacessible, the pages behind begin to be written to IE's DOM and the whole thing becomes more and more untenable (ie, the amount of work required to support Netscape increases). Its a wedge, without a doubt. Also: we're finding with our setup (several domains) we can't make basic authenitication and NTLM work reliably at the same time - even though we also allow basic aunthentication on many parts of the site increasingly Netscape users, version 4 or 6, still can't authenticate to servers in the other domains. This is clearly almost certainly a bug somewhere in Microsoft's server code, but the net effect is that Netscape doesn't work.
lordpixel: Since this should have worked for some time, lets get a new bug report on that, please.
Here is what I know about NTLM, this is more of a data dump of the things in my brain so that we can start figuring out how to tackle these problems one at a time. Plus most of this stuff isnt documentated anywhere so it helps to have it down somewhere. (Some of this is taken from other sources NTLM transaction 1: C --> S GET ... 2: C <-- S 401 Unauthorized WWW-Authenticate: NTLM 3: C --> S GET ... Authorization: NTLM <base64-encoded type-1-message> 4: C <-- S 401 Unauthorized WWW-Authenticate: NTLM <base64-encoded type-2-message> 5: C --> S GET ... Authorization: NTLM <base64-encoded type-3-message> 6: C <-- S 200 Ok Now its a *connection* authorization mechanism which means it must be kept-alived or this whole thing must start over again....It also appears that after it is authorized you dont need to send the authorization header no matter where you go... but i am not sure about this yet....a good resource is http://www.innovation.ch/java/ntlm.html
Oh yeah another thing is it has to use the same port for the authorization setup...if you use another port further along the whole process repeats itself...but i could be wrong on that one...
As far as I'm aware authorisation is intended only to apply to the directory whether the first request applied and sub directories. Whether this is an NTLM thing or a general HTTP auth thing or just an IIS thing I don't know. However its how IE behaves, based on the server logs I've looked through. It only sends authorization for items in that directory and sub directories. One gotcha - I've observed a bug in IE5 where javascript loaded URLs don't use authentication when they should. This should be part of the QA test for any Mozilla implementation.
for now, this is nsenterprise-
Keywords: nsenterprise → nsenterprise-
My company uses a ntlm proxy and I've finally managed to use Mozilla. I used the 'NTLM Authorization Proxy Server', a small application writeen in Python. http://www.geocities.com/rozmanov/ntlm/ This application also includes a html file with the 'NTLM Authentication Scheme for HTTP' that i'm adding as an attachment.
*** Bug 111128 has been marked as a duplicate of this bug. ***
This is the core NTLM implementation that libsoup (http transport library, gnome cvs module "soup") uses. It is verified working with several Windows versions. It contains a clean-roomed MD4 impl (licensed LGPL), public-domain DES impl, and all the NTLM protocol code. Contact me or Dan Winship (danw@ximian.com) if you need help on usage.
In addition to the above protocol flow, be aware that newer windows versions always close the connection after the first 401 response (step 2). So you need to be able to tell the next connection to begin the conversation at step 3. I don't know your abstractions at all, so this might be easy, but for soup it was a pain...
The first 401 response contains a "connection: close" header, mozilla's connection pooling handles this correctly and will indeed send the next request on a new connection. The problem is still bug 74246 where step 3 and 5 are sent over different connections.
I have been coding an addon to Squid to allow NTLM authorization with groups at work so I am well aware of how NTLM works in the real world etc. My main problem is i dont have enough computing power to actually test the patches (all I have is a 233 Mhz) so I am stuck with the cart but without the horse.
RE: Comment #57 Yes, forgive me for not being detailed enough... of course it will send the next request over a new connection, however either the message being sent or that new connection need to know 1) that this is a new connection 2) we are in the middle of NTLM auth, so start at step 3. If this is not handled, you will get in a loop as your connections are all closed after the first response (having not continued at step 3 and thus the server HUP'ing the connection). Yes, I had I had to deal with step 3 and 5 being sent over different conns too :)
You should also look at the "negotiate" authentication scheme that is used by newer MS IIS servers. This will replace the old NTLM scheme. With negotiate auth Kerberos can be used and with it, it is possible to make authentication from Unix without prompting for userid/password. So if Mozilla had that, it would be possible for both Unix and MS users to access pages without having to type in user/password (if you use Kerberos). The negotiate scheme is describe in IETF draft: draft-brezak-spnego-http-02.txt (current draft for the moment).
*** Bug 119472 has been marked as a duplicate of this bug. ***
Attached file NTLM proxy utility. —
An implementation of an NTLM proxy. Note that this also works with Opera v6.0.
I have seen that proxy and plan on using how it interfaces on Windows to the NTLM API as how we will but of course in C++ its very good as a temporary single user solution. Oh yeah and I finally got a computer that can compile Mozilla so now i can start working on it in ernest...Woot!
Keywords: mozilla0.9.4
See http://www.geocities.com/rozmanov/ntlm for a Python proxy workaround to this problem. Version 0.9.7 of this code includes some documentation on the NTLM protocol as well as a AUTH_DEBUG environment variable that instruments the NTLM negotiation sequence. The nice thing about being written in Python is that it's cross-platform so it works on our Suns.
*** Bug 124466 has been marked as a duplicate of this bug. ***
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
*** Bug 130355 has been marked as a duplicate of this bug. ***
-> me
Assignee: gagan → darin
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2alpha → Future
*** Bug 140353 has been marked as a duplicate of this bug. ***
*** Bug 140376 has been marked as a duplicate of this bug. ***
*** Bug 141508 has been marked as a duplicate of this bug. ***
*** Bug 143302 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0 → mozilla1.1
Hardware: PC → All
Is there an ETA on this feature? It still has a target of "future". We've run into a bunch of cases where the corporate proxy server only supports NTLM authentication (no more Basic Auth). Hence - no Internet access is available using Mozilla.
+nsenterprise. That might help.
Keywords: nsenterprise
I work (but only for another couple of weeks) at such a site. Our *&(*&^(*$%^ network maniacs went microsoft-only a few weeks ago and replaced squid with WebSweeper with NTLM-only authentication. Although the NTLMproxy server has been installed, it is unsatisfactory: - http and ftp downloads usually fail to retrieve the last packet. I have seen this affect .exe, .tar.gz and .pfd files. - a number of cgis e.g. tinderbox, mozilla cvs log are badly formatted, often with portions of <a> tags being rendered in the display. - many larg'ish pages do not 'complete' i.e. the Mozilla 'm' keeps 'waving' until, I presume, it times out. IE, directly talking to Websweeper, doesn't suffer these problems. There are at least two problems: 1. Because it spoofs the connection to look like IE, we get invalid HTML/DHTML i.e. w/ MS extensions. This is a nasty one and can only be fixed by native Mozilla support for NTLM. 2. The use of the proxy is less than perfect and can lose the last packet or so on large transfers. The net effect is that I am forced to use IE 6 for a number of actions :( PS. Of course, Netscape 4 suffers the same problems.
i'm going to be ambitious here and say that i'll have time to work on this for 1.1beta ;-)
Target Milestone: Future → mozilla1.1beta
Darin, go, go :-) Please keep in mind that NTLM may also be used with SMTP, IMAP, POP and NNTP. It would be great if you're routines would be reusable for the other protocols.
*** Bug 150537 has been marked as a duplicate of this bug. ***
*** Bug 18891 has been marked as a duplicate of this bug. ***
*** Bug 150840 has been marked as a duplicate of this bug. ***
Can someone verify that this problem is also the culprit in bug 151422?
This may be obvious, but having set up Outlook Web Access in the past, I thought I'd mention it. Outlook Web Access can be set to use HTTP Basic Authentication, NTLM Authentication, or both/either. The setup screen muddies the waters a bit by showing the options as "Basic Authentication" or "Secure Authentication". Any admin not very versed in Microsoft Newspeak (tm) could easily set their server up for secure authentication only, figuring that it's more secure. If so, bugs here could be very server-specific. I personally know Moz had no issues with Basic Authentication the last time I had to use Outlook Web Access. Another big question would be whether Outlook handles the Basic+Secure setting correctly. I don't have the server to test this out with anymore, unfortunately.
Damn wrong bug. Spam.
*** Bug 151422 has been marked as a duplicate of this bug. ***
wtc: NSS provides DES and MD4 crypto algorithms, right? if so, what's the best way to expose them to our HTTP implementation? MD5 (and others) are already available via caps/idl/nsISignatureVerifier.idl... can this be extended? thx!
kaie, ssaux: so i'd like to extend nsISignatureVerifier to provide DES and MD4. is this possible? wtc tells me that NSS probably doesn't provide MD4 since it is known to be insecure, but inorder to provide NTLM support we have to use it. we have a clean-roomed MD4 impl attached to this bug, so we could just use that. my only concern is that i figure the MD4 code probably can't live in necko (because of import restrictions in some countries). so, can PSM provide these crypto algorithms via nsISignatureVerifier? thx!!
I confirmed that NSS doesn't provide MD4. We did not include MD4 in NSS because there are known attacks against parts of the MD4 algorithm. (See Applied Cryptography, 2nd. Ed., pp 435-436.)
Darin, we don't have the resources right now with the RTM release to add this to the PSM code. I'm also worried about adding something to the crypto code that is known to be breakable. I'll need to check with a few folks.
MD4 is a small algorithm, moreover it will never be used by PSM, why not just adding it inline in the NTLM code?
Side suggestion: If an NTLM session tries to use MD4 (once implemented), we could pop up a separate "insecurity" dialog requesting that you contact the site administrator and that data may not be secure. Or, at least, override the "lock" icon in the lower right corner of the window. Of course, such discussions are best saved for later.
afaik that's like saying if an ntlm server is NT4, complain. open a npm.necko thread (i'll gladly ignore it, but you'll be able to have your discussion)
I agree with timeless. We don't display a warning for basic-cleartext, which is even less secure, so i don't see a reason to display a warning for NTML. But we should defenetly not lock the lock-icon since NTML doesn't give secure transfers in any way.
I think, if the NSS team does not want to add the algorithm, the second best place would be PSM. This would save us the hassle of having another module that needs to be handled as export controlled. However, which directory should the code get added to? mozilla/security/nss is out. security/manager/ssl is mostly a C++ wrapper around NSS, and does not seem logically approriate. It also has some special magic to couple module init to NSS init, and it disables any services from within that module, if NSS can not get initialized. So an unavailability of NSS would also mean other algorithms would not be available, too. security/manager/pki defines no crypto logic on its own, but contains Mozilla UI glue code to NSS. It also contains logic embeddors are likely to replace, so we should not add base logic here. security/manager/boot is only a lean subset of the crypto UI glue code. We created it, when we were asked to optimize the startup time. We also have an open request, to optimize the number of XPCom modules, and we might eventually move this code over to other Mozilla components, eliminating this module. While I personally wouldn't have a problem with adding the logic to the security/manager/boot module, this makes implementing the optimization bug harder. If our intention is to keep the above logical structure, it would make sense to start a new XPCom module, and add that as a new directory named (suggestion): mozilla/security/non-nss
kaie: either way can MD4 be exposed via nsISignatureVerifier, which nsNSSComponent implements?
Depends on: 152883
> can MD4 be exposed via nsISignatureVerifier, which nsNSSComponent implements? I think we can reuse the interface. But I think, if the implementation of MD4 does not live inside security/manager/ssl/, a different implementation of this interface should be used to verify MD4. I suggest to use a new contract ID for the verification services offered by a new XPCom module, implemented in mozilla/security/non-nss like "@mozilla.org/non-nss/signature-verifier-service;1" The netwerk code could know when to ask for the new contract ID (right now only for MD4), and when to ask for the psm contract ID. If you want to, I'd say it is fine to use the existing interface nsISignatureVerifier regardless who implements it. This probably makes life easier for those modules who need verification services from multiple implementors. We can add additional algorithm ID constants to the interface. But we need to be careful when choosing the constants. Currently, function hashBegin takes as an argument a number, which is directly mapped to NSS's own set of internal algorithms IDs. We either must use a different range of numeric identifiers, those which are guaranteed to get never used by NSS. Or we should ask the NSS team to at least define and reserve a numeric ID for any algorithm they are not providing and that the Mozilla team wants to implement on their own.
*** Bug 152481 has been marked as a duplicate of this bug. ***
The good and safe workaround for NTLM authorization in IIS Web sites and MS proxies is using SSL at site/proxy and using user certificates for NT logins (Certificate Server is required in your domain/AD). See my comments (#44) in bug 35159 for details. But I hope this bug to be fixed.
There are no workarounds if your IT administration is hell bent on using only NTLM for their MS proxy servers. Trying to convince them to upgrade their security infrastructure to include certificates for everyone, while laudable, is like hitting your head against a wall. That dog just don't hunt.
*** Bug 158619 has been marked as a duplicate of this bug. ***
not going to make it for moz 1.1
Target Milestone: mozilla1.1beta → mozilla1.2alpha
Keywords: approval, mozilla1.1, patch, qawanted, review
This will have to be a Windows-only implementation. You need to go through SSPI which depends on the OS for the passing of credentials. White Paper: http://www.microsoft.com/windows2000/techinfo/howitworks/security/sspi2000.asp Implementing: http://msdn.microsoft.com/library/en-us/security/security/initializing_sspi.asp I recommend that the Severity be changed from enhancement to normal since as of right now, credentials are being send clear-text without the user knowing otherwise.
If this ends up being Windows-only, then Platform and OS should be set accordingly, and bug 151422 will need to be reopened to cover it on Mac OS.
there's no reason to limit this to windows only. we can easily put together a XP solution. we don't have to reuse microsoft libraries (though we could on windows if we really really wanted to). the only hard part about this patch is solving bug 152883, which kai seems to have a good start on.
There are two big advantages to using a native windows implementation: 1) SSPI can by used to send the credentials of the user running the browser without any user interaction. In an intranet situation (workstation and web/proxy server share the same user database) this means seamless authentication. IMHO, this is usually how windows authentication is used. I am not sure if Mozilla would be able to grab a hold of these credentials and use them for network authentication without using SSPI (I doubt it). 2) The first step of an SSPI driven authentication negotiates the authentication protocol. NTLM is but one possible outcomes. Two windows 2000 machines might choose to use MS's kerebos implementation instead of NTLM. If memory serves me, it is possible to disable NTLM altogether in a pure windows 2000+ domain, my guess is that then IIS/MS Proxy server will require kerebos instead of NTLM to authenticate the connection and the solutions proposed in the bug won't work. There is obviously a big advantage to having NTLM on non-windows platforms as well. I do however think that using SSPI on windows would be desireable. I filed bug 159015 (Implement windows authentication using SSPI) to 'request' ;-) a seperate windows implementation as well.
Blocks: 159015
No longer blocks: 159015
I fully support Darin. NTLM support must be platform independent, for example, to use it on MacOS behind MS Proxy or to visit sites with IIS authentication from Linux system. Using SSPI is, IMHO, not so good idea - I may want to logon to MS Proxy or IIS with another login, not current at my local PC.
It should be XP. For Unix I suggest using SAMBAs winbindd (used to provide NTLM service for PAM, Apache and the Cyrus SASL lib). The drawback is thta Mozilla will depend on a SAMBA installation. OTOH, who deploys a Linux box in a NT network certainly uses SAMBA anyway. Whether it is a good idea to use SSPI on Windows cannot say. But creating our very own implementation of NTLM could be hard (and will probably not 100% compatible) so I vote for reusing existing mechanisms. I am not a Mac guy so I don't know the situation is there. SAMBA will probably run on OS X, but thatÄs no good for OS 8/9.
SAMBA exists not on all Unix compatible systems. And if I want to logon in IIS site over the Internet (not in LAN) - following your logic I must install SAMBA anyway? Maybe, you think that we must include SAMBA in Mozilla install package? I hope NTLM support is not so hard thing to relalize it in native Mozilla code - it implementation in SAMBA and in Python NTLM proxy utility doesn't look as very complicated issue.
To avoid coding every available security option into an application, SSPI enables applications to access dynamic-link libraries containing common authentication and cryptographic data schemes. An application implementing SSPI can use any security package available on a system without knowing details about the security protocols that the security package implements. manko's statement - "I may want to logon to MS Proxy or IIS with another login, not current at my local PC." If the authentication fails with Kerberos, then it prompts you for credentials that it passes via NTLM. So you CAN use SSPI on Windows and still use a login that differs from your Domain account that you login to your PC with. It would be nice to have NTLM support on the UNIX/Mac side, but there is a greater need right now with Windows clients to have this ASAP. The methods are there, and you do not need to worry about hashing with bug 152883 or proxies or anything like that if you are using SSPI (Re-read my first paragraph).
If Mozilla is to be a viable alternative to MS products, the Mozilla group must commit to supporting all of MS Proxy's non-standard quicks in a timely, high priority, cross-platform manner. Leaving NTLM authentication as a priority 3 enhancement and taking 2 years (and counting) to handle it is the best way I can think of to encourage the MS folks to add some new blocking "feature" when you finally get NTLM implemented. Unfortunately I don't have the expertise to assist with this project, but as a user stuck behind a corporate MS Proxy server I can tell you that Mozilla's features, performance and stability don't matter if you can't authenticate.
In my organization, the timesheet application is behind NTLM on the intranet. If you don't fill out the timesheet, you don't get paid. Or health benefits for that matter. The intranet administrators are a hostile entity that cannot be negotiated with. Our intranet applications slowly become increasingly dependent on IE-only features. Worse, I work in the most enlightened company in the region. I can't escape. Since there seem to be many of us that are interested in this problem, but few of us who feel qualified to contribute, maybe we could set up a separate mailing list where we can work this puzzle out together?
I can help with the SSPI and how authentication works in Windows. I only know VB and VB.NET, so I wouldn't be too much help in implementing. If you want my help with the Windows side, SSPI, Domain authentication, I'm here.
(I'll try to be brief, because many people have heard what I am going to say here before...) Mozilla's trunk code base is strongly rooted in XP solutions. Many of the consumers of the code (who hope to make finished products from the code) work in XP or non-Windows environments. As such, the general aproach of Mozilla is to implement, whenever possible, a single, cross-platform solution. However, Mozilla has obviously added platform features, which I think is a sign of the code maturity and robustness. Reading Mac OS prefs in Chimera and Windows-path handling in URL bar are good examples. As such, I think this dicussion of using a native Windows library is a good idea. However, this is clearly not what was originally contemplated here, so I suggest the following: create a new bug that is Windows-only. If you do successfully create a Windows patch, you will need to make this feature pref-controlled. Once that bug is fixed, we can resume the debate over which is the better choice (presumably which would be "on" by default in Windows).
I'll bug it since I know what is involved on the windows side.
Windows implementation is now Bug 159215, assigned to mstoltz@netscape.com.
Correction :) Windows implementation is now Bug 159015
This "bug" should be fixed for all platforms. Without it for many people, they are excluded from small company intranet applications without access to a browser that can do this NTLM authentication. That is to say they have to have a windows box. It should be easy to implement stand alone on all platforms. There is code from SAMBA and a small standalone python daemon that can also be used as a resource (search for aps097 in google). I know it is an insecure non standard proprietary authentication protocol, but that shouldn't stop you from implementing it. My company for example offers Linux users a citrix server to access windows apps. Great. But then the MSCE certs decided to only allow access to citrix through a NTLM secured web server. Without recourse to the python server the Linux users would have been out in the cold. It would all be a lot easier if it was built into Mozilla.
my plan is still to implement the XP solution outlined in attachment 53556 [details].
Darin, I agree that attachment 53556 [details] is agood starting point and will provide a basic implementation. However, MS seems to have a number of various variations of the protcol plus keeps on adding "enhancements". So on Windows using SSPI will always provide better support. IMHO the same is true for using SAMBA/winbindd on Unix. The guys have a natural interest in keeping up with MS. That said I think, Mozilla should have a fallback XP implementation of NTLM, but should either use platform dependent code if possible or allow some kind of plug-in to be used instead. Is there a need for a "Win auth using winbindd" bug?
NTLM has a two implementatons - v1 and v2. The difference, AFAIK, is only in encryption algorithm: NTLM v1 uses 56 bit MD4 hash and v2 uses 128 bit MD5 hash. SAMBA supports both versions. I think (hope ;) that MS hasn't plans to develope new incompatible NTLM algorhithms just now - a big park of Windows NT 4 and 2000 servers will demand backward compatibility still long time.
NTLM is there for backwards compatibilty. MS Kerberos is used first then NTLM is Kerberos is unavailable.
Blocks: 159015
Description of MS Kerberos http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000serv/deploy/kerberos.asp But NTLM is favorite for IIS web-servers in Internet.
Keywords: nsbeta1
Adding topembed since we got a topsite using this authentication method from the Latin America evangelism effort.
Keywords: topembed
*** Bug 160529 has been marked as a duplicate of this bug. ***
bumping the vote count up to 79. The wedge has struck here. Our medical school standardized on MSIE a couple of years ago, and just last week started enforcing that policy by using NTLM-only on all of our intranet content. Thousands of users can no longer use mozilla. I code perl for said intranet and have had to start using MSIE. ;6 <-- that's a "Mr. Yuck" face At least I'm on MacOS X rather than linux or I wouldn't even be able to use my OS. Damned wedge. :( Seconding Martin in comment #77 > Darin, go, go :-) -matt
Blocks: 61681
adding nsdogfood on behalf of myself and all others who have been locked out of our intranets with a switch to IIS and NTML. Well, not entirely locked out, but not able to get in with mozilla... -matt
Keywords: nsdogfood
Removing nsdogfood, which is only fed to NS dogs. See the keyword description.
Keywords: nsdogfood
Darin, what is the next step here.
Keywords: topembed → topembed+
Blocks: majorbugs
the next step is for me to finish off the patch i'm working on ;-)
*** Bug 164879 has been marked as a duplicate of this bug. ***
*** Bug 165798 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Blocks: 164421
Darin, any update on progress towards resolving this bug?
difficult to find time to work on this patch these days... but i'm still optimistic about getting this in by moz 1.2 :)
QA Contact: benc → tever
*** Bug 170754 has been marked as a duplicate of this bug. ***
*Please* don't create yet-another-bodgy-ntlmssp-implementation... A *lot* of products are seem to have much of and idea trying the NTLMSPP game on unix, but very few seem to have much of an idea what NTLMSSP is. Firstly, the patches I see here seem to miss the point: NTLMSSP is DCE-RPC NDR encoded. It has muliple negotiation flags, and is quite a 'general' protocol. In particular, the flags presented by ISS is not the same as persented by exchange, or their SMB server. So creating a 'this is what I saw on the wire' implemeation will probably break. I have a spec out on solving this (for unix platforms, server side), see: http://lists.samba.org/pipermail/samba-technical/2002-September/039255.html and I think the client can be solved in a similar way. For windows systems, using the SSPI is the *much* prefered method. Please keep in touch with the Samba Team on these issues! (BTW, there is LGPL MD4 at mhash.sf.net) Andrew Bartlett
Filed a new bug on supporting NLTMSSP on Unix with winbindd. Added the to the blocker list, though I think it should be listed with #159015 as a dependency.
Blocks: 171500
It sounds like you're already past the point where this would be of help, but just in case, here's a perl module that does NTLM http://search.cpan.org/dist/Authen-Perl-NTLM/ distributed under the same terms as perl itself namely: http://www.perldoc.com/perl5.6.1/Artistic.html -matt
not going to make it for mozilla 1.2
Target Milestone: mozilla1.2beta → mozilla1.3alpha
*** Bug 149842 has been marked as a duplicate of this bug. ***
I don't mean to sound ungreatful or anything, but can somebody please let us poor users who are stuck behind NTLM-only proxy servers know what's holding this up? Surely 3 years and half a dozen sample implementations in other languages should be enough to get this done.
it has unfortunately taken a back seat, but i'm hoping (cross your fingers) to have time to work on it soon.
I think the priority must be set more high !
With 134 votes this bug is among the top 10 as voted by users. Yet priority is still P3. Seems like a disconnect to me. From my experience, I can tell you that NTLM is very popular because it provides transparent authentication with high security. Most major sites on my company's intranet use it, some exclusively. Users can't use Mozilla if NTLM is the only authentication mechanism allowed by an intranet site. And if basic authentication is allowed as a backup, users are prompted to authenticate every time. All this quickly discourages users from using Mozilla.
*** Bug 179521 has been marked as a duplicate of this bug. ***
I told some of my coworkers how proud I was to remove Microsoft products from the dock (OSX). Because of this problem, explorer is back. Like some others, NTLM is used in my department and I need access. Please make this high priority.
llichtor, see bug 35159 comment 36 and bug 35159 comment 44 to workaround your troubles.
is there a workaround for NTLM digest authentication in IIS? <deleted>(why I hate having to use MSIE to debug CGI scripts at work)</deleted> -matt
There are 2 workarounds for NTLM authentication. 1. Basic authentication. Simple in use, but unsafe for non-SSL connections. SSL (https://) connections are safe because plaintext password is being sent in already encrypted TCP packet. For more information see: http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm#enablebasic You must specufy default NT domain in IIS settings for plain username. If default domain is omitted or you want use login from another NT domain, use "DOMAINNAME\username" in login field at authentication dialog window. 2. Using certificates mapped to NT accounts. This is SSL-only feature, but very useful and secure. See: http://www.microsoft.com/windows2000/en/server/iis/htm/core/iicerts.htm?id=90 Certificates issued by Windows-based certification root, must be exported on PKCS #12 format then imported in Mozilla, see also bug 35159 comment 44.
Sorry "manko", but any "workaround" that forces the IT organization to change their configuration of the proxy server or their web servers is not a workaround. The only available workaround must be performed by the browser or under the browser user's control. Even an accommodating IT organization such as ours draws the line on this.
Brian, we use Mozilla as standard browser in our company instead of MSIE for security reasons. And I consider that webmasters and system administrators must do not ignore Mozilla users. Moreover sysadmins IMHO must encourage using Mozilla at workplaces thanks to it safety and traffic savings - attempt to convince your sysadmin by this arguments. Of course, this bug must be fixed, but if your webmaster or proxy administrator can add Mozilla support just now, I see no reasons for disregarding.
Sorry - not disregarding anything. But many sysadmins (including our own) refuse to "turn on" basic authentication for any reason. They've got it in their head that this is the most secure means to restrict access to systems within their network in the most secure means. I can talk til I'm blue in the face about what is or isn't more secure. They won't change their mind for a handful of mozilla users who have broken ranks with the corporate standard. This plays out all over corporate America everyday. So, every release when this bug gets deferred to the next release (it's happened at least 3 times), mozilla goes another release where it can't be easily used in the office. For me, the only way around it today is to install a proxy server on my PC and route all traffic through it, even though I only need it for a handful of corporate servers. Obviously, if it were a proxy server that was blocking my way, it (separate proxy) wouldn't seem to be such a waste of resources.
and yet NTLM use weak crypto algorithms... lovely ;-)
Stop making this political and just start working on the bug.
Missing the point again. Crypto strength does not matter. The predominant attitude in IT administration is set - you can't change it. I've had arguments with sysadmins who argued that telnet was more secure than rlogin because rlogin might have a password passed in the clear (he read that somewhere). Never mind that so did telnet. Or the argument from a different admin who wouldn't let us use SSH because SSL was more secure. It makes no sense. IT makes no sense. You can bludgeon your head against the wall for years and it won't ever make sense. This is a top-10 problem for Mozilla but it never gets fixed. I can only presume it's personally distasteful for Mozilla developers to fix.
Top-10? This bug is probably somewhere in the Top-1 bugs affecting Mozilla's usability.
The severity was set as an Enhancement in Jan of 2000, can it please be changed to Normal. Darin, where are you on this? Please post your progress or what you need help with. If you don't have the time to work on this and don't consider it serious enough, assign it to someone else.
> I can only presume it's personally distasteful for Mozilla developers to fix. this is by far the most moronic thing i've ever heard. get a grip man!!! everyone wants this to be fixed, including me (the person who will most likely do the work). i understand how important this is to many many users. it is important to the mozilla project and to netscape, but so are a huge pile of other bugs. the only reason this bug has been delayed is because it is difficult to fix. several folks have attempted to fix it, but have given up after they realized just how much work is involved. it will take a good couple of weeks to fix this bug, and right now i am being paid to work on other things. if someone else wants to own this bug, please let me know. otherwise, comment #140 still holds. if you have further comments that are NOT constructive please find an appropriate mailing list or newsgroup instead. let's please PLEASE cut out the useless chatter in this bug report. thanks!
> The severity was set as an Enhancement in Jan of 2000, can it please be > changed to Normal. why? enhancement is not less than normal. enhancement means that this is an addition to the mozilla feature set. the severity level is correct.
>why? enhancement is not less than normal. enhancement means that this is an >addition to the mozilla feature set. the severity level is correct. This is not a feature request, this is a loss of function where there is not an easy workaround present. Users can not access the site at all, there is no way for them to get to the site no matter what workaround the client tries to do. I would think this falls between Major and Minor. It should be changed to Normal.
The severity must be set to BLOCKER because it blocks hundreds of thousands people all over the world off from using the Mozilla Browser !
Greetings. I think I will have to side with the many that complained for the apparent stagnation of the activity surrounding this bug. It looks to me that a very clear and important business case exists for this to be fixed - it is a missing feature that unnecessarily restrict the browser's user base, something that should be important to the Mozilla project. Makes one wonder what can be so much more deserving than this to prevent allocating the time and resources needed for about three years time, 144 votes and more than 160 comments.
To all those complaining about the progress of this bug: This is not an easy bug to fix, certianly not properly. It is easy (as has been demonstrated) to create nice intel-only works-for-me solutions to this problem. It is *much* harder to create a sufficent implemention of NTLMSSP to actually cope with the range of MS (and other!) servers that this will encounter. Furthermore, depending on the implementation, it might not solve your problems anyway! Until the SSPI version is implemented (which should be the easier of the two to tackle) you will not get 'no password prompt' stuff anyway. There are also serious security issues to be addressed: Microsoft uses their 'internet security zones' to determine where they should send an NTLM password. Mozilla must do the same, becouse otherwise there are *serious* security risks. (NTLMSSP is easily used in a MITM attack, and brute forcing an LM hash is quite cheap these days.) Netscape and Mozilla have never shipped with support for this method of authentication, a scheme that breaks all the relevent RFCs, so while I can understand people wanting bugs 'upgraded', this is an enhancement, and is certainly not a show-stopper. (Which would imply loss of functionaliy, IMHO). In the meantime, there are workarounds for those stuck in this situation. Finally, for those with time to develop this area, the ethereal network sniffer decodes NTLMSSP over HTTP, and I intend to get some Samba-side stuff done that would allow the use of some Samba code in solving this unix-side. Andrew Bartlett Samba Team
OK, at about comment 160 I begin to think a bug has gotten out of hand. Please do not post any comments to this bug unless you have working code to fix this problem. Darin has on numerous occasions (most recently comment #156) said that he has this bug planned, but is being paid to fix other more important bugs at the moment. When the time comes, he will focus on this. If you want to try to fix the bug, please do so. There is (believe it or not) a lot of useful information in this bug to help you. If you want to whine, you should do it in the newsgroups (netscape.public.mozilla.browser would be a good try) or you can submit requests to Netscape at http://channels.netscape.com/ns/browsers/7/feedback/default.jsp Perhaps then you can affect which bugs Darin gets paid to work on. :-)
Whiteboard: DO NOT SPAM read comment #162 before posting
I've been trying to stay out of this, as I've been following this bug for about a year now, but I've got a few things on my mind. I understand where the developers and such are coming from on the fact that this is time consuming, and I understand that they have to meet the needs of the users with what is feesable. But, this missing feature/bug (depending on ones point of view) is costly to NS and to Mozilla. How can you expect this to be used by the masses when it doesn't fully support existing technology. And why is it that this bug has been here nearly 3 years without anything but "low priority" as a comment from the netscape crew? Unfortunately, the ostrich syndrom that surrounds this bug isn't going to help Mozilla, it is ultimately going to hinder it. Regardless of what they think, NTLM isn't going away. Not that I can see. Why not take a bite of humble pie, get this fixed, and move on to bigger and better things, like tackling the other bugs out there. If I was proficient enough in the language, I'd certainly offer my services, but I'm not. If this were fixed, then IE would have a serious threat posed against it.
Contribute code or money, or please for the sake of whatever deity you hold holy shut up.
And nothing like Comment 164 proving my point exactly. Remarks telling people to "contriube code/money or shutup" are not the type of things that this project is about. Just because I don't contribute code or money does not make my points have any less value than yours. Every time I launched Mozilla it tells me "This means that you've volunteered to become part of the Mozilla testing community. Great! Welcome aboard. Helping out won't take much of your time, doesn't require special skills, and will help improve Mozilla." I'm trying to help improve Mozilla, but it's hard to help improve when feedback by users is ignored, and taken with a grain of salt. I am a developer by day. I know what it means to have users asking for features, and giving feedback on current features. But I don't get a RFE/Bug and say "Oh, we'll look at it in about 5 years". That's very bad practice for a developer. The attitude that i've observed is that users feedback doesn't mean squat in your eyes, Andrew. You don't have to write code to contribue feedback to the project...like it says in the quote I pasted "helping out doesn't special skills".
I see some of the delays in this bug as resulting from bug 74246 and bug 152883 but in at least bug 74246's case, there's a feedback loop (bug 23679 isn't moving, so bug 74246 won't move ...). For many reasons (which I vote for in my bug votes) I can't deploy Mozilla as the primary browser in the businesses I consult for. However, it seems people are willing to put time into implementing tabbed browsing and/or banner blocking. I'm glad these people contribute code, but some of the features Mozilla lacks (like NTLM authentication) require people with good Mozilla & coding experience and I hope those people are willing to at least get their feet wet in it at some point. Did anyone else notice that bug 159015 also depends on this bug, even though it was pointed to expressly because its solution could be developped astride of this one's? PS, Anyone openened a bug for .NET authentication yet? :-) Better get started early. Keep up the good work, even if its another 3 years ...
See: http://www.luigidragone.com/networking/ntlm.html for a supposedly "100 Pure Java" implementation of the MS NTLM authentication protocol offered under the GNU GPL. I'm not a C or Java programmer so I can't vouch for the accuracy or completeness of this code, but it might provide a means of getting NTLM authentication into a Java enabled Mozilla browser reasonably quickly. We've been stuck behind an NTLM-only MS Proxy server for the past three years and have had switch away from Netscape onto MS Internet Explorer running on Solaris (yuck). Since MS recently discontinued this product, we're about to be left in the lurch.
That page does not work for me, but here is the google cache: http://www.google.ca/search? q=cache:h2HCA2EommYC:www.luigidragone.com/networking/ntlm.html+&hl=en&ie=UTF-8
-> 1.3 beta
Target Milestone: mozilla1.3alpha → mozilla1.3beta
Hi, Sorry, a little new to the Bugzilla etc world (including Multizilla for me). I find your comment Darin a bit cryptic (um so to speak). -> 1.3 beta Does that mean it's going in now? Yesterday's 12/3 build? (Was before the time of your post so probably not). So maybe today's build 12/4? Or is this just an indication that you think it'll be in there sometime with 1.3 beta? Looking forward very much to getting NTLM and appreciate all the work of the programmers who've made a much superior product to IE (sorry if that seems faint praise). thanx. pat
*** Bug 183972 has been marked as a duplicate of this bug. ***
NTLM also need to make it into the installer, I couldn't install NS7.01 today because the installer couldn't get through the proxy. This means that any web-development work I do won't be tested against NS7.01, and therefore may only work with IE and older NS/Moz browsers.
Don't want to add too much to the spam, but the 1.3 beta tag means that he will try to get an implementation in sometime during the 1.3 beta which realistically means before the feature freeze for 1.3. When is the feature freeze for 1.3? According to the roadmap it scheduled for the end of January next year, so anytime
A full installer for Netscape 7.01 is available. http://wp.netscape.com/download/full_install.html
Rozmanov's utility (NTLM proxy, written in PHP) can be download from: http://www.http-tunnel.com/aps098.zip Freshmeat/Geocities URLs are outdated.
In the Comment #175 I made a mistake: That proxy -- of course -- written in Python, not PHP...
*** Bug 187800 has been marked as a duplicate of this bug. ***
*** Bug 189170 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.3beta → mozilla1.4alpha
*** Bug 190530 has been marked as a duplicate of this bug. ***
Can we have any news about mozilla ntlm implementation? Thanks a lot
Hi there, yes, I too am keen to find out whether NTLM support will make it into 1.3. Currently using 1.3b and its great! Probably the best Moz ever, just shy of NTLM support ... :-(
There is no way that this bug will make it for 1.3. No patch was checked in, I don't even know if anyone is actively working on this.
If you must have NTLM right now, and are running windows, have a look at bug 159015 , which has a preliminary patch. Apologies to anyone that already knows this.
*** Bug 198323 has been marked as a duplicate of this bug. ***
*** Bug 198819 has been marked as a duplicate of this bug. ***
topembed- per edt@netscape.com
Keywords: topembed+ → topembed-
Priority: P3 → P5
Target Milestone: mozilla1.4alpha → Future
Brilliant - thank you ! Mozilla Works for me under Mozilla 1.4b Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 we have a W2K with Microsoft ISA proxy doing NTLM auth. Goodbye to the Python proxy ! :-) darren.
Is there a problem with WWW-Authenticate: Negotiate NTLM? I use: Mozilla 1.4b Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507 I do not see a pop-up, but instead immediately get: "HTTP 401.2 - Unauthorized: Logon failed due to server configuration Internet Information Services" I connect to the IIS server over the Internet (I am at home and the server at work). In IE the expected pop-up appears and I can connect. On the server only "Integrated Windows authentication" is enabled. Headers from LiveHTTPHeaders: http://the.server.domain/app/admin.asp GET /app/admin.asp HTTP/1.1 Host: the.server.domain User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507 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 Connection: keep-alive HTTP/1.x 401 Access Denied Server: Microsoft-IIS/5.0 Date: Fri, 09 May 2003 17:00:28 GMT WWW-Authenticate: Negotiate NTLM Connection: close Content-Length: 4431 Content-Type: text/html
Regarding comment 188: It would appear that the WWW-Authenticate header is continued to the next line without a preceeding white space character. That violates RFC 822, RFC 1945, RFC 2068, and RFC 2616. Of course, mozilla does it, too (bug 205078). Is there anyway you could get the hex values of the output and post that? I would guess IIS is delimiting continued lines with a "\n" and ending headers with "\r\n". Making mozilla support that would probably then fail with some otherwise broken servers and scripts, though (things that send "\n" rather than "\r\n" when they meant end-of-header). I wonder what IE does. Also, a similar but slightly different problem: mozilla doesn't handle multiple authentication types listed on a single line. Mozilla won't handle it, but it is valid to do: WWW-Authenticate: Basic realm="foo" Digest realm="bar"
Running IE and accessing the IIS server. From tethereal -x -i eth0 'port 80': 5 0.148392 ip.from.my.server -> ip.to.my.client HTTP HTTP/1.1 401 Access Denied 0030 fa 2a a3 6e 00 00 48 54 54 50 2f 31 2e 31 20 34 .*.n..HTTP/1.1 4 0040 30 31 20 41 63 63 65 73 73 20 44 65 6e 69 65 64 01 Access Denied 0050 0d 0a 53 65 72 76 65 72 3a 20 4d 69 63 72 6f 73 ..Server: Micros 0060 6f 66 74 2d 49 49 53 2f 35 2e 30 0d 0a 44 61 74 oft-IIS/5.0..Dat 0070 65 3a 20 46 72 69 2c 20 30 39 20 4d 61 79 20 32 e: Fri, 09 May 2 0080 30 30 33 20 32 31 3a 34 34 3a 32 39 20 47 4d 54 003 21:44:29 GMT 0090 0d 0a 57 57 57 2d 41 75 74 68 65 6e 74 69 63 61 ..WWW-Authentica 00a0 74 65 3a 20 4e 65 67 6f 74 69 61 74 65 0d 0a 57 te: Negotiate..W 00b0 57 57 2d 41 75 74 68 65 6e 74 69 63 61 74 65 3a WW-Authenticate: 00c0 20 4e 54 4c 4d 0d 0a 43 6f 6e 6e 65 63 74 69 6f NTLM..Connectio 00d0 6e 3a 20 63 6c 6f 73 65 0d 0a 43 6f 6e 74 65 6e n: close..Conten 00e0 74 2d 4c 65 6e 67 74 68 3a 20 34 34 33 31 0d 0a t-Length: 4431.. 00f0 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 Content-Type: te 0100 78 74 2f 68 74 6d 6c 0d 0a 0d 0a 3c 21 44 4f 43 xt/html....<!DOC Or in plain ascii: WWW-Authenticate: Negotiate\r\n WWW-Authenticate: NTLM\r\n Is there a way to configure NTML to make mozilla work? Is Comment #187 just for a proxy? What are the testcase in mozilla for NTML? Mozilla support for NTML is on the first page of mozilla.org.
Regarding Comment 188 I have reported the 401.2 Error with IIS at #200520 as a separate bug report. I'm using an IIS with Integrated Windows Authentication at my workplace, and it is doing the exact behavior that you are experiencing.
>It would appear that the WWW-Authenticate header is continued to the next line >without a preceeding white space character. That violates RFC 822, RFC 1945, RFC >2068, and RFC 2616. Of course, mozilla does it, too (bug 205078). no! you are seeing the results of the way necko coalesces multiple WWW-Authenticate response headers. the \n is completely fabricated by necko for internal reasons (because some sites insert ',' into their realm).
NTLM is disabled if PSM is not installed. please verify that you have PSM installed.
Installed Mozilla 1.4b on a Win98 that never have had mozilla installed before. Basic auth works, https: works (is that enough to be sure that PSM is installed?). NTLM just gives me HTTP 401.2 - Unauthorized directly, no pop-up for entering username, etc. Can this be related to just Win98 then? Comment 187 means it works on WinXP?
1.4b works fine on NT 4 sp6, but not on Windows 98. I'm getting the box with password and login on NT, but it's not poping up on 98 and I'm getting the same error Morgan received. I'm testing this out on VirtualPC in two (one NT & one 98) VPCs and on two other systems in the same setup.
1.4b works fine on NT 4 sp6, but not on Windows 98. I'm getting the box with password and login on NT, but it's not poping up on 98 and I'm getting the same error Morgan received. I'm testing this out on VirtualPC in two (one NT & one 98) VPCs and on two other systems in the same setup.
The current nightly builds work for WinXP, but still fail on Win98 for an ISA proxy with NTLM enabled.
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 207471 has been marked as a duplicate of this bug. ***
*** Bug 35159 has been marked as a duplicate of this bug. ***
Should I open a bug against the web site and release notes that report NTLM as functional as of 1.4 (I get a basic auth prompt indicating NTLM Auth failed)? This feature still looks to be a work in progress...
Re: comment 202: please provide more information about your setup in the future. There are known limitations on the NTLM support, and the release notes specify this. Useful information includes your version of mozilla (from about:) and your operating system (platform and version, e.g. RedHat Linux 9.0 on PC, Win2K, etc.). If you are using Mozilla 1.4 on Windows, please file a new bug with details about your setup. If you are not using Mozilla 1.4 on Windows, please re-read the release notes, where it mentions that support is currently only available on Windows.
*** Bug 213278 has been marked as a duplicate of this bug. ***
When will NTLM auth come to non-windows builds? I'm thinking talking through SAMBA, perhaps, for Unix builds? Does anyone know if this is underway, if a plugin exists on MozDev, or if it is unfeasible because of some reason? If I were to try and do this myself is there anyone I can talk to who could advise re: the NTLM auth protocol? Thanks, Manik
In the release notes for Mozilla 1.4.1 I found that windows builds now supports windows NTLM authentification. I'm not sure that I understand correctly what it is, but I hope it's so. In my work office installed MS ISA firewall and proxy with authentification. So, when the first mozilla window opened and accessed to any web-site I have to enter my login and password which is the same I used when logging in windows. This is very inconveniently you know. I cant even save this login+password in my mozilla profile. But MS IE somewhat doesn't require such authorization but working fine. So, is NTLM auth is what I need? If yes, why Mozilla 1.5 doesn't seemes to support it? About my system: Windows XP Professional/Eng, Mozilla 1.5-Win32.
this bug is fixed. see bug 224653 for details. here's a quick summary: o starting with mozilla 1.6 beta, it should be possible to connect using NTLM authentication on all platforms. note: NTLM is currently only supported for HTTP or HTTPS. o it is not supported when FIPS mode is enabled (because it uses MD4). o the SSPI based WIN32 implementation has been dropped in favor of the new cross-platform implementation. we had too many bugs with SSPI crashing on older machines. if possible, i'd therefore like to avoid SSPI altogether. however, i'm willing to entertain the possibility of adding it back under certain conditions if it proves valuable. o the new implementation attempts to negotiate the preferred NTLM2 session key mode whenever the server supports it. this improves security. o as with the previous SSPI based implementation, mozilla does not automatically send username, password, and domain (based on the user's WINNT logon) since we feel that that is a security risk. in a future version we may eliminate this restriction for proxy authentication.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Depends on: 224653
Resolution: --- → FIXED
Is there any possibility to disable NTLM authentification ? We have a lot trouble with bad configured MS-Webservers. These sites are not accessable since mozilla 1.3 because Mozilla now tries NTLM and fail. But basic authentification works well. sorry for commenting a fixed bug
d. oertel: please see bug 226456. with more recent builds of mozilla you can actually cancel the NTLM auth prompt, and then you will be presented with the Basic auth prompt. this allows users to get around bad NTLM servers. the downside is that we don't tell users that this is happening. our auth prompts don't inform them of the security level :(
showing the type of authentication in the dialog is bug 115500, btw
Keywords: relnote
No longer blocks: 164421
Blocks: 158464
No longer blocks: majorbugs
Isn't this, like, fixed long ago? It's marked as RESOLVED FIXED but apparently still active!

NTLM over http is using HTTP persistent connection or http keep-alive.

A single connection is created and then kept open for the rest of the session.

If using the same authenticated connection, it is not necessary to send the authentication headers anymore.

This is also the reason why NTLM doesn't work with certain proxy servers that don't support keep-alive connections.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: