Closed Bug 231529 Opened 21 years ago Closed 20 years ago

Optionally enable unprompted NTLM authentication

Categories

(Core :: Networking: HTTP, enhancement)

Product:
Core
Component:
Networking: HTTP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: aquarius, Assigned: darin.moz)

References

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: [patch])

Attachments

(1 file, 1 obsolete file)

v1 patch
20.19 KB, patch
cneberg
: review+
bryner
: superreview+
mkaply
: approval-aviary+
mkaply
: approval1.7.5+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Mozilla should be able to optionally authenticate using NTLM to a server without
prompting the user for username and password with a dialog box (instead
retrieving that data from the client itself, similarly to Internet Explorer).
Given the security issues surrounding this, it should be limited in some way,
either by not being the default, or by only occurring to a set IP range, or some
similar method. This would enable "seamless logins", which is a popular
technique in enclosed intranet environments.

Reproducible: Always

Steps to Reproduce:
Status: UNCONFIRMED → NEW
Ever confirmed: true
see bug 199644 comment 9 for Darin's comments on this.
I agree that it's a complex issue to determine "what lies within the intranet".
A suggestion: since this feature is pretty much only requested by people who
want to use it for intranets, i.e., in a closed environment where there is
control over browser installations on people's machines, why not only do
automatic NTLM authentication to a specific list of IPs which must be
configured? A corporate (or similar) environment will be able to roll out new
browser profiles containing the specific IPs and manage them without any major
problems, and ordinary users outside that sort of environment will not be
affected because they won't have specifically configured any IPs. An extension
of this would be to not offer UI asking a user to "remember their Windows
credentials for this website" or similar, at least for an initial release; if
the list can only be manually configured (but the method for configuring is
well-documented) then it may well keep the target market happy without requiring
significant work other than in the authentication process itself.
A big part of the problem w/ duplicating IE is that their definition of the
intranet is pretty vague.
Depends on: 169106
From my very limited understanding of this issue, we have a problem here that
windows isn't just about to hand over the password to any user-level application.

Instead, I think this requires going back and using SSPI, and all the fun&games
that that represents.  (It is however the most accurate NTLMSSP implementation
available)

Support for 'seamless' logins is indeed a strong 'IE replacement' requirement,
even at sites as freindly as my own (where I could mandate Mozilla, if it were
not for these issues)

Andrew Bartlett
Samba Team
We have the same exact problem on all platforms.  What I'd like to see happen is
for Mozilla to provide a cross-platform "seamless" logon mechanism.

Issues:

1) Windows users don't expect to ever be prompted for their Windows logon. 
Unless we use NTLMSSP, we'd have to prompt at least once.

2) NTLMSSP crashes on some older systems.  We dropped using NTLMSSP to avoid
these crashes.

3) NTLMSSP uses the weaker hash on Win9x (LMv1 only).  With our own code, we can
provide the better version on all Windows platforms (NTLM2 Session Hash if
supported by the server).

4) When the negotiate auth component is completed, that will hopefully be the
authentication scheme of choice since it'll offer better password authentication
and "seamless" logon.

Given the issues we've had with NTLMSSP, I really don't want to go back to using
it.  I think we could get by with other solutions.  For example, we could have
preferences UI to allow the user to enter their windows logon into Mozilla.  We
could also have preferences UI for the user to specify which domains support
automatic logon.  Maybe something like this would get us close enough.
*** Bug 237589 has been marked as a duplicate of this bug. ***
In the comments the automated logon is desired only in internet.

Our proxy requires NTLM authentification, I will not explain our
users why they have to logon twice (Windows AND Mozilla).
We try to setup a single login mechanismus, so we would need this
feature for every site and not just only for the internet.

I could live with a stored (and encypted) user name and password
in some configuration file.

I hope this issue makes it into a stable version.
Thanks, CL
Sorry - mistype: automated logon not only in INTRANET:
------------------------------------------------------

In the comments the automated logon is desired only in intranet.

