I do not control this server so I don't know if it is configured with NTLM as 
srollason describes but this same message is coming up at http://moss.calpoly.edu  
The site works fine in firefox.

I can confirm this is a problem as it was working a few days ago.  
I have reproduced exactly the same problem as srollason.  Very Frustrating..  
Can we get a fix for this asap.

I can confirm this is problem with 2.0.157.2 and I have reproduced the error on a IIS 
web server I control that is configured to only accept NTLM authentication.

forgot to add that my version is 2.0.159.0

Similar or duplicate of Issue 19 ?

Issue 19 is dealing with proxy settings other than one or two people's comments that 
seem to point around this issue, but up until 2 days ago this was working for me.  
Also the problem here is we should be getting prompted and are not

This pretty much removes the ability to use chrome with IIS if only NTLM "Integrated 
Windows Authentication" is checked in the config.
-b

Well, Issue 19 ultimately is about implementing NTLM authentication (proxy or 
otherwise), which as far as I know has never been implemented in Chrome yet.  If 
anything worked before, I don't have an explanation for it.

wow, that is quite amazing-- NTLM never has been implemented?

But my question then is why is it working now on two of my coworkers machines using 
chrome(I can check versions..if you would like)  and not mine and another machine 
which both are set up as to pull down google chrome developer updates?

I'm having this exact issue. It prompted for un/pw in a previous version, but now it 
just goes right to the HTTP 401.2 error screen. I don't really care if automatic NTLM 
auth is ever implemented, but I do need to be prompted for the credentials if it's 
not. I have v2.0.159.0.

In 1.0.154.43 NTLM auth is working as intended, login prompt is displayed.
In 2.0.158.0  NTLM auth fails with 401.2, login prompt is never displayed.

I suspect that this is related to the "New network code" added in 2.0.156.1

It should be fairly simple to set up an ethereal environment to debug this, and I 
suspect that the team in charge of the network implementation already have this set 
up.

Note that this is a duplicate of 7150.

Having read this thread, I have a theory for why this used to work. Following on from 
Comment 10... Chrome must have gotten NTLM authentication "for free" with winHTTP.

Man, that's a drag because Chrome I would much rather use Chrome when forced to 
access our internal SharePoint site!  :(

Indeed, seems to be a duplicate of 7150 and 6287.

It is great that many people have logged it as a bug.  I hate having to use firefox 
again, but this leaves me no choice...

Soo...when can we get a patch... humble programmers og chrome.  :)

 Issue 7150  has been merged into this issue.

Come on guys... I'll send out a box of cookies to the first one who can successfully 
implement this feature :) I'm also trying to use SharePoint sites, and like someone 
said, even if it's not automated it'd sill be something :)

(No comment was entered for this change.)

I am experiencing the exact same issue... our Sharepoint intranet prompts me for U|P 
on version 1.0.154.43 and gives me a 401.2 with version 2.0.158.0.    

Why was this merged into issue #19?  Issue #19 relates to proxies.  This issue has 
nothing to do with proxies and is a new bug which was introduced when WinHTTP was 
removed.  When Issue #19 was created, this particular problem did not exist.

Hello iambob, I been following this issue for some time.

I am now running version 1.0.154.48 without this problem, just fyi.  If you want to 
have authentication working for now, unistall google chrome and re-install and don't 
set up the developer edition.

The reason it was merged with the issue 19 is from comment 11 above scott3--chrome 
must have gotten NTLM authentication "for free" with winHTTP.  Therefore reading 
issue number 19: Implement integrated windows authentication (aka NTLM / Negotiate 
Auth support).  So this makes perfect sense to me.  Of course you probably are saying 
they removed Winhttp and then the bug came up...which I agree..but I am sure there 
are reasons for it?

I dont know googles development cycles or how they take along in stories in their 
sprints, but I can gather that this might take a while to implement.  Therefore off 
of develepment for me.  Plus the last development version was giving me blue screens 
when I ran it... Yuck...

