Closed Bug 453156 Opened 13 years ago Closed 13 years ago

NTLM / Integrated Windows authentication not working

Categories

(Core :: Networking, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: rflazaro, Assigned: crowderbt)

References

Details

Attachments

(1 file)

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.
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
Component: General → Networking
Product: Firefox → Core
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.
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
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....)
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
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 <blassey@mozilla.com>, r=biesi

This has hit me on Seamonkey/trunk with our NTLM authenticating proxy.
Adding Brian Crowder to CC list.
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.
Assignee: nobody → crowder
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually, I think it is the embedding patch (not necko) that broke this (same range, of course).
Do you mean this checkin? http://hg.mozilla.org/mozilla-central/rev/73d8df3129ac
Yes.  At the very least, this cast is bogus:

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

I'll have a patch coming up shortly.
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:40-bcrowder@mozilla.com-try-73b81a34bda/

Thanks
Works for me.
Thanks for the fast fix.
Works for me. Hope to see it in the nightly build soon.
Confirming that the behavior I mentioned in comment #9 is also fixed.
Attached patch The fixSplinter Review
Attachment #336860 - Flags: superreview?(benjamin)
Attachment #336860 - Flags: review?(benjamin)
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.
Blocks: 422772
Flags: in-litmus?
Attachment #336860 - Flags: superreview?(benjamin)
Attachment #336860 - Flags: superreview+
Attachment #336860 - Flags: review?(benjamin)
Attachment #336860 - Flags: review+
http://hg.mozilla.org/mozilla-central/rev/d78fa9eb3c9f
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.