453156 - NTLM / Integrated Windows authentication not working

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[RFLazaro]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080901033305 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080901033305 Minefield/3.1b1pre

NTLM / Integrated Windows authentication not working recently. 

Reproducible: Always

Steps to Reproduce:
1. Browse to any SharePoint sites
2.
3.
Actual Results:  
A page with the following message is shown:

You are not authorized to view this page
You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept.

Please try the following:
* Contact the Web site administrator if you believe you should be able to view this directory or page.
* Click the Refresh button to try again with different credentials.

HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration.
Internet Information Services (IIS)

Technical Information (for support personnel)
* Go to Microsoft Product Support Services and perform a title search for the words HTTP and 401.
* Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled About Security, Authentication, and About Custom Error Messages.


Expected Results:  
Page should display normally.

Comment 1

[RFLazaro]

I have narrowed it to the following builds

Works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080826034105 Minefield/3.1a2pre

Fails: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080828034823 Minefield/3.1a2pre

Comment 2

[RFLazaro]

This bug would also show in any "intranet" site that requires NTLM/integrated authentication.

This also happens in intranets that have proxies that require pass through authentication.

Comment 3

[RFLazaro]

WORKS: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre)
Gecko/20080826034105 Minefield/3.1a2pre

WORKS: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080827031643 Minefield/3.1a2pre

FAILS: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre)
Gecko/20080828034823 Minefield/3.1a2pre

Comment 4

[Alexander Kluss]

It's only the automaticly login at the proxy server brocken. If you disable the pref "network.automatic-ntlm-auth.allow-proxies" Mozilla show the login dialog and the login with your account works.

also fails:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080901231657 SeaMonkey/2.0a1pre (since Gecko 20080828....)

Comment 5

[RFLazaro]

I set the following but it's still failing; no login dialog either.

network.automatic-ntlm-auth.allow-proxies FALSE
network.ntlm.send-lm-response FALSE

Comment 6

[(mostly gone) XtC4UaLL [:xtc4uall]]

checkin range based on comment 3: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-27+01%3A00%3A00&enddate=2008-08-28+03%3A00%3A00

Comment 7

[Markus Milleder]

Most likely checkin from the range seems to be
9698ed0a3e43	Brian Crowder — Bug 418703 - reduce narrow Windows API calls in necko, original patch by Brad Lassey <[e-mail]>, r=biesi

This has hit me on Seamonkey/trunk with our NTLM authenticating proxy.

Comment 8

[RFLazaro]

Adding Brian Crowder to CC list.

Comment 9

[Dean Tessman]

I wonder if this is the same issue that I'm running into.  I can't browse to anything at work with the latest builds.  We have a corporate proxy, and what used to work seemlessly now results in a proxy authentication dialog for anything I try to do.  Entering the proper credentials doesn't get me past it.

If I use the LockoutStatus utility from Microsoft, I can see that the domain controller thinks I've entered a bad password everytime that I enter credentials into the proxy prompt.

I see the same regression window as comment #3, between 2008-08-27 and 2008-08-28.

Comment 10

[Brian Crowder]

Actually, I think it is the embedding patch (not necko) that broke this (same range, of course).

Comment 11

[RFLazaro]

Do you mean this checkin? http://hg.mozilla.org/mozilla-central/rev/73d8df3129ac

Comment 12

[Brian Crowder]

Yes.  At the very least, this cast is bogus:

   3.101 +        sn = (SEC_WCHAR *) mServiceName.get();

I'll have a patch coming up shortly.

Comment 13

[Brian Crowder]

Can those reporting troubles in this bug please try again with the build provided here:
https://build.mozilla.org/tryserver-builds/2008-09-03_13:[e-mail]-try-73b81a34bda/

Thanks

Comment 14

[Markus Milleder]

Works for me.
Thanks for the fast fix.

Comment 15

[RFLazaro]

Works for me. Hope to see it in the nightly build soon.

Comment 16

[Dean Tessman]

Confirming that the behavior I mentioned in comment #9 is also fixed.

Comment 17

[Brian Crowder]

Attachment: The fix

Comment 18

[Brian Crowder]

Benjamin:  I've fixed two string bugs and also repaired some broken spacing from the previous patch that I somehow managed not to fix before.

Comment 19

[Brian Crowder]

http://hg.mozilla.org/mozilla-central/rev/d78fa9eb3c9f