New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 14206 link

Starred by 23 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Oct 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

NTLM authentication using NTLMv2 not working in Google Chrome v2.0 and newer

Reported by tomas.ro...@gmail.com, Jun 16 2009

Issue description

Chrome Version       : any 2.0 version
URLs (if applicable) : any
Other browsers tested:
  Firefox 3.x: OK

What steps will reproduce the problem?
1. be behind ISA proxy requiring NTLM authentication
2. try to navigate to any website

What is the expected result?
In Chrome v1.0 and older, once the user provides username and password via modal dialog, the 
website is shown (= Chrome correctly authenticates the user at the proxy)

What happens instead?
As of v2.0, the username/password dialog keeps showing up ad infinitum (= Chrome is unable to correctly authenticate the user at the proxy)

I have tested following versions of Chrome and Chromium, with following authentication results:
0.2.149.30	NTLM authentication works
1.0.154.48	NTLM authentication works
1.0.154.65	NTLM authentication works
2.0.156.1	NTLM authentication doesn't work at all
2.0.157.0	NTLM authentication doesn't work at all
2.0.159.0	NTLM authentication doesn't work at all
2.0.160.0	NTLM authentication doesn't work at all
2.0.160.2	NTLM authentication doesn't work at all
2.0.164.0	NTLM authentication doesn't work at all
2.0.166.1	NTLM authentication doesn't work at all
2.0.167.0	NTLM authentication doesn't work at all
2.0.168.0	keeps asking for credentials ad infinitum
2.0.169.0	keeps asking for credentials ad infinitum
2.0.169.1	keeps asking for credentials ad infinitum
2.0.172.23	keeps asking for credentials ad infinitum
2.0.172.30	keeps asking for credentials ad infinitum
chromium build 17184	keeps asking for credentials ad infinitum
chromium build 18514	keeps asking for credentials ad infinitum

Attaching samples of HTTP streams dumped by Wireshark for Chrome 1.0.154.48 (authentication successful), Chrome 2.0.172.30 (authentication unsuccessful) and Chromium build 18514 
(authentication also unsuccessful).
 
2.0.172.30_authentication.dat
12.4 KB View Download
1.0.154.48_authentication.dat
50.6 KB View Download
18514_authentication.dat
19.4 KB View Download

Comment 2 by wtc@chromium.org, Jun 17 2009

tomas: thanks a lot for the bug reports and Wireshark HTTP stream dumps.

In Chrome 2.0, the HTTP code has been rewritten.  So this explains the
change of behavior in Chrome 2.0 that you observed.

In the username/password dialog, you need to enter "DOMAIN\user" in
the "User Name" field.  If you only enter "user" in the "User Name"
field, the NT domain will be missing and could lead to authentication
failure.  Please try entering "Domain\user" and let me know if that
helps.
Hi, I'm entering the username in DOMAIN\user form in the User Name field all the time 
(also when I did the dumps), unfortunately it doesn't help.

Comment 4 by wtc@chromium.org, Jun 17 2009

tomas: could you please try this experiment?  Thanks.

1. In Firefox, type "about:config" in the location bar.

2. In the "about:config" page, type "ntlm" in the Filter field.

3. Change the value of "network.automatic-ntlm-auth.allow-proxies"
from "true" (the default value) to "false".

4. Shut down and restart Firefox.  Does it still work with your
ISA proxy?
Hi, when I change network.automatic-ntlm-auth.allow-proxies to false in Firefox, it 
no longer works with my ISA proxy - FF shows the same user/pass dialog as Chrome and 
keeps raising it, just like Chrome 2.0

Comment 6 by wtc@chromium.org, Jun 17 2009

Status: Untriaged
tomas: thanks.  Firefox has two NTLM implementations.  We copied one
of them, which Firefox uses when network.automatic-ntlm-auth.allow-proxies
is false.  This implementation doesn't support NTLMv2.  Perhaps your ISA
proxy requires NTLMv2.  I will need to add some logging code and ask you
to run it to verify this hypothesis.  Because of another project and an
upcoming vacation, I may not be able to do that until mid-July.

