Authorization request header for NTLM is no longer being sent which is breaking authentication to internal corporate applications
Reported by
kevin.r...@accelecode.com,
Apr 18 2016
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36 Example URL: I don't have a URL I can share. Hopefully you have a test environment with a Windows domain setup. Steps to reproduce the problem: 1. Visit any site protected by Windows authentication (using a Windows domain) 2. You are prompted for basic authentication What is the expected behavior? The correct Authorization header should be sent and a site protected with Windows authentication should function properly. The user should not be prompted for basic authentication credentials. What went wrong? I have verified using the dev tools that the "Authorization: Negotiate ..." request header is not being sent by the browser (I compared the behavior with Chromium 49). Did this work before? Yes version 49 Chrome version: 50.0.2661.75 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0 Installing Chromium version 49 resolves the problem. This appears to be a regression.
,
Apr 18 2016
Thanks for filling this issue. I don't have a test environment handy with windows authentication, but if you upload a net-internals log we may be able to track down the issue. https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
,
Apr 18 2016
,
Apr 18 2016
I just sent you the net-internals log file as requested. I used your email address as shown on this issue.
,
Apr 18 2016
Thanks. Looks like the server is sending
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
And the URLRequest just hangs for 20 seconds until you stopped the log.
cc davidben@, svaldez@. Ping me for the net-internals if you want it. If we can throw together a repro it looks like this should be bisectable.
,
Apr 18 2016
+asanka is probably the right person for anything NTLM or Negotiate related.
,
Apr 19 2016
Hi again. Any update on this issue. Did you find the root cause yet? By the way, thanks for your help!
,
Apr 20 2016
Thank you for providing more feedback. Adding requester "csharrison@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 20 2016
I'm no longer on triage duty, sheriffbot. Opening this up for davidben@ to further triage.
,
Apr 20 2016
The net log is at this drive link accessible by Googlers: https://drive.google.com/open?id=0B4nvMDZmRxtxQkROdExsUWVsRk0
,
Apr 20 2016
Going ahead and assigning this to Asanka to investigate. I don't see anything in the log that looks especially enlightening to me either. We seem to be stuck on something locally.
,
Apr 22 2016
Removing from triaging queue since an owner is already assigned.
,
Apr 26 2016
We were able to resolve this problem ourselves. This is not a browser bug. Windows group policy was setting a registry key named "AuthServerWhiteList" with a value that was not comprehensive enough for all of our internal sites. It appears that setting the key forces Chrome to stop using settings for IE related to trusted sites. Removing the key resolved the problem completely for us. We have policy in place for IE and it appears that Chrome reverted back to using the settings we have there.
,
Apr 26 2016
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by kevin.r...@accelecode.com
, Apr 18 2016