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: