@sean.d.jost: Could you please provide the reproducible steps for the issue with an expected result screen-cast,so that it would be helpful to triage the issue from our end.
Thanks!

This looks like a headless-only issue, since Headless does not support Windows prompts. 

In headless, you should use DevTools to handle authentication
You could check if you can use Network request intercept methods for this: https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-setRequestInterceptionEnabled

Also, if this a certificate error you could use: https://chromedevtools.github.io/devtools-protocol/tot/Security/#method-handleCertificateError


Feel free to provide more info as  rkalavakuntla@ requested

Please fix this ASAP, all corporate sites use Windows Authentication and we can't use chrome headless to tests

 Issue 755129  has been merged into this issue.

 Issue 751032  has been merged into this issue.

When this will be fix? Should be marked as BUG with highest pri!!!

Agreed, extremely important to support authentication options in enterprise environments.

Any update on this issue..

IT IS A BLOCKER for everyone.
Currently Chrome headless is useless...
When this will be fix!?

It's a real bummer. We've had to create a "Test" build configuration for our WebAPI service that disables authentication - which is far from ideal! :(

Still no info...

will it work in chrome 63 version ?

I just ran into this today. We have the exact same setup.. CI server running tests against an API that uses windows authentication. Real bummer.

When this will be fix???

Having to disable authentication on our web app in order to use headless chrome (62) in CI tests, which means we can't automate any of the access tests.

This is also a deal-breaker for my current assignment. Verifying whether NTLM authentication works correctly is exactly the main reason why we're introducing UI testing/Chrome headless.

Is there any ETA for this issue?

I'm having the same issue too.  Chromium Devs - is there any update?

There is a workaround, though it's a bit involved.

You can run this proxy server: http://cntlm.sourceforge.net/ - it has a "NTLMToBasic" feature (-B) flag that lets you turn NTLM auth into "basic auth".

Then start headless chrome with the proxy-server flag, e.g:

--proxy-server=http://127.0.0.1:7080

And then pass in the basic auth credentials as shown here:

https://github.com/hross/headless-chrome-basic-auth/blob/e853f0a9c05bb1a36e96376ec264cdbb49d7ef93/request.js#L20

Any update on this issue.
We have been waiting from long time to use headless chrome.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c8be452f932dfeb6590aa6f276f4c2e39794cba0

commit c8be452f932dfeb6590aa6f276f4c2e39794cba0
Author: Iris Uy <irisu@chromium.org>
Date: Fri Dec 15 02:46:14 2017

Add a switch for the AuthServerWhitelist for headless.

This adds a switch so that an AuthServerWhitelist can be set in headless
mode which enables Negotiate authentication for the whitelisted URLs.
The switch is added to the HttpAuthPreferences for the HttpAuthHandlerFactory,
which is set in the URLRequestContext.

Bug:  741872 
Change-Id: Iaeaefbf58ff21351b9830309faf4f017c14e7b17
Reviewed-on: https://chromium-review.googlesource.com/828321
Reviewed-by: David Vallet <dvallet@chromium.org>
Commit-Queue: Iris Uy <irisu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524300}
[modify] https://crrev.com/c8be452f932dfeb6590aa6f276f4c2e39794cba0/headless/app/headless_shell_switches.cc
[modify] https://crrev.com/c8be452f932dfeb6590aa6f276f4c2e39794cba0/headless/app/headless_shell_switches.h
[modify] https://crrev.com/c8be452f932dfeb6590aa6f276f4c2e39794cba0/headless/lib/browser/headless_url_request_context_getter.cc

I've added a new flag for headless: --auth-server-whitelist. With this change, negotiate authentication should work with headless.

This should be set the same as the AuthServerWhitelist policy is set for headfull chrome. See the "Integrated Authentication" section here: https://www.chromium.org/developers/design-documents/http-authentication or see: https://dev.chromium.org/administrators/policy-list-3#AuthServerWhitelist

e.g. ./chrome --headless --auth-server-whitelist="*example.com"

Also note, on windows the --auth-server-whitelist need not be specified if the server is in the local machine or intranet.

From the design doc linked in #26: "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."

WOW, it took only 6 months to deploy few lines of code. God job!
Next 6 months to merge with prod?

#28: The change should be in M65, see https://www.chromium.org/developers/calendar. We always appreciate contributions from the community, so feel free to pitch in next time!

@irisu, is there any more work to be done here?

This should be working with that fix.

The "Integrated Authentication" section says:

"Chrome can authenticate the user [..] 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"

Is it possible to provide credentials OTHER than those of the user that logs in to Headless Chrome?

I'd like to test impersonating different users as they should see a different UI based on how their accounts are set up.  I can get an alternate Kerberos ticket, but not sure how to give it to Chrome...

I concur with comment 31 from Samir - we need a way to provide explicit domain/user/password credentials to Chrome for use in Selenium WebDriver tests, and to be able to use the headless Chromium too.  I created a workaround for non-headless where I launch Chrome using impersonation - in a "wrapped" mock version of ChromeDriver.  My version of ChromeDriver launches the real ChromeDriver with the approrpriate impersonation, and from there the  Chrome process runs as the impersonated user.  The browser prompts for NTLM credentials, and I use AutoIT to fill that dialog in.  That process works but is ugly and a kluge PITA. It does not work for Headless.    See also https://stackoverflow.com/questions/45374320/selenium-chrome-60-headless-handle-basic-authentication-saml-dialog-over-https 

Thanks for the comments

That sounds like a different feature that this feature is describing, would you mind creating a feature request for this so we can triage it?

Thanks

 Issue 806738  has been merged into this issue.

I've filed a new feature request to allow impersonating different users: https://bugs.chromium.org/p/chromium/issues/detail?id=807028

Actually, we found a work around using "Network.setRequestInterception" that allows setting any username/password without a proxy.

// 1) Call request interception:

Network.setRequestInterception({ patterns: [] })

// 2) Handle the requestIntercepted event: 

let authChallengeSubmitted = {};
let username = "test";
let password = "hunter2";

Network.requestIntercepted(function (params) {
    if (params.authChallenge) {
        // There was an auth challenge!
        if (authChallengeSubmitted[params.interceptionId]) {
            // We already tried and failed
            delete authChallengeSubmitted[params.interceptionId];
            // Cancel the authChallenge.
            Network.continueInterceptedRequest({
                'interceptionId': params.interceptionId,
                'authChallengeResponse': {
                    'response': 'CancelAuth'
                }
            });
        } else {
            // Save that we tried because if it fails, we will just get the authChallenge again.
            authChallengeSubmitted[params.interceptionId] = true;
            // Provide the username and password.
            Network.continueInterceptedRequest({
                'interceptionId': params.interceptionId,
                'authChallengeResponse': {
                    'response': 'ProvideCredentials',
                    'username': username,
                    'password': password
                }
            });
        }
    } else {
        // No auth challenge - continue with the request.
        Network.continueInterceptedRequest({ 'interceptionId': params.interceptionId });
    }
});

Hi, I'm having trouble with this. I am using Chrome 65 stable on Windows 10 with the chromedriver (version 2.36). Can you confirm that policy support for headless chrome was indeed added in Chrome 65 stable?

I am using selenium (python) with chromedriver  to automate processes for an intranet site that requires kerberos / negotiate authentication. When I use the GUI version of chrome, all works fine. However, when I use the headless, I receive a message that kerberos credentials delegation is not enabled.

Nice to see that --auth-server-whitelist works! This is one step in the direction of a solution for my problem. Is there also a flag --auth-negotiate-delegate-whitelist planned in the future? I really benefit from that as these policies should be set in my kerberos authentication setup.

I am having this issue right now with accessing using Integrated Authentication on localhost. From the notes in this issue, on Windows, --auth-server-whitelist should not be needed, but even with that, does not work.

FYI, works fine as long as I don't use --headless.