Would you mind providing a real website link for the ease of triaging?

This one is interesting. We currently don't have a way to disable prompting for Negotiate. It's almost always going to use NTLM under the hood and is probably not what folks wanted to use in the first place.

We're facing the same issue. 

The popup was shown also to user outside our organization, as such we are removing the WWW-Authenticate header for outside customers.

If you can specify an IP, I should be able to arrange a test (via exception).

I don't have any websites handy exposed to the internet with negotiate:kerberos the only acceptable method, and nobody really ought to have that either.

But it should be trivial enough to set up a lab environment with a vm hosting a full stack with AD and IIS. If you are unable to set one up in your lab, let me know and I will see if I can set up a dummy box for you, somewhere.

It seems that IE has the same bug, btw.. only firefox correctly handles this scenario and does not prompt for a username/password.

Sorry about my belated response, but I don't use gmail, so I never saw the question.

Some additional information:

Our servers do not allow NTLM auth, only kerberos.
We have an IIS webfarm set up to only allow windows authentication with the Negotiate:Kerberos provider as the only option.
We also have kernel mode disabled and run the website under a custom application pool, running under a dedicated domain user account, that has an SPN http/service.example.com registered in AD.

I have changed my google account to use my actual email rather than my defunct gmail box.

Yeah, the problem here is that the initial negotiate challenge from the server doesn't indicate which mechanisms are supported. There's no token. So the UA has to optimistically build a negotiate message using whichever credentials are available locally. If the UA is on a Windows machine, then Chrome will try to use explicit credentials with whichever mechanism the OS is willing to use with the server, which is almost always NTLM in this scenario. Of course that's ultimately not going to work since the server only accepts GSSAPI/Kerberos.


In the netlog in #0, I see an attempt at an authentication handshake using ambient or cached credentials. Can you comment on which it was?

reporter: Can you answer the question in comment 9? 

Archiving bug due to lack of response from the bug creator. 4815162342.mn@, please create a new bug if you have further updates.