Perhaps the best question to ask is when will this be implemented?  Good luck

Right.  NTLM has been implemented for a while, and I was using it with our Intranet 
for a while.  (P.S.: Our Intranet is NOT SharePoint... it is custom... but it DOES 
use NTLM for authentication)  As soon as WinHTTP was removed, the NTLM authentication 
went with it.

I believe the reason WinHTTP was removed was to make the code-base less platform 
specific (so it can be more easily ported to Mac/Linux).  Unfortunately, it has the 
side effect of removing NTLM.  I don't think this was intentional, but I also don't 
think that many of the testers or developers visit sites that require NTLM, so it 
went unnoticed during alpha testing but it becoming very evident during beta testing.  
So, really, if Issue 19 is only about implementing NTLM, then Issue 19 should have 
been closed a long time ago, before this new problem came up.  However, when reading 
the specifics of Issue 19, it specifically relates to how NTLM authentication works 
through proxies.

Basically, previous posters have said it already: Chrome had gotten NTLM authentication 
"for free" with winHTTP.  However, that was just a *bonus* side effect, and the 
developers have *never* considered NTLM authentication as ever having been implemented.  
@iambob, I think it is incorrect to say that "NTLM had been implemented for a while" 
because the developers have always known NTLM would "go away" once they switched to the 
newHTTP stack.

And this has been known from very the beginning because Chrome was *always* going to 
have its own HTTP stack.  winHTTP was only used at the very beginning to quickly get a 
first stage browser working and out to market for users to try and get feedback for.  

Although many of the comments in Issue 19 are about NTLM through proxies, this bug is 
duplicated to that one because Issue 19 is effectively expanded to be a bug about just 
plain "implementing NTLM".

@krtulmay,

Well, when I said "NTLM had been implemented for a while" I was speaking from a user-perspective, not a 
developer-perspective.  As far as USERS are concerned... Chrome had a feature, then suddenly lost it.  If the 
feature was never intended, the developers should have been careful enough to disable it so that users didn't 
start relying on it.

As it stands, I switched to using Chrome 99% of the time when it started becoming a bit more stable.  Then, 
when NTLM authentication was lost, I have been forced to using Chrome 80% of the time, with Safari the 
remainder of the time.

If the developers always knew that NTLM authentication would go away, it would have been much nicer to 
communicate this to users ahead of time.  Adding new features without informing the users is one thing.  
Deprecating features and apologizing to users is another.  Taking away features and then explaining to users 
"it wasn't supposed to be there for months to begin with."  That's just irresponsible.

And if issue 19 started out being related to NTLM authentication through a proxy, it should remain that.  
Allowing one issue to slowly morph into another problem altogether makes an issue system entirely pointless.  
It would allow issue 19 to be closed with the explanation "we don't plan on supporting NTLM authentication 
through proxies," leaving the separate issue of just "NTLM authentication" ignored.  It creates confusion.  If 
issue 19 changed once, who is to say it won't change again?  This also means that if the meaning of issue 19 
changes again, all other issues that were merged into it could be lost forever, needing to be entered again, 
and starting the cycle of merging unrelated issues and allowing issue-creep to continue forever.

Again, I see where you're coming from.  I now see that NTLM authentication was never intended.  I now see that 
NTLM authentication is not at the top of the list.  I now see that NTLM authentication was accidentally left in 
and was finally removed, as part of switching to its own HTTP stack.  I get all of this.  But it now means that 
Chrome, which once had a feature that Firefox, IE, and Safari have... is now missing a feature that the other 
three significant browsers continue to support.  I recognize that Chrome is not meant to be "just another 
browser"... but at some point, wouldn't the goal be to make Chrome compatible with sites that people frequent?  
One such type of site is an Intranet, even though it isn't ONLY Intranets that necessarily use NTLM 
authentication - it is the more common scenario.  Even if there could be a command-line switch, allowing Chrome 
to alternately use WinHTTP.  I would much rather run a more current version of Chrome with more up-to-date 
security patches and other improvements, but with WinHTTP for NTLM authentication... than have to be stuck 
using an out-of-date version of Chrome just so that I don't have to keep thinking about which browser I am 
going to use in different circumstances.

