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: