Issue 117802 in chromium: Servers not correctly detected as Intranet: Integrated authentication fails

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Type-Bug Pri-2 Feature-Enterprise

New issue 117802 by wyd...@gmail.com: Servers not correctly detected as
Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Version of Google Chrome (Wrench-> About Google Chrome):17.0.963.79
Version of MSI (if applicable): 15.x
Using group policy settings? Yes/No: No

Other browsers tested:
Chrome 17.x (Windows 7): OK
IE 7/8/9 (Vista): OK
IE 8/9 (Windows 7): OK
Firefox 10.x (Vista/Windows 7): FAIL
Safari: NOT TESTED

Scenario:
* We have IIS web based services hosted in a private cloud, many of these
services are enabled for integrated authentication
* The private cloud has an incoming trust with our domain - Users in our
corporate domain can authenticate in the private cloud
* Our proxy configuration uses a PAC. For servers in the private cloud, an
IP address range instructs the browser to bypass the proxy and send traffic
DIRECT
* IE on all our clients is enabled to "Automatically Detect Intranet
Network" as per this article http://support.microsoft.com/kb/2028170.
Sites therefore that are a result of a proxy bypass, are treated as
INTRANET.

Result/Issue:
Chrome 17.x when running on Vista isn't detecting the private cloud as
Intranet. By design therefore Chrome is ignoring the server's
WWW-Authenticate:Negotiate/NTLM headers sent in response to the initial GET
request. Integrated authentication therefore fails and rolls over to basic,
prompting the user for a username/password, which the user does not have
(we use smartcards).

Expected Result:
As per Windows 7 and all IE browsers on both Vista and Windows 7, Chrome on
Vista should detect/treat the private cloud as INTRANET and Integrated
authentication will proceed

Workaround:
Users of Chrome on Vista who require to use services in the private cloud
must launch Chrome with the added argument
--auth-server-whitelist="*cloud-domain.com" this however takes precedence
over any automatic detection, causing other intranet based services not
hosted in the private cloud to fail (unless also added to the whitelist).

Although the workaround is possible for the short term, it's not
sustainable.
Please help to address this matter for our users using Chrome on Vista.

Thanks.

[chro...@googlecode.com]

Comment #1 on issue 117802 by joaod...@chromium.org: Servers not

correctly detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Have you considered the AuthServerWhitelist policy, instead of the command
line?

http://www.chromium.org/administrators/policy-list-3#AuthServerWhitelist

[chro...@googlecode.com]

Updates:
Status: Available
Labels: OS-Windows

Comment #7 on issue 117802 by cbent...@google.com: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Sorry - was traveling last week.

I agree that Chrome needs to improve our intranet detection to be more
consistent with IE. This particular setting will help.

[chro...@googlecode.com]

Comment #8 on issue 117802 by wyd...@gmail.com: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Thanks. I guess our immediate and most pressing concern is why the
behaviour difference between operation of Chrome on Vista vs Windows 7?
With almost all of our users on Vista and with the Intranet detection
problem occurring on Vista, we really need to get to the bottom of this and
address the root cause ASAP. Any ideas? Thanks.

[chro...@googlecode.com]

Updates:
Status: Started
Owner: asa...@chromium.org

Comment #10 on issue 117802 by asa...@chromium.org: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #11 on issue 117802 by wyd...@gmail.com: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Any update on this item? Thanks.

[chro...@googlecode.com]

Updates:
Cc: cben...@chromium.org w...@chromium.org ero...@chromium.org

Comment #13 on issue 117802 by asa...@chromium.org: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Issue 122788 has been merged into this issue.

[chro...@googlecode.com]

Comment #14 on issue 117802 by wyd...@gmail.com: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Hi Asanka, Happy New Year... Any news on this item? Thanks.

[chro...@googlecode.com]

Comment #15 on issue 117802 by wyd...@gmail.com: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

Any news Asanka?

[chro...@googlecode.com]

Comment #16 on issue 117802 by jwe...@compumaster.de: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

is there any status update, roadmap plan, any information we might plan
with?

[chro...@googlecode.com]

Comment #18 on issue 117802 by wyd...@gmail.com: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

@Asanka, all
Do you have an update on this, it's been over a year now!

