Disabling Integrate Authentication for Chrome on Windows Server

[Dritan Suljoti]

Hi,

 

Trying to figure out how to run Chrome on Windows Server with an NTLM proxy which is not in the same domain as the Server. In other words, trying to figure out how to disable “Integrated Authentication” for chrome. None odf the documented switched or flags show an option to disable. Trying changes on IE settings has no impact.

https://www.chromium.org/developers/design-documents/http-authentication

 

Integrated Authentication

 

With Integrated Authentication, Chrome can authenticate the user to an Intranet server or proxy without prompting the user for a username or password. It does this by using cached credentials which are established when the user initially logs in to the machine that the Chrome browser is running on. Integrated Authentication is supported for Negotiate and NTLM challenges only.

 

Due to potential attacks, Integrated Authentication is only enabled when Chrome receives an authentication challenge from a proxy, or when it receives a challenge from a server which is in the permitted list.

 

This list is passed in to Chrome using a comma-separated list of URLs to Chrome via the AuthServerWhitelist policy setting. For example, if the AuthServerWhitelist policy setting was:

 

*example.com,*foobar.com,*baz

 

then Chrome would consider that any URL ending in either 'example.com', 'foobar.com', or 'baz' is in the permitted list.  Without the '*' prefix, the URL has to match exactly.

 

In Windows only, if the AuthServerWhitelist setting is not specified, the permitted list consists of those servers in the Local Machine or Local Intranet security zone (for example, when the host in the URL includes a "." character it is outside the Local Intranet security zone), which is the behavior present in IE. Treating servers that bypass proxies as being in the intranet zone is not currently supported.

 

If a challenge comes from a server outside of the permitted list, the user will need to enter the username and password.

 

Any suggestions?

 

 

Thanks

 

drit

 

[Asanka Herath]

On Mon, Aug 28, 2017 at 12:33 PM Dritan Suljoti <dr...@catchpoint.com> wrote:

Hi,

 

Trying to figure out how to run Chrome on Windows Server with an NTLM proxy which is not in the same domain as the Server. In other words, trying to figure out how to disable “Integrated Authentication” for chrome. None odf the documented switched or flags show an option to disable. Trying changes on IE settings has no impact.

https://www.chromium.org/developers/design-documents/http-authentication

 

Chrome should be prompting you if the integrated authentication fails to the proxy. Is that not happening?

 

Integrated Authentication

 

With Integrated Authentication, Chrome can authenticate the user to an Intranet server or proxy without prompting the user for a username or password. It does this by using cached credentials which are established when the user initially logs in to the machine that the Chrome browser is running on. Integrated Authentication is supported for Negotiate and NTLM challenges only.

 

Due to potential attacks, Integrated Authentication is only enabled when Chrome receives an authentication challenge from a proxy, or when it receives a challenge from a server which is in the permitted list.

 

This list is passed in to Chrome using a comma-separated list of URLs to Chrome via the AuthServerWhitelist policy setting. For example, if the AuthServerWhitelist policy setting was:

 

*example.com,*foobar.com,*baz

 

then Chrome would consider that any URL ending in either 'example.com', 'foobar.com', or 'baz' is in the permitted list.  Without the '*' prefix, the URL has to match exactly.

 

In Windows only, if the AuthServerWhitelist setting is not specified, the permitted list consists of those servers in the Local Machine or Local Intranet security zone (for example, when the host in the URL includes a "." character it is outside the Local Intranet security zone), which is the behavior present in IE. Treating servers that bypass proxies as being in the intranet zone is not currently supported.

 

If a challenge comes from a server outside of the permitted list, the user will need to enter the username and password.

 

Any suggestions?

 

 

Thanks

 

drit

 

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/DM5PR04MB0188A5049847C13A4F4A3969AF9E0%40DM5PR04MB0188.namprd04.prod.outlook.com.

[Dritan Suljoti]

Chrome does display the dialog window for credentials – but it keeps asking on the infinite. From wireshark capture it seems like it responds to the first 407 from the proxy with the NTLM credentials of current logins user.

 

From our tests it seems to be an issue with “squid/3.3.8” and the order in which Chrome processes NTLM. We tested with IE on the same machine it works.

 

We tested with Chrome on a Windows 10 machine with a non-domain user, it works fine (there the order is different, it does not seem to pass the user credentials on the first 407).

 

We also tested with Mcafee Gateway and it works fine.

 

We tried also what is stated here, but did not work either: https://stackoverflow.com/questions/33283442/how-to-turn-off-windows-integrated-authentication-in-chrome

 

 

Thanks

 

drit

[Asanka Herath]

On Mon, Aug 28, 2017 at 8:38 PM Dritan Suljoti <dr...@catchpoint.com> wrote:

Chrome does display the dialog window for credentials – but it keeps asking on the infinite. From wireshark capture it seems like it responds to the first 407 from the proxy with the NTLM credentials of current logins user.

Could you file a bug (here) and attach a net-internals log as described here (alternatively, email me a log, but also file a bug)? You don't need to include any private information. While the tokens will be stripped from the log, the byte counts will remain. Those are likely sufficient for us to figure out whether we are mishandling the handshake in this case.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/DM5PR04MB018891C701BCF7FFA06BD96FAF9F0%40DM5PR04MB0188.namprd04.prod.outlook.com.