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

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Mar 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

No logon prompt for "Integrated Windows Authentication" (NTLM) only sites

Reported by srolla...@gmail.com, Jan 22 2009

Issue description

Chrome Version       : 2.0.157.2
URLs (if applicable) : N/A (all sites are internal intranet sites).
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3:
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Browse to an IIS-based web site with only "Integrated Windows 
Authentication" (NTLM) enabled

What is the expected result?
Google Chrome prompts for user name and password

What happens instead?
A HTTP/401 error page is displayed instead:

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

Please provide any additional information below. Attach a screenshot if 
possible.

It seems that if only NTLM "Integrated Windows Authentication" (and not 
Basic Authentication) is enabled for a site, Google Chrome does not even 
prompt for the id and password. This was working correctly in earlier 
versions, as I was able to successfully log on to sites on the intranet at 
work which all used Integrated Authentication, but this is not currently 
possible.
I have tested this with a local test site, and with Basic Authentication 
enabled I get the prompt but with only "Integrated Windows Authentication" 
I don't.
 

Comment 1 by brian...@gmail.com, Jan 24 2009

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.

Comment 2 by Deleted ...@, Jan 27 2009

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.

Comment 3 by dhor...@gmail.com, Jan 27 2009

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.

Comment 4 by Deleted ...@, Jan 27 2009

forgot to add that my version is 2.0.159.0

Comment 5 by dhh...@gmail.com, Jan 27 2009

Similar or duplicate of  Issue 19  ?

Comment 6 by Deleted ...@, Jan 27 2009

 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

Comment 7 by dhh...@gmail.com, Jan 27 2009

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.

Comment 8 by Deleted ...@, Jan 27 2009

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.

Comment 10 by blarh...@gmail.com, Jan 28 2009

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.

Comment 11 by sco...@gmail.com, Jan 29 2009

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.

Comment 13 by Deleted ...@, Jan 29 2009

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 :)

Comment 16 by jon@chromium.org, Feb 4 2009

Mergedinto: 19
Status: Duplicate

Comment 17 by Deleted ...@, Feb 5 2009

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.    

Comment 18 by iam...@gmail.com, Feb 6 2009

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.

Comment 19 by Deleted ...@, Feb 6 2009

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


Comment 20 by iam...@gmail.com, Feb 6 2009

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".

Comment 22 by iam...@gmail.com, Feb 6 2009

@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.



Comment 23 by wtc@chromium.org, Feb 6 2009

Labels: -Area-Misc Area-BrowserBackend Regression
Mergedinto: -19
Status: Untriaged
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.

Comment 24 by Deleted ...@, Feb 6 2009

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.

Comment 27 by iam...@gmail.com, Feb 7 2009

Many thanks for this.

Comment 28 by cad...@gmail.com, Feb 11 2009

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

Labels: -Pri-2 Pri-1 NewHTTP stable
Status: Assigned
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?

Comment 30 by wtc@chromium.org, Feb 11 2009

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

Comment 31 by wtc@chromium.org, Feb 14 2009

 Issue 6287  has been merged into this issue.
Labels: Mstone-2.0
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
------------------------------------------------------------------------

Comment 35 by wtc@chromium.org, Feb 18 2009

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

Keep up the good work!!
 Issue 7843  has been merged into this issue.
 Issue 7932  has been merged into this issue.

Comment 40 by wtc@chromium.org, Feb 25 2009

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
------------------------------------------------------------------------

Comment 42 by iam...@gmail.com, Feb 25 2009

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.

Comment 44 by iam...@gmail.com, Feb 25 2009

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

Comment 47 by Deleted ...@, Feb 26 2009

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.

Comment 49 by Deleted ...@, Feb 26 2009

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.

Comment 51 by Deleted ...@, Feb 26 2009

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.

Comment 54 by wtc@chromium.org, Mar 1 2009

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


Comment 56 by wtc@chromium.org, Mar 2 2009

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.

Comment 57 by Deleted ...@, Mar 2 2009

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

Comment 58 by jon@chromium.org, Mar 2 2009

Status: Fixed
Sounds fixed to me.

Comment 59 by Deleted ...@, Mar 3 2009

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
------------------------------------------------------------------------

Comment 62 by bqan...@gmail.com, Jun 19 2009

What Rev of the software was this fixed in?

Comment 63 by wtc@chromium.org, Jun 19 2009

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

Comment 64 by Deleted ...@, Jul 22 2009

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?

Comment 65 by Deleted ...@, Jul 22 2009

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.
Labels: -Area-BrowserBackend Area-Internals Internals-Network
Labels: -Regression bulkmove Type-Regression
Chrome Version       : 2.0.157.2
URLs (if applicable) : N/A (all sites are internal intranet sites).
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3:
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Browse to an IIS-based web site with only &quot;Integrated Windows 
Authentication&quot; (NTLM) enabled

What is the expected result?
Google Chrome prompts for user name and password

What happens instead?
A HTTP/401 error page is displayed instead:

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

Please provide any additional information below. Attach a screenshot if 
possible.

It seems that if only NTLM &quot;Integrated Windows Authentication&quot; (and not 
Basic Authentication) is enabled for a site, Google Chrome does not even 
prompt for the id and password. This was working correctly in earlier 
versions, as I was able to successfully log on to sites on the intranet at 
work which all used Integrated Authentication, but this is not currently 
possible.
I have tested this with a local test site, and with Basic Authentication 
enabled I get the prompt but with only &quot;Integrated Windows Authentication&quot; 
I don't.
Project Member

Comment 68 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 69 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Type-Regression Type-Bug-Regression Cr-Internals Cr-Internals-Network

Sign in to add a comment