If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Failover from automatic to built-in NTLM auth with MS-Proxy sometimes fails with Mozilla 1.7.5 / Firefox 1.0

NEW
Unassigned

Status

()

Core
Networking
P5
major
13 years ago
a month ago

People

(Reporter: Sianka, Unassigned)

Tracking

({helpwanted, regression})

Trunk
mozilla1.9alpha1
x86
Windows NT
helpwanted, regression
Points:
---
Bug Flags:
blocking1.7.6 -
blocking1.8b3 -
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact][ntlm] [necko-would-take])

(Reporter)

Description

13 years ago
Since Mozilla 1.7.5, I get the same old error than before with NTLM auth. See:
http://bugzilla.mozilla.org/show_bug.cgi?id=35159
There is no password prompt any more and I get an auth error 407.

It was working fine before.

A downgrade from Mozilla 1.7.5 to 1.7.3 fix the problem.

Updated

13 years ago
Component: General → Networking
Keywords: regression
Product: Mozilla Application Suite → Core

Updated

13 years ago
Assignee: general → darin
QA Contact: general → benc
Severity: blocker → major
(Reporter)

Comment 1

13 years ago
By the way, I have the same problem with Firefox 1.0

Comment 2

13 years ago
I am seeing different results with Firefox. The Mozilla Suite nightly fails but
the Firefox nightly works. Both are installed on the same system.

Mozilla Suite
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050112
Build ID: 2005011204
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050116
Build ID: 2005011605

Firefox
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050113 Firefox/1.0+
Confirming to make sure this gets some attention.... What landed on branch
between 1.7 and 1.7.5 that could have broken this?

Also, since this is broken on trunk, changing version field.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b?
Version: 1.7 Branch → Trunk

Comment 4

13 years ago
There was some sort of auth change made - darin?
should this block a 1.7.6? (sounds like...)
Flags: blocking1.7.6?

Updated

13 years ago
Flags: blocking1.7.6? → blocking1.7.6+

Comment 6

13 years ago
To anyone who can reproduce this problem:

Please try setting the pref "network.automatic-ntlm-auth.allow-proxies" to
false.  You can change this pref by loading about:config in the browser.

Also, it would help to know if anyone experiences this problem on platforms
other than Windows.

Thanks!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
(Reporter)

Comment 7

13 years ago
Hi

First thanks for your time and support.

I re-installed mozilla 1.7.5 release.
I reproduced the initial bug.
Then I set up "network.automatic-ntlm-auth.allow-proxies" to false as you suggested.
Now the browser is prompting for user/password the same way than with 1.7.3.

As far as I tested, it seems to work fine in this configuration.

Is automatic-ntlm-auth a new feature ?


Comment 8

13 years ago
> Is automatic-ntlm-auth a new feature ?

Yes, it is a new feature.  The intent is to first try using the built-in NTLM
module on your system (called Microsoft SSPI).  That module will attempt to use
your Windows logon as the NTLM credentials.  If it fails, then we _should_
failover to Mozilla's NTLM module, which means behaving like Moz 1.7.3, etc.  It
would seem that that failover code is not working properly in your case.

You could help me a great deal by restoring the default configuration, and then
capture a Mozilla HTTP log for me using these instructions:
http://www.mozilla.org/project/netlib/http/http-debugging.html

When you have the log file, please attach it to this bug report using the
"Create a New Attachment" link above.  Or, if you prefer you can send it to me
directly via email.

Thanks again!
Summary: NTLM Auth with MS-Proxy now failed with Mozilla 1.7.5 → automatic-ntlm auth with MS-Proxy sometimes fails with Mozilla 1.7.5 / Firefox 1.0
(Reporter)

Comment 9

13 years ago
> You could help me a great deal by restoring the default configuration, and then
> capture a Mozilla HTTP log for me using these instructions:
> http://www.mozilla.org/project/netlib/http/http-debugging.html

I get a 404 file not found error with this url

Comment 10

13 years ago
Typo, it is at http://www.mozilla.org/projects/netlib/http/http-debugging.html
(Reporter)

Comment 11