Our proxy requires NTLM authentification, I will not explain our
users why they have to logon twice (Windows AND Mozilla).
We try to setup a single login mechanismus, so we would need this
feature for every site and not just only for the intranet.

I could live with a stored (and encypted) user name and password
in some configuration file.

I hope this issue makes it into a stable version.
Thanks, CL
I agree with most of the comments here--to summarize, I think these are the
basic needs:

1) Administrators need to be able to create "pre-approved" or "exclusively
approved" sites--perhaps with wildcards, such as "*.mozilla.org" or "12.13.14.*"
(and perhaps requiring HTTPS to be used) for their less-savy browser users.
2) Users need to be able to designate sites as "approved" for auto-login
3) The username and password need to be grabbed dynamically from the platform's
login information.

Implementation ideas: perhaps by popping up a "This site is requesting your
network login credentials" dialog with [Send Username/Password] [Don't Send]
[Log in as another user] buttons and a []Add this site to my approved list
checkbox. For added customization, there might be a new option in the Privacy
area for "When promted for an NTLM login..." ( ) Always prompt ( ) Send login
info for approved sites ( ) Require user-typed username and password, with
"Always Prompt" as the default, but allowing Admins to switch it to switch it to
"Send login info to approved sites"
(In reply to comment #5)
> 2) NTLMSSP crashes on some older systems.  We dropped using NTLMSSP to avoid
> these crashes.
> ...
> Given the issues we've had with NTLMSSP, I really don't want to go back to using
> it.  I think we could get by with other solutions.  For example, we could have
> preferences UI to allow the user to enter their windows logon into Mozilla. We
> could also have preferences UI for the user to specify which domains support
> automatic logon.  Maybe something like this would get us close enough.

What did IE use on those older systems to provide seamless login to IIS-based
servers? Something other than NTLMSSP? Or did NTLMSSP just crash sometimes and
they didn't mind? Adding Windows username and password to preferences wouldn't
cover the seamless issue, because users would have to enter that manually (and
change it once a month, too, under a password aging policy), and that
contravenes their current user experience (and your point about Windows users
not expecting to be asked for their password). I appreciate that I'm not helping
offer a solution here, I'm just trying to more clearly define my original issue:
that users with IE can be seamlessly logged in to intranets, and it prevents
organisations from switching to Mozilla. 
This is a big issue for those using Microsoft's ISA server (ugh...but not my
decision). It can't be expected that people type in their user/password and have
to click OK everytime they start the browser (even if they clicked to save the
password).

Would it be possible to implement NTLMSSP for at least the specified proxy
server? Even if it was just available on NT based platforms for stability. I'm
quite ignorant of NTLMSSP so I apologize in advance if I don't know what I'm
talking about. 

This is a major stumbling block to rolling out Mozilla in my company, although
the boss is interested, the proxy thing is a problem.
I hate 'me too' responses, but this is also the blocker for deployment at my site.  

As you can see by my e-mail address, I'm not exactly a fan of MS, and I don't
even use IIS!  But I use Samba/Winbind/ntlm_auth/Squid as a transparent
authentication system for internet access.

The SSPI code for hooking this in exists, it even appears to be the choice for
POP3/IMAP, from the latest release notes, and it has been used for HTTP in the past.

What I ask is that there is a choice - that users/administrators may select to
use SSPI ('use my system login credentials') or mozilla's internal credentials. 

BTW, this bug has almost exactly the same goals as #237586 and perhaps should be
meged there.  Use of bare NTLM should be a special case in that patch, I think

Andrew Bartlett
> The SSPI code for hooking this in exists, it even appears to be the choice for
> POP3/IMAP, from the latest release notes, and it has been used for HTTP in the
past.

No, that was a mistake in the release notes.


> What I ask is that there is a choice - that users/administrators may select to
> use SSPI ('use my system login credentials') or mozilla's internal credentials. 

Yes, I agree that a choice would be ideal.

Here's some issues to keep in mind:

(1) Using SSPI has known crashers in Mozilla that lie deep inside SECUR32.DLL
that we have very little way of fixing.