If the lack of NTLMv2 is the problem, this bug will be fixed when we
fix  issue 19  (which will add a second NTLM implementation equivalent to
Firefox's other implementation that works with your ISA proxy).
OK, np, I can do some testing if needed. Thx
Just to add a different situation to your mix for testing:

I dont use any proxy server.
I am going straight from Chrome to my Apache w/mod_sspi 1.04  (on two different machines)
I just updated to Chrome 2.0.172.33 (after having abandoned earlier versions because
of lack of NTLM)
NTLM auth does not work, even if using  Domain\user format.
Apache error log displays error:

(OS 87) The parameter is incorrect. : authentication failure for "/url/here": user
unknown, reason: cannot generate context, referer: "/cur/url/here"

Both machines are XPSP3 (client is Pro, other is Home).
 I believe NTLMv2 is the only game to use.
If you want a tester, be happy to.
Till then goodbye Chrome (except for gmail)
BTW - the situation works under Firefox (since 1.5+) and of course IE

Comment 9 by wtc@chromium.org, Jun 24 2009

ahujachanderm: thanks for your comments.  I'd appreciate it if you could
try the following experiment.  (This is a variant of the experiment I asked
tomas to try in comment 4.)

1. In Firefox, type "about:config" in the location bar.

2. In the "about:config" page, type "ntlm" in the Filter field.

3. Does the value of "network.automatic-ntlm-auth.trusted-uris"
include your Apache server?

If it does, change the value of "network.automatic-ntlm-auth.trusted-uris"
to an empty string.

4. Shut down and restart Firefox.  Does it still work with your
Apache server?

Thank you for your help.

Comment 10 by Deleted ...@, Jun 25 2009

Hi,

We are seeing the same thing with our Ironport WSA proxy. Even if the user types in their credential correctly, 
it will not authenticate. 

To get Firefox to work we put Webgate,Webgate2,Webgate3 in the network.automatic-ntlm-auth.trusted-uris 
section. We do not put the fqdn in there and it works fine. Obviously these at the names of our proxies.

We are happy to do the same with Chrome if that makes the fix quicker :-)

Best wishes

Michael

Hi,
Checked the Firefox NTLM config settings as requested.

- for the one ending in  "-uris"  the status is "default", Type is "string" value is
empty (blank)
just fyi:
all the rest are "default" status and Type is "boolean".
"...-allow-proxies" value is "true"
"...-lm-response" value is "false"

Also fyi -
 apache server is intranet and a version of app runs under IIS which is reachable
from Internet - both work / have worked (last 4 yrs) with browsers default (out of
the box) settings except for the incorrigible IE where the "Authentication" setting
has to be set and reset for it to take effect and stop prompting users when on a
local (same machine) server setup (else it wont even authenticate!!) plus of course
IE has to be "taught" that the server is on the Intranet.

The difference between IE and Firefox in this scene (local machine server) is that
with Firefox - i dont have to enter the password (windows+sspi(iis) seems to do the
magic behind the scene) and with IE i can get it to not even prompt me (assuming i
did the authentication set and reset trick properly).
 When server is non-local (apache or IIS) both browsers require username and password
to be entered - which is as desired.

Hope the extra info is of some use...

Let me know if there is any other setting i can check / test to run. 

-chander

Comment 12 by wtc@chromium.org, Jun 26 2009

ahujachanderm: thanks for the info.  The empty value of
"network.automatic-ntlm-auth.trusted-uris" is not what I
expected, so I don't know what caused the NTLM authentication
problem with your Apache server.

Did you configure Firefox to use your Apache server as a
proxy by any chance?
wtc wrote:
 Did you configure Firefox to use your Apache server as a
proxy by any chance?

Ans:
  No. No proxies of any kind. 

I just dont think Chrome is doing NTLMv2 but of course you have indicated that...

i just threw in my scenario, because everyone else's NTLM problems seemed to include
proxy usage of some kind, but i didnt want y'all to forget about those of us that
dont have or need a proxy - which is most often the case on an Intranet (i.e.
Corporate acceptance of any browser will be decided by its Intranet capabilities)

I believe i'm having a similar problem with version 3:
http://code.google.com/p/chromium/issues/detail?id=19474

Basically, ntlm failed for me in version 2, but now (badly) works in version 3. Where 
you say "keeps asking for credentials ad infinitum" - if I persist, and enter my 
user/pass ~8 times, it starts working! You may want to try that.

Comment 15 by wtc@chromium.org, Sep 15 2009

tomas.rollo: I just checked in a change to use the system NTLM
implementation in Windows.  Could you please test a current
Chrome build and see if it works with your ISA proxy?

Instructions:

1. Download the chrome-win32.zip file from
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/26228/