I confirmed that Google Chrome 1.0.154.x supports NTLM
authentication.  I mistakenly thought that we never
supported NTLM, but after consulting the source code
and talking to Nicolas, I found that the only thing we
turned off in 1.0.154.x was automatic NTLM logon;
1.0.154.x still supports NTLM authentication with manual
logon (asking the user for username and password).  The
relevant change was, from our old SVN repository:

Index: http/http_transaction_winhttp.cc
===================================================================
--- http/http_transaction_winhttp.cc    (revision 29763)
+++ http/http_transaction_winhttp.cc    (revision 29764)
@@ -916,10 +916,18 @@

   if (!WinHttpSetOption(request_handle_, WINHTTP_OPTION_DISABLE_FEATURE,
                         &options, sizeof(options))) {
-    DLOG(ERROR) << "WinHttpSetOption failed: " << GetLastError();
+    DLOG(ERROR) << "WinHttpSetOption disable feature failed:" << GetLastError()
;
     return false;
   }

+  // Disable auto-login for Negotiate and NTLM auth methods.
+  DWORD security_level = WINHTTP_AUTOLOGON_SECURITY_LEVEL_HIGH;
+  if (!WinHttpSetOption(request_handle_, WINHTTP_OPTION_AUTOLOGON_POLICY,
+                        &security_level, sizeof(security_level))) {
+    DLOG(ERROR) << "WinHttpSetOption autologon failed: " << GetLastError();
+    return false;
+  }
+
   if (is_https_) {
     // Check SSL server certificate revocation.
     SSLConfig ssl_config;

I'm reopening this bug in the hope that it will stop the
discussion on whether it's the same as issue 19.  What's
important is that we recognize the Dev channel 2.0.x.y
builds have a regression in NTLM authentication support.

Wahoo.. 
This is great news. What do you think the ETA wil be to fix this in the chrome dev 
trunk? I would like to go back to using the latest and greatest dev release.

I can't wait to have NTLM Authentication back. I'm currently using a old build at 
work so I can access our intranet sites.

wtc: ahh, that makes sense.  manual ntlm doesn't have the same security concerns as 
automatic ntlm.

Many thanks for this.

Has this been addressed?  I'm still getting HTTP Error 401.2 - Unauthorized: Access 
is denied due to server configuration on our sharepoint sites and no prompt for 
username/password from Chrome version 2.0.160.0

It looks like this is working on Stable (WinHTTP), but not on Dev.

Is this something we still need to implement in the new HTTP stack?

Yes.  That's why I marked this bug as a regression.

 Issue 6287  has been merged into this issue.

(No comment was entered for this change.)

since i switched to 2.0 i can confirm the bug on isa server. reverting to 1.x stable
until this is fixed.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9964 

------------------------------------------------------------------------
r9964 | wtc@chromium.org | 2009-02-18 13:00:32 -0800 (Wed, 18 Feb 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=9964&r2=9963
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=9964&r2=9963
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=9964&r2=9963

Perform HTTP authentication over a keep-alive connection.
This is required for NTLM authentication.

R=eroman
BUG=6567,6824
Review URL: http://codereview.chromium.org/21433
------------------------------------------------------------------------

(No comment was entered for this change.)

Now work on this issue has started, I just can't wait :)

Keep up the good work!!

Some reading materials for NTLM:
http://en.wikipedia.org/wiki/NTLM
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-
a657e5900cd3/[MS-NTHT].pdf

I plan to copy the cross-platform NTLM code from Mozilla
and integrate it with our HTTP stack:
http://mxr.mozilla.org/mozilla/source/netwerk/protocol/http/src/nsHttpNTLMAuth.cpp
http://mxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNTLMAuthModule.cpp

 Issue 7843  has been merged into this issue.

 Issue 7932  has been merged into this issue.

Status update: I have ported Mozilla's cross-platform NTLM code to
Chromium, and integrated it with Chromium's HttpAuthHandler framework.
It is working with an IIS that uses local accounts.  If you have used
Google Chrome 1.0 successfully with your domain account, could you
tell me how you enter the domain in Google Chrome's login dialog?
Do you enter "DOMAIN\user" in the username field?

I expect that I will be able to clean up the changelist for review
tomorrow.  The NTLM auth scheme is different in a few aspects from
the Basic and Digest auth schemes, so I have to change our
HttpAuthHandler framework to accomodate the differences.  The
integration of the Mozilla code with Chromium could be done
better.  I hope Eric and Darin will be able to advise in these two
areas during the code review.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=10324 

------------------------------------------------------------------------
r10324 | wtc@chromium.org | 2009-02-24 18:53:01 -0800 (Tue, 24 Feb 2009) | 11 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/generated_resources.grd?r1=10324&r2=10323
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/login_prompt.cc?r1=10324&r2=10323

Add a new message id IDS_LOGIN_DIALOG_DESCRIPTION_NO_REALM,
which is a variant of IDS_LOGIN_DIALOG_DESCRIPTION that
doesn't have a realm.  Some HTTP authentication schemes
such as NTLM don't have a realm.

In IDS_LOGIN_DIALOG_DESCRIPTION, changed the placeholder's
name from "TITLE" to "REALM".

R=eroman,tony
BUG=6567,6824
Review URL: http://codereview.chromium.org/27117
------------------------------------------------------------------------

Yes, DOMAIN\username is entered into the username field.

@wtc

Yeah, as iambob said, DOMAIN\username.

That said, you might want to consider separating that in the Chromium dialog box to
something more like:

Domain (optional): 
Username: 
Password: 

Talking from a tech support angle, I find it difficult explaining to end-users that
they are not supposed to type their username in the 'username' box, but instead
DOMAIN\username

If that makes sense.  *shrug* just a thought.

I would agree that this would make things nice and neat... but honestly, I don't 
think the interface should bow down to the special needs of NTML authentication.  I 
just want it to support it... it doesn't need to be any more special than that.

i don't need to enter my domain with 1.0, just user and password

doesn't work for me with 2.0.166.1

	Technical Information (for support personnel)
Error Code: 407 Proxy Authentication Required. The ISA Server requires authorization
to fulfill the request. Access to the Web Proxy filter is denied. (12209)
IP Address: 192.168.xxx.yyy
Date: 26/02/2009 7.45.38 [GMT]
Server: XXXXXXXXXXXXXXXXXX
Source: proxy

Doesn't work for me too with version 2.0.166.1. Please repair this issue as soon as
possible, because i must used different browser for this.

Technical Information (for support personnel)
Error Code: 407 Proxy Authentication Required. The ISA Server requires authorization
to fulfill the request. Access to the Web Proxy filter is denied. (12209)
IP Address: xx.xx.xx.xx
Date: 2/26/2009 9:02:46 AM [GMT]
Server: xxxxxxxxxxx
Source: proxy

Indeed, no automatic authentication either a login prompt when using Chrome 2.0.166.1 
with sharepoint.

Instead an error message 401.2 (instead of petr.urban.ing's 407) :

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

Works fine with IE 7.0.

Last build -- 2.0.167.0 (Developer Build 10455) -- still not working with my ISA
server or our IIS servers. But I can see the issue is closed, so I guess the code
change will be integrated in the build process soon.

unfortunatly it's marked as closed and the release note say the svn revision, 
supposed to fix this, is already compiled.

this means it's simply not fixed and we need code fix, not wait build process.

Thanks for the heads up patrizio... Looks like we have to wait until it is fixed then...

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=10667 

------------------------------------------------------------------------
r10667 | wtc@chromium.org | 2009-02-27 17:29:24 -0800 (Fri, 27 Feb 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/build/net.vcproj?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/build/net_unittests.vcproj?r1=10667&r2=10666
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/des.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/des.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/des_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth.cc?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth.h?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_cache_unittest.cc?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler.cc?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler.h?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_basic.cc?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_digest.cc?r1=10667&r2=10666
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_unittest.cc?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=10667&r2=10666
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/md4.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/md4.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.xcodeproj/project.pbxproj?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net_lib.scons?r1=10667&r2=10666
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net_unittests.scons?r1=10667&r2=10666

Implement the NTLM authentication scheme by porting
Mozilla's implementation.

R=darin,eroman
BUG=6567,6824
Review URL: http://codereview.chromium.org/28144
------------------------------------------------------------------------

This is now working in build 10679. Good Work.

gatekiller: thanks for the update.  Do you use NTLM authentication
with a local account or a "domain" account?  I don't have the setup
to test our NTLM auth code with a domain account, so I'd appreciate
it if you could test it with a domain account.

@wtc@chromium.org

I've tested with both a domain and a local account and both work. You also don't need 
to enter the domain, which is very handy, and also still works if you do enter the 
domain.

The servers I have tested them against are windows server 2003 with IIS 6.

If you would like any more testing, I'd be happy to help.

Cheers
Stephen

Stephen,

Glad to hear that.  If you could test against a proxy server
(preferrably Microsoft ISA Server) and post your test results
in  issue 6567 , I'd appreciate it.  Thanks a lot for your help.

I can confirm it :-) Now really work with test build 10689. Finally proxy work now. Cool.

Sounds fixed to me.

I can back up gatekiller. I just grabbed the lastest build version 2.0.168.0 (10786) 
and it is working great for my IIS server Internal MS server.

Thanks for the port and the fix here guys :^

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=11488 

------------------------------------------------------------------------
r11488 | wtc@chromium.org | 2009-03-11 15:21:29 -0700 (Wed, 11 Mar 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.cc?r1=11488&r2=11487
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.h?r1=11488&r2=11487
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=11488&r2=11487

Add unit tests for NTLM authentication.  This requires
overriding the functions that generate random bytes or get
the local host name, so that the generated NTLM messages are
reproducible.

R=eroman
BUG=6567,6824
Review URL: http://codereview.chromium.org/42052
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=12290 

------------------------------------------------------------------------
r12290 | wtc@chromium.org | 2009-03-23 09:52:20 -0700 (Mon, 23 Mar 2009) | 17 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.cc?r1=12290&r2=12289
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ntlm.h?r1=12290&r2=12289
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=12290&r2=12289

Make GetHostNameProc return a std::string.

Add the ScopedProcSetter helper class so that unit tests
restore the original GenerateRandom and GetHostName
functions on completion.

Merge NTLMAuthModule into HttpAuthHandlerNTLM.  The data
members domain_, username_, and password_ are moved.  The
Init method is inlined at its only call site.  The
GetNextToken method is moved.

Make generate_random_proc_ and get_host_name_proc_ static
members of the HttpAuthHandlerNTLM class.

R=eroman
BUG=6567,6824
Review URL: http://codereview.chromium.org/43113
------------------------------------------------------------------------

What Rev of the software was this fixed in?

It's fixed in the current Stable release (2.0.172.28 or later).

With 2.0.172.37 under the ISA proxy with NTLM I need to enter my credentials every time 
I start browsing. Very annoing. Is it possible to turn on the NTLM autologon via the 
winlogon credentials, like IE does?

Sorry for previous message incompleteness. In details, I want to have some possibility 
to config trusted sites for NTLM autologon. Just like the network.automatic-ntlm-
auth.trusted-uris config setting in FireFox.

(No comment was entered for this change.)