We're having an increasing number of issues with unsuccessful intranet
detection in Chrome that's its threatening Chrome's viability as an
alternative web browser to IE, within our enterprise environment.
Even with the AuthServerWhitelist policy or the equivalent launch argument
applied, Chrome doesn’t seem to obey these and for some users/sites Chrome
apparently (and randomly which is makes it worse) treats some of our
internal (now whitelisted) sites as Internet.

I need to get to the bottom of this ASAP please and at least be able to
explain why this is happening. So if there is not going to be a fix soon,
I’d at least like to understand the details of how Chrome today does
Intranet detection and why policies such as AuthServerWhitelist and I
assume AuthNegotiateDelegateWhitelist “appear” to be ignored. Thank you.


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #19 on issue 117802 by wyd...@gmail.com: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

@Asanka, all

Do you have an update on this please, it's been over a year now! Chrome’s
apparent randomness with respect to intranet detection is beginning to wear
on us. :-(

We’ve applied AuthServerWhitelist and AuthNegotiateDelegateWhitelist
policies and it helps, but with an enterprise the size of ours and with
many joint ventures and trusted domains, the fact we can’t treat sites that
bypass the proxy as Intranet (like IE can) does mean that we have to
explicitly whitelist everything and this is high on administrative effort
as you can imagine.

Therefore if there is not going to be a fix soon, we'd at least like to
understand the details of how Chrome today does Intranet detection, so I
may be able to explain to our stakeholders why we have this randomness to
Intranet detection (and therefore SSO/IWA) in Chrome. Could you perhaps
oblige?

[chro...@googlecode.com]

Comment #20 on issue 117802 by asa...@chromium.org: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

In general, Chrome doesn't do its own intranet detection. The issue here
is about how Chrome decides whether or not to use default credentials
for HTTP authentication.

Chrome uses default credentials if one of the following is true:

* The target for authentication is a proxy server.

* A AuthServerWhitelist was specified and the target server is included
in the whitelist.

* A AuthServerWhitelist was NOT specified and one of the following is true:

- The CREDENTIALS_USE policy for the target URL is SILENT_LOGON_OK. [1]

- The CREDENTIALS_USE policy for the target URL is CONDITIONAL_PROMPT
*AND* the target URL is in the INTRANET zone. [2]

Both [1] and [2] are determined by using a IInternetSecurityManager
instance acquired using the CoInternetCreateSecurityManager API. Chrome
doesn't have its own logic for looking at Security Zones.

[1]: This is based on the 'User Authentication' setting of the security
zone for the target URL. These settings can be configured on the
local machine or via group policy:


http://blogs.msdn.com/b/askie/archive/2012/06/05/how-to-configure-internet-explorer-security-zone-sites-using-group-polices.aspx

Security zones and policies are described in:

http://msdn.microsoft.com/en-us/library/ms537186.aspx

[2]: The determination of whether a site belongs to the INTRANET zone is
done by invoking IInternetSecurityManager::MapUrlToZone. The
determination is based on the URL and doesn't take the results of a
PAC script evaluation into account.

The addition of treating a URL as being in the INTRANET zone at [2]
based on the results of the PAC script evaluation is the scope of this
issue.

[chro...@googlecode.com]

Comment #21 on issue 117802 by jwe...@compumaster.de: Servers not correctly

detected as Intranet: Integrated authentication fails
http://code.google.com/p/chromium/issues/detail?id=117802

@asanka: thank you for describing a few more details on the process.

But the issue #122788 reference in this issue is still open and I don't
know if ticket #122788 could be solved by adding an extra check for the
proxy exclude list (I assume, the AuthServerWhitelist contains the
addresses from the proxy exclude list (a string like
e.g. "*.mycompany.com;10.121.*;*.mycompany.de;*.de.deutz.de;172.16.72.58;172.16.1.2")
as well as a logic to detect for local network addresses if the checkbox
for "don't use proxy server for local network addresses" (origin label in
German: Proxyserver für lokale Adressen umgehen)

Or maybe the ToDo is to fill the AuthServerWhitelist with all the addresses
from the proxy exclude list and the local network addresses?

Is there a chance that issue #122788 can be closed soon by doing some extra
work here?