2. Extract all the files from chrome-win32.zip.  You should see a
chrome-win32 directory.

3. If you are running Chrome, shut it down.

4. Change directory to that chrome-win32 directory, and run the
chrome.exe program in that directory.

5. Type "about:version" in Chrome's location bar.  You should see the
version string:
 Chromium: 4.0.210.0 (Developer Build 26228)

6. Test Chrome with your ISA proxy.
I tried your update. The about:version screen showed the correct version, but when i 
tried to log onto an external site, there was no improvement. It still asked for my 
username and password ~8 times.

Comment 17 by wtc@chromium.org, Sep 17 2009

Please ignore chris.hulbert's comment 14 and comment 16.  He's running into
a different bug.
Okay i'll leave this issue and go over to 19474... seeya!
Hi WTC, just tried the build 26228, works like a charm with my company ISA proxy. No 
popups asking for password at all, works out of the box. Megathanks!!!

I'll start testing it for longer period of time now, will post here if I'll spot 
anything bad.

Regards
Tomas

Comment 20 by wtc@chromium.org, Sep 18 2009

Status: Started
Summary: NTLM authentication using NTLMv2 not working in Google Chrome v2.0 and newer
tomas.rollo: Thank you for testing build 26228.  But there is still an issue: Chromium 
should ask you for the username and password *once*, because I haven't fixed  issue 19  
yet.  Are you sure there are no popups asking for password at all?

Comment 21 by wtc@chromium.org, Sep 18 2009

tomas.rollo: one more thing -- I will be making more changes related to NTLM and 
Negotiate authentication.  You can help me by using our Dev channel release.  See 
http://dev.chromium.org/getting-involved/dev-channel for instructions.  Thank you for 
your help.
wtc: Chromium might have asked for the credentials at the beginning, don't recall now. 
I've switched to the DEV channel release, will be using it as a regular browser to see 
the impact of the future changes.

Comment 23 by wtc@chromium.org, Sep 21 2009

Labels: -OS-All -Area-Misc OS-Windows Area-BrowserBackend
Status: Fixed
tomas.rollo: I'm marking this bug fixed now.  Important: if Chromium doesn't ask you for the username and password at the beginning, please let me know and I'll reopen this 
bug.

I opened  issue 22532  for adding NTLMv2 support to Linux and Mac.  On Windows, we now 
support NTLMv2 as a result of using Windows SSPI for NTLM.
wtc: Chromium seems to only ask for user/pass for intranet sites which I guess require 
separate authentication. Other than that I haven't seen the user/pass dialog at all 
with the new build - neither when I open Chromium and go to first page (start of 
browsing session) nor after entire PC restart. Anyway it seems to be working fine now 
:)

Comment 25 by wtc@chromium.org, Sep 21 2009

Status: Started
tomas.rollo: Thanks for the new info.  I will look into why Chromium doesn't
ask you for the username and password for the ISA proxy.  I have no clue ...

Could you doublecheck that the username/password dialogs you see for the
intranet sites display the hostnames and ports of the intranet sites rather
than the ISA proxy?

Comment 26 by zhen...@gmail.com, Sep 23 2009

I've been trying to find a fix/workaround for this issue for some time since my 
workplace security people forced a new authentication scheme which broke both Firefox 
and Chrome (after 1.0). Since the canned standard response from them is that they 
support only Internet Explorer, I have been unable to find out what level of NTLM 
authentication they used. 

I am happy to confirm that build 4.0.211.4 (from the dev channel) now works (OS: 
Windows XP SP3), and it only prompts once for the username/password. Cheers! 

Comment 27 by Deleted ...@, Oct 7 2009

The way the admin team has our proxy set up allows me to get through with Chrome 
(without signing into the proxy) as long as I have opened IE in the last 7 minutes or 
so. Hope this helps. 

Comment 28 by wtc@chromium.org, Oct 7 2009

andrew.chipman05: thanks for the info.  Could you type
"about:version" in the location bar of Chrome and tell
me what version you're using?  If it's 3.0.195.25, then
it doesn't have my fix for this bug.

tomas.rollo: I'd appreciate it if you could answer my
questions in comment 25.  That's the only remaining
issue for this bug.
wtc@chromium.org: chromium now asks for the username and pass at the start of each 
session (i.e. open the browser from scratch and navigate to first internet page). The 
dialog shows the proxy address and port, so it seems to act as expected. Note that 
I'm now running 4.0.220.1 (build 27713) as I'm subscribed to the dev channel.

Hope this clears it up and we can close this bug.

Cheers
Tomas

Comment 30 by wtc@chromium.org, Oct 7 2009

Status: Verified
tomas.rollo: Yes, that's the expected behavior.  Please continue to
use our Dev channel releases.  Thanks a lot.

Comment 31 by Deleted ...@, Oct 7 2009

wtc@chromium.org: I'm at version 3.0.195.25 

Comment 32 by Deleted ...@, Nov 6 2009

Hi. I have Chrome 3.0.195.27 (Official Build 28507). I have a similar problem with 
NTLMv2 (or Negotiate). I have no proxy as I am using my local PC. I have a custom Web 
Server written in .NET using the standard HttpListener code. Firefox and IE work 
fine, but Chrome asks me once for my userid/password and then cycles ad infinitum 
getting 401 errors and NOT sending a header for the authentication. I'm using Fiddler 
(www.fiddler2.com) to see the traffic. Any idea which minor version to use?

Thanks,

Michael

Comment 33 by zhen...@gmail.com, Nov 9 2009

Hi, the problem has resurfaced in 4.0.237.0 - the browser now loops infinitely 
asking for my proxy username/password combination and it fails repeatedly. 
Strangely, Chrome is able to check for status update. 

I will try to rollback my installation to the previous version and see if that works.

Cheers.

Comment 34 by zhen...@gmail.com, Nov 9 2009

I managed to get NTLM proxy authentication working after rolling it back to version 
4.0.211.2 (Official Build 26474). I downloaded this version from FileHippo - the 
immediate version before 4.0.237.0 did not work either.
Labels: -Area-BrowserBackend Area-Internals

Comment 36 by Deleted ...@, Feb 17 2010

I'm running 4.0.249.89 (38071). I'm getting this more than ever before.
Has anyone tried this with one of the 5.0 dev builds?
Never mind. I gave 5.0.322.2 a try. Same problem. :-(
Chrome 5.0.342.3 problem is still here

Comment 40 by Deleted ...@, May 5 2010

Problem is fixed for me with 5.0.375.29
I'm still having authentication problems even with 5.0.322.2. I still get the multiple 
prompts. I hear that this now has NTLMv2 authentication, but I can't explain why this 
doesn't work where Firefox and IE work fine.
I'm still having authentication problems even with 5.0.322.2. I still get the multiple 
prompts. I hear that this now has NTLMv2 authentication, but I can't explain why this 
doesn't work where Firefox and IE work fine.
5.0.375.29 (Official Build 46008) beta is working fine now, no prompts for 
username/password at the start of browsing session as opposed to the previous (v4) 
versions.

Kudos!

Comment 44 by wtc@chromium.org, May 6 2010

Please do not add new comments to this bug report.  Instead, please file
new bug reports.  This will help us keep track of all the problems with
HTTP NTLM and Negotiation authentication.

This bug report is limited to the problem that tomas.rollo originally
reported.

Comment 45 by Deleted ...@, Aug 26 2010

Will google ever introduce NTLM authentication in Chrome? This has been around for years now and there are hundreds of people posting comments but nothing from google as to state whether or not it will be implemented.



After upgrading from version 5 (can't remember which exact version) to Chrome 7.0.503.0 dev, I cannot open my intranet websites that use NTLM authentication.  The modal dialog box appears, I enter my credentials, no login, but I do get locked out of my Active Directory account.  I have to use IE or Firefox to get to those websites.

Comment 47 by Deleted ...@, Oct 29 2010

FYI, in my case removing "negociate" authentication mode from squid.conf using squid3 allowed chrome 7.0.517.41 to successfully authenticate with windows session credentials without prompting for login/password.

Comment 48 by rcoa...@gmail.com, Dec 26 2011

I don't know which bug to post this, but I've found out that some proxy servers (Websense in my case) have configurations concerning the user-agent. And they actively block NTLM auth even when requested by the browser if the user-agent is not recognized (or matches some list, dunno). For example in my company, setting chrome's user-agent to a Firefox user-agent magically makes NTLM authentication work. I suggest you to ask everyone having NTLM auth problems to try changing their chrome's UA to the one of a working browser (IE ou Firefox) and see if it works. I'm not saying this is a solution, but it can help find out which bugs are real chrome problems and which are stupid sysadmins configuration problems.
Project Member

Comment 49 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 50 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Sign in to add a comment