13 years ago
(In reply to comment #8)
> When you have the log file, please attach it to this bug report using the
> "Create a New Attachment" link above.  Or, if you prefer you can send it to me
> directly via email.

Done. I sent the log to you via email.

Comment 12

13 years ago
Thanks for the log file.

Here's some interesting bits from the log file:

247[76a1a0]: http response [
247[76a1a0]:   HTTP/1.1 407 Proxy Authentication Required ( The ISA Server
requires authorization to
247[76a1a0]:   Via: 1.1 PROXY
247[76a1a0]:   Proxy-Authenticate: NTLM
Kerberos
Negotiate
247[76a1a0]:   Pragma: no-cache
247[76a1a0]:   Cache-Control: no-cache
247[76a1a0]:   Content-Type: text/html
247[76a1a0]:   Content-Length: 3759
247[76a1a0]: ]
...
0[751e70]: nsHttpChannel::ProcessAuthentication [this=1fddad0 code=407]
0[751e70]: nsHttpChannel::GetAuthenticator [this=1fddad0]
0[751e70]: nsHttpChannel::GetCredentialsForChallenge [this=1fddad0 proxyAuth=1
challenges=NTLM]
0[751e70]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://172.16.252.5:8080
realm=]
0[751e70]: nsHttpNTLMAuth::ChallengeReceived
0[751e70]:   identity invalid = 0
0[751e70]: nsHttpNTLMAuth::GenerateCredentials
0[751e70]: nsHttpChannel::GetAuthenticator [this=1fddad0]
0[751e70]: nsHttpChannel::GetAuthenticator [this=1fddad0]
0[751e70]: nsHttpChannel::GetCredentialsForChallenge [this=1fddad0 proxyAuth=1
challenges=Negotiate]
0[751e70]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://172.16.252.5:8080
realm=]
0[751e70]: unable to authenticate
0[751e70]: ProcessAuthentication failed [rv=80004004]

What it tells me is that nsHttpNTLMAuth::GenerateCredentials is failing.  That's
interesting because normally it succeeds since it is just sending some flags at
this stage.

I believe we get confused by this error condition and then never re-try NTLM,
and hence we never failover to our built-in NTLM module.  So, it seems to me
that the user's system has a busted SSPI or something like that.  We should
probably failover immediately if SSPI ever fails to generate credentials. 
Summary: automatic-ntlm auth with MS-Proxy sometimes fails with Mozilla 1.7.5 / Firefox 1.0 → Failover from automatic to built-in NTLM auth with MS-Proxy sometimes fails with Mozilla 1.7.5 / Firefox 1.0

Updated

13 years ago
Flags: blocking1.8b? → blocking1.8b+

Comment 13

13 years ago
Darin, so do you think this is something important to fix for the upcoming 1.8
gecko releases?
Flags: blocking1.8b+ → blocking1.8b2?

Comment 14

13 years ago
yes, i think it is important for 1.8 beta (1 or 2)
No traction here, not going to wait for this fix.
Flags: blocking1.7.6+ → blocking1.7.6-

Updated

13 years ago
Priority: -- → P2
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2

Comment 16

13 years ago
Darin, are you going to be able to get at this in the next few days? We're
coming up fast on 1.8b2.

Updated

13 years ago
Flags: blocking1.8b3?
Flags: blocking1.8b2?
Flags: blocking1.8b2-

Updated

13 years ago
Flags: blocking1.8b4?
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking1.8b2-

Updated

12 years ago
Whiteboard: [no l10n impact]

Comment 17

12 years ago
I think this bug should remain on the radar for Gecko 1.8
Keywords: helpwanted
Target Milestone: mozilla1.8beta2 → mozilla1.8beta4

Updated

12 years ago
Flags: blocking1.8b4? → blocking1.8b4+

Updated

12 years ago
Flags: blocking1.8b4-
Flags: blocking1.8b4+
Flags: blocking-aviary1.5+

Updated

12 years ago
Flags: blocking-aviary1.5+

Updated

12 years ago
Target Milestone: mozilla1.8beta4 → mozilla1.9alpha
*** Bug 326045 has been marked as a duplicate of this bug. ***

Comment 19

11 years ago
-> reassign to default owner
Assignee: darin.moz → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking

Comment 20

4 years ago
Hello!

I am not sure, if i am right here (i am a newby here), but we have this issue with firefox v28 and the Blue Coat ProxySG as well. The problem is, that it does not occure all the time. Sometimes surfing works fine and sometimes the popup arrises. Of course with MS-IE everythink works fine. The strange thing ist, that on the configuration on the proxysgs nothing has changed and the NTLM worked fine with Firefox for a long time.

Does anyone have the same issiue with Firefox v28?

Best regards
Martin

Comment 21

4 years ago
(In reply to Martin Peinsipp from comment #20)
> Hello!
> 
> I am not sure, if i am right here (i am a newby here), but we have this
> issue with firefox v28 and the Blue Coat ProxySG as well. The problem is,
> that it does not occure all the time. Sometimes surfing works fine and
> sometimes the popup arrises. Of course with MS-IE everythink works fine. The
> strange thing ist, that on the configuration on the proxysgs nothing has
> changed and the NTLM worked fine with Firefox for a long time.
> 
> Does anyone have the same issiue with Firefox v28?
> 
> Best regards
> Martin

Hi!

I am sorry, i think this is the wrong threat.

martin
Whiteboard: [no l10n impact] → [no l10n impact][ntlm] [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P2 → P5
You need to log in before you can comment on or make changes to this bug.