(2) Mozilla would need to implement a security zones system similar to IE in
order to know when it is safe to respond automatically with default credentials.

(3) Using the default NTLMSSP implementation may result in weaker NTLM
authentication for Win9x users.

(4) Once we implement NegotiateAuth under Win32, we will support Kerberos if
available on client systems, and we will do so using SSPI.  Kerberos provides a
much better single-signon system than NTLM.  We still have a need for security
zones with Kerberos, but at least we don't have to deal with user passwords, etc.
> What did IE use on those older systems to provide seamless login to IIS-based
> servers? Something other than NTLMSSP?

Based on packet traces, I do not believe that IE uses SSPI to provide NTLMSSP. 
I could be wrong, but no matter what combination of flags I used, I could not
get Mozilla to produce the same traffic as IE.  Hence, I believe that IE has
some internal implementation or maybe IE is using some private Win32 API.
Does anyone know of a Microsoft API that provides a user's logon?  Surely there
must be some API that can be used to query that information.
(In reply to comment #13)

--snip--
> (4) Once we implement NegotiateAuth under Win32, we will support Kerberos if
> available on client systems, and we will do so using SSPI.  Kerberos provides a
> much better single-signon system than NTLM.  We still have a need for security
> zones with Kerberos, but at least we don't have to deal with user passwords, etc.
--snip--

So if I understand this correctly, when NegotiateAuth is implemented, if your
login is using Kerberos (anything Active Directory based, correct?) no password
dialog will be displayed, at least for sites in a trusted zone. That sounds
great if thats what is going to happen. Is this a (Firefox) 1.0 timeframe thing,
or more of a "when it gets done" timeframe?

*** Bug 249112 has been marked as a duplicate of this bug. ***
(In reply to comment #13)

I'm rather worried about the implication of this comment.  Does this mean that
this bug really should be marked WONTFIX, because there is not intention to
provide this with NTLM?

NTLMSSP is a dog.  I know, particulary as I'm forced to develop client and
server implementations of it.  However, even in sites that *think* they are
running 'Active Directory', very few actually use Kerberos.  

Due to the way Microsoft clients 'fall back' to NTLM/NTLMSSP, many corperate
networks simply do not funciton with Kerberos logins.  This is certainly our
experience with Samba.

Finally, not all sites run Active Directory - and while I have no particular
affection for those who run NT4, I run an all-Samba site, and for the timebeing,
we *cannot* support kerberos.  That said, I need NTLM logins into my proxy
server (squid/ntlm_auth/winbindd), or some other *automatic* and not-plaintext
way to identify my users.

Andrew Bartlett
Samba Team
> So if I understand this correctly, when NegotiateAuth is implemented, if your
> login is using Kerberos (anything Active Directory based, correct?) no 
> password dialog will be displayed, at least for sites in a trusted zone. That
> sounds

yes


> great if thats what is going to happen. Is this a (Firefox) 1.0 timeframe 
> thing, or more of a "when it gets done" timeframe?

i'm hoping for firefox 1.0, but don't count on it.


also, it looks like it may be possible to extract the user logon credentials
using Win32 APIs.  I'll have to play around with those some more, but if that
proves to be possible, then we may in fact be able to support a security model
in which we automatically send user credentials via NTLM for certain domains
("intranet" domainl -- however that is defined!)
> I'm rather worried about the implication of this comment.  Does this mean that
> this bug really should be marked WONTFIX, because there is not intention to
> provide this with NTLM?

no.. i just don't want to be sloppy about how we implement this feature. 
remember that NTLM v1 is easy to crack.  (and servers get to tell the browser
that they want NTLM v1.)  if i give out user credentials to a hacker, then he
has the opportunity to impersonate a user.  that means we have to be very careful.


> Due to the way Microsoft clients 'fall back' to NTLM/NTLMSSP, many corperate
> networks simply do not funciton with Kerberos logins.  This is certainly our
> experience with Samba.

kerberos is very very sensitive to clock skew, and yes.. it seems very likely
that failover to NTLM would happen regularly and go unnoticed.  unfortunate.


> server (squid/ntlm_auth/winbindd), or some other *automatic* and not-plaintext
> way to identify my users.

in the case of proxy servers, i think we may be able to be much more aggressive
about handing out the default windows logon via NTLM to proxy servers.  this is
because there is no way for an evil website to change the browser's proxy server
configuration or fake a 407.  we have security measures in place that prevent
the browser from acting on a 407 that is generated in response to a non-proxy
browser request.  and we also do not support the 305 directive.  this means that
we could solve the problem of automatic logon to proxy servers much more easily.
i presume that squid does not forward 407's to the browser :-)
> also, it looks like it may be possible to extract the user logon credentials
> using Win32 APIs.

I spoke prematurely.  I know how to get the "domain\user", but I haven't figured
out how to get the current user's password yet.  I'm sure there is logic in
making it hard or impossible to extract the user's password from the system.

Perhaps the only solution is to enable NTLMSSP optionally or via SPNEGO only.
> Perhaps the only solution is to enable NTLMSSP optionally or via SPNEGO only.

My patch for bug 237586 implements the latter.  I've tested it against Win2k3,
and I'm able to login silently using either Kerberos or NTLM via SPNEGO
(Negotiate).  If those fail, then I am prompted to enter my domain\username and
password, and Mozilla uses its NTLM implementation to authenticate me.

Since we limit SPNEGO to a trusted set of domains, this solution seems
reasonable.  We have the advantage of using the stronger version of NTLM on the
world-wild-web, provided servers support it, and we get single signon in
intranets, provided Mozilla has been properly configured.
Re: comment #21

Last time it was possible to get access to a user's passwords in Win9X, it was
considered a security bug, and patched.  (This was by digging around in memory,
and the solution was to store only the 'hashed' versions of the passwords).

It may be possible to gain these hashes (and that's all we need for NTLMSSP),
but I suspect MS doesn't make it easy...   

Re: comment #22

This sounds like a workable solution, except that current Squid only supports
NTLM, not Negotiate.  Now, I'm actually working to fix that, but we have a
supprisingly large deployment of Squid/NTLM/winbind sites out there, as well as
older MS proxy servers not setup for Active Directory (and therefore not having
SPNEGO).


> This sounds like a workable solution, except that current Squid only supports
> NTLM, not Negotiate.

That's unfortunate :-(


> Now, I'm actually working to fix that, but

Good to hear.


Again, I am concerned about the crashes we observed as a result of using SSPI
directly for NTLM in Mozilla 1.4.  It is possible that the crashes only occured
when we passed domain/username/password to SSPI.  (I suspect that older versions
of SSPI might not copy the contents of the domain/username/password buffers,
which might explain the crashes we saw on Win9x boxes.)  So, perhaps we should
try to use SSPI on Win32 as much as possible.... and maybe only failover to our
NTLM implementation when we are forced to prompt the user.  Or, maybe we should
just always use SSPI on Win32 and hope that I'm right about the cause of those
crashes.  It is incredibly painful to debug crashes that occur in a
closed-source system library! :-(
I feel your pain.  It's hard enough working with this stuff when you have all
the sources...

On copying the username/password, it would appear that at least some examples do
this:

http://win32.mvps.org/security/client.cpp

On what NTLM we should be using, I increasingly feel this should be the admin's
choice:
 - I would suggest that the default on Win9X and non-Windows platforms should be
the internal one
 - Where we want to do an autoloign, we have no choice but to do SSPI
 - Where we specify the password, the internal mech can handle it well, and not
leak the LM password.
 - Where the system is so configured, the SSPI mech could do fully accurate
NTLMv2, per the group (system) policy, which is not currently in the internal
mech (I understand).

The only thing that bothers me about NLTM from SSPI is the tendency to send the
LM password hash anyway, but it's still better than plaintext...
*** Bug 244028 has been marked as a duplicate of this bug. ***
Blocks: 250014
> On what NTLM we should be using, I increasingly feel this should be the admin's
> choice:
>  - I would suggest that the default on Win9X and non-Windows platforms should be
> the internal one

This sounds like a good plan.  we could also check the SSPI library version number.


>  - Where we want to do an autoloign, we have no choice but to do SSPI

If we are using the internal mech for Win9X clients, then are you also
suggesting that we disable autologin for Win9X clients?


>  - Where we specify the password, the internal mech can handle it well, and not
> leak the LM password.

Our internal mech will leak the LM password if the server requests the LM hash.   


>  - Where the system is so configured, the SSPI mech could do fully accurate
> NTLMv2, per the group (system) policy, which is not currently in the internal
> mech (I understand).

Right, we support NTLMv1/LMv1 and NTLM2 Session Key, which can be negotiated. 
We do not support NTLMv2/LMv2 since there is no way to negotiate that AFAIK.
Samba winbindd appears to negotiate NTLM2 Session Key, so by default Mozilla
does not send the LMv1 hash when talking to squid+winbindd.


> The only thing that bothers me about NLTM from SSPI is the tendency to send the
> LM password hash anyway, but it's still better than plaintext...

Should our internal mech never send a LMv1 hash?  When the server does not
support NTLM2 Session Key, should we only send a NTLMv1 hash?  I was under the
impression that that could lead to incompatibilities with older domain servers.

I agree that we should make as much of this configurable on the Mozilla side as
possible.
>>  - Where we want to do an autoloign, we have no choice but to do SSPI
>
> If we are using the internal mech for Win9X clients, then are you also
> suggesting that we disable autologin for Win9X clients?

Hmm... I suppose I forgot that people still use Win9X, and still use it in a 
'domain'.  I just don't like the LM-only thing for automatic authentication... 

>>  - Where we specify the password, the internal mech can handle it well, and 
>>  not leak the LM password.

> Our internal mech will leak the LM password if the server requests the LM 
> hash.   

I think that's bad.

>>  - Where the system is so configured, the SSPI mech could do fully accurate
>> NTLMv2, per the group (system) policy, which is not currently in the internal
>> mech (I understand).

> Right, we support NTLMv1/LMv1 and NTLM2 Session Key, which can be negotiated. 
> We do not support NTLMv2/LMv2 since there is no way to negotiate that AFAIK.
> Samba winbindd appears to negotiate NTLM2 Session Key, so by default Mozilla
> does not send the LMv1 hash when talking to squid+winbindd.

That's great!  I really should read more of the source code...

>> The only thing that bothers me about NLTM from SSPI is the tendency to send
>> the LM password hash anyway, but it's still better than plaintext...

> Should our internal mech never send a LMv1 hash?  When the server does not
> support NTLM2 Session Key, should we only send a NTLMv1 hash?  I was under the
> impression that that could lead to incompatibilities with older domain 
> servers.

Not really.  For a site to only have an LM password on record means that they:
 - Cannot use NTLM2, and must have specificly configured all member servers, 
   and proxies etc not to negotiate use of it

 - Must have changed that user's password from a Win95 machine, with a
   particularly old password change call.
or
 - Must never have changed that password since running 'Lan Manager' 10 years
ago (or for Samba PDCs, since running a very old version of Samba).

I think it's safe to assume the presence of the NT password hash.

> I agree that we should make as much of this configurable on the Mozilla side
> as possible.

Of course, we can always add an option to send the LM response :-)
Attached patch v0 patch (obsolete) — — Splinter Review 
This is an incomplete patch.  It provides support for using the operating
system's NTLM package in response to "Proxy-Authenticate: NTLM"

More work is needed to use it in response to "WWW-Authenticate: NTLM"

Specifically, I'd like to implement a whitelist of allowed URIs similar to the
one implemented for SPNEGO.

I have not yet tested this patch.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
Attached patch v1 patch — — Splinter Review 
Finalized and tested patch.

This patch introduces the following preferences:

  network.automatic-ntlm-auth.allow-proxies
  network.automatic-ntlm-auth.trusted-uris

allow-proxied defaults to true, and trusted-uris defaults to the empty string. 
trusted-uris works just like network.negotiate-auth.trusted-uris.

I plan on documenting these preferences on
http://www.mozilla.org/projects/netlib/integrated-auth.html
Attachment #153446 - Attachment is obsolete: true
Attachment #154669 - Flags: review?(cneberg)
Whiteboard: [patch]
I'll have time to look at this today.
One option we need in both Negotiate and NTLM is the ability to disable
auto-login  as a bool pref. (I'm not sure if NTLM needs a seperate pref from
Negotiate or if they should just share one.)

The reason for this is I have several test accounts which I want to switch to,
and  the current set up I have to delete all or part of my list of trusted sites
just to disable it for a few minutes.  I would be easier (and makes sense in the
GUI I'm designing in another bug) to be able disable it temporarly without the
data loss that is caused by forcing the user to delete the list of sites.
> One option we need in both Negotiate and NTLM is the ability to disable
> auto-login  as a bool pref.

good idea.  can you file a new bug for this?  we should do it as a separate
patch.  reference your comments here in that new bug.  thx!
Comment on attachment 154669 [details] [diff] [review]
v1 patch

Looks and works fine.
Attachment #154669 - Flags: review?(cneberg) → review+
Attachment #154669 - Flags: superreview?(bryner)
Sorry for the newbie question...but does the fact that a patch is now available
mean that this will end up in the AVIARY_1_0_20040515_BRANCH, and as such the
nightly firefox branch builds??

Thanks.
> Sorry for the newbie question...but does the fact that a patch is now available
> mean that this will end up in the AVIARY_1_0_20040515_BRANCH, and as such the
> nightly firefox branch builds??

It is my intention to try to get this patch into the Aviary 1.0 branch, but
first we need to get it onto the Mozilla trunk.  Then we have to get the Aviary
drivers to approve this patch for their branch.
Comment on attachment 154669 [details] [diff] [review]
v1 patch

>+static NS_METHOD
>+nsNegotiateAuthConstructor(nsISupports *outer, REFNSIID iid, void **result)
>+{
>+  if (outer)
>+    return NS_ERROR_NO_AGGREGATION;
>+
>+  nsNegotiateAuth *auth = new nsNegotiateAuth();
>+  if (!auth)
>+    return NS_ERROR_OUT_OF_MEMORY;
>+  
>+  NS_ADDREF(auth);
>+  nsresult rv = auth->QueryInterface(iid, result);
>+  NS_RELEASE(auth);
>+  return rv;
>+}
>+

change this to NS_GENERIC_FACTORY_CONSTRUCTOR


>--- extensions/negotiateauth/nsNegotiateAuthSSPI.cpp	9 Jul 2004 21:59:09 -0000	1.1
>+++ extensions/negotiateauth/nsNegotiateAuthSSPI.cpp	29 Jul 2004 17:41:31 -0000
>-    rv = MakeSN(serviceName, mServiceName);
>-    if (NS_FAILED(rv))
>-        return rv;
>-    mServiceFlags = serviceFlags;
>+    char *package;

const char*  (or SEC_CHAR*, maybe?)
Attachment #154669 - Flags: superreview?(bryner) → superreview+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 154669 [details] [diff] [review]
v1 patch

requesting approval to land this on the stable branches to keep the
authentication support in sync with the trunk.	the patch has isolated impact
on the product.
Attachment #154669 - Flags: approval1.7.3?
Attachment #154669 - Flags: approval-aviary?
Flags: blocking-aviary1.0?
Comment on attachment 154669 [details] [diff] [review]
v1 patch

a=mkaply for 1.7.3 and aviary.
Attachment #154669 - Flags: approval1.7.3?
Attachment #154669 - Flags: approval1.7.3+
Attachment #154669 - Flags: approval-aviary?
Attachment #154669 - Flags: approval-aviary+
fixed-aviary1.0
Keywords: fixed-aviary1.0
fixed1.7.3
Keywords: fixed1.7.3
Does this code change the behavior of Linux Firefox builds when talking to NTLM
servers?
(In reply to comment #43)
> Does this code change the behavior of Linux Firefox builds when talking to NTLM
> servers?

No, it should have no affect on non-Win32 builds.
Flags: blocking-aviary1.0?
Maybe I'm missing something here, but I just upgraded to Firefox 1.0PR and with
the network-automatic-ntlm-auth.allow-proxies value set to the default (TRUE), I
get the opposite behavior: multiple NTLM pop ups instead of none. Only by
setting the value to false can I get some peace. 
http://bugzilla.mozilla.org/show_bug.cgi?id=259826
Aha. My problem must be because I am authenticating to the proxy server with
different credentials than I am logged in with on my machine. This is because my
computer is not part of the domain; I log in with a local account and then use
domain credentials explicitly whenever I need to. I can just turn the allow
proxy setting off. But in this case it is not possible to have completely silent
NLTM. 

IE doesn't have that problem though. I wonder how it does it.
I'm not sure what is going on here.  I just installed 2004110305 and find that
this just isn't working properly.  I'm logged into the domain and have manual
proxies set.  It doesn't seem to matter whether I have
network-automatic-ntlm-auth.allow-proxies value set to the default (TRUE) or to
(FALSE).

In one case I get a pop-up dialog box asking for account and password
information.  If I enter account and password information, I can get into one
webpage.  However in other instances I get no pop-up dialog box and simply see
an access denied come up on the screen.

George
Well, after doing a great deal more headbanging and testing, it's time for me to
eat some crow regarding my earlier comment (#47).  It would appear that the
reason for the allegedly erroneous and erratic authentication behavior was that
I had incorrectly entered the proxy exceptions using the same generic format
*.*.xxx.xxx that we use as a standard for IE.

What gave me the clue that it was a proxy exception problem was that in the 1st
example, when I got the dialog box, entered the user & pwd info, I got into the
appropriate intranet site.  I noticed that in the 2nd instance, when no dialog
box popped up and I just got an access denied message, I did some more testing
and finally realized that that "access denied" message was coming from one of
our firewalls.  Since I was trying to access another intranet site, nothing
should have been directed to a firewall.

Anyway, once I changed the proxy exception to read xxx.xxx, NTLM authentication
began behaving properly.  I'll continue testing to see if any other issues occur.

Sorry about the red herring.

George
*** Bug 271725 has been marked as a duplicate of this bug. ***
*** Bug 237790 has been marked as a duplicate of this bug. ***
*No wildcard support
*No full DNS resolving

Network.automatic-ntlm-auth.trusted-uris="domain.org"

A. If accessing http://portal in Intranet no auth.
B. I have to do http://portal.domain.org. FF should be able to resolve with A

Also would not be a problem if it allowed wildcards like this 10.*.*.*
I wish I could use wildcards, e.g.:
example.* would work for:
example.com, example.net, example.org
Is passwordless NTLM authentication (single sign on) available on Linux and Mac?

Kerberos works fine but NTLM doesn't seem to work. I opened a separate bug report since even after hours of searching I couldn't find this one. 

You can find it here:

https://bugzilla.mozilla.org/show_bug.cgi?id=645806

It would be great to understand wether this feature is not available on Linux / Mac or it is a configuration issue.
The big show stopper here in not being able to push this into corporate environment is that it's currently impossible to emulate IE's definition of 'intranet' (ie do the auth) which is a is a bare hostname (without domain).  

So in IE http://intranet/ is considered as an intranet site, whereas http://intranet.ourdomain.local/ isn't.  

Recently <local> (meaning any site that's not FQDN) was added as an option in the proxy auth part of Firefox, and really should be added here as well for trusted-uris with both NTLMauth and NegotiateAuth like this:

network.automatic-ntlm-auth.trusted-uris     <local>
network.negotiate-auth.trusted-uris          <local>
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: