New issue
Advanced search Search tips

Issue 649664 link

Starred by 3 users
Status: Duplicate
Merged: issue 648366
Owner: ----
Closed: Nov 2016
Cc:
asanka@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

NTLM auth not asking user password when fails

Reported by augusto....@gmail.com, Sep 23 2016 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36

Steps to reproduce the problem:
1. Connect to a site using NTLM auth
2. Chrome will send automatically auth user/pass using NTLM
3. If user/password is not valid (workstation not in domain), Chrome will send auth/pass four more times and then fails with error invalid credentials.

What is the expected behavior?
Ask for a valid user password when credentials are not valid.

What went wrong?
Ask for a valid user password when credentials are not valid.

I've attached screenshot of the expected behavior

Did this work before? Yes Chrome 49 (maybe 50,  51 and 52)

Chrome version: 53.0.2785.101  Channel: n/a
OS Version: 10
Flash Version: 

This is the apache log (Chrome 53 on Windows 10). 

172.24.80.115 - - [23/Sep/2016:15:13:31 +0200] "GET /sso/ntlmssov2?authtoken=d061d03f-06f1-4ca4-8d6b-a1ef9fe57ce1&forceAuthDiag=yes&BACKTO=http%3A%2F%2Fws01%2FInmovilizado%2F HTTP/1.1" 301 1077 "http://ws01/Inmovilizado/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.34 Safari/537.36"
172.24.80.115 - - [23/Sep/2016:15:13:31 +0200] "GET /sso/ntlmssov2/?authtoken=d061d03f-06f1-4ca4-8d6b-a1ef9fe57ce1&forceAuthDiag=yes&BACKTO=http%3A%2F%2Fws01%2FInmovilizado%2F HTTP/1.1" 302 596 "http://ws01/Inmovilizado/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.34 Safari/537.36"
172.24.80.115 - - [23/Sep/2016:15:13:31 +0200] "GET /sso/ntlmssov3?authtoken=d061d03f-06f1-4ca4-8d6b-a1ef9fe57ce1&forceAuthDiag=yes&BACKTO=http%3A%2F%2Fws01%2FInmovilizado%2F HTTP/1.1" 401 804 "http://ws01/Inmovilizado/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.34 Safari/537.36"
172.24.80.115 - - [23/Sep/2016:15:13:31 +0200] "GET /sso/ntlmssov3?authtoken=d061d03f-06f1-4ca4-8d6b-a1ef9fe57ce1&forceAuthDiag=yes&BACKTO=http%3A%2F%2Fws01%2FInmovilizado%2F HTTP/1.1" 401 1397 "http://ws01/Inmovilizado/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.34 Safari/537.36"
172.24.80.115 - - [23/Sep/2016:15:13:32 +0200] "GET /sso/ntlmssov3?authtoken=d061d03f-06f1-4ca4-8d6b-a1ef9fe57ce1&forceAuthDiag=yes&BACKTO=http%3A%2F%2Fws01%2FInmovilizado%2F HTTP/1.1" 401 949 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.34 Safari/537.36"
172.24.80.115 - - [23/Sep/2016:15:13:32 +0200] "GET /sso/ntlmssov3?authtoken=d061d03f-06f1-4ca4-8d6b-a1ef9fe57ce1&forceAuthDiag=yes&BACKTO=http%3A%2F%2Fws01%2FInmovilizado%2F HTTP/1.1" 401 1397 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.34 Safari/537.36"

This is the apache log (Chrome 49 on Windows XP). 

172.24.81.210 - - [23/Sep/2016:15:27:31 +0200] "GET /sso/ntlmssov2?authtoken=3c820a7a-27d0-4ab2-a966-cd7ed99a0b2c&BACKTO=http%3A%2F%2F172.24.81.210%3A8080%2FzkInfoMargen%2F HTTP/1.1" 301 2018 "http://172.24.81.210:8080/zkInfoMargen/" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36"
172.24.81.210 - - [23/Sep/2016:15:27:31 +0200] "GET /sso/ntlmssov2/?authtoken=3c820a7a-27d0-4ab2-a966-cd7ed99a0b2c&BACKTO=http%3A%2F%2F172.24.81.210%3A8080%2FzkInfoMargen%2F HTTP/1.1" 302 596 "http://172.24.81.210:8080/zkInfoMargen/" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36"
172.24.81.210 - - [23/Sep/2016:15:27:31 +0200] "GET /sso/ntlmssov3?authtoken=3c820a7a-27d0-4ab2-a966-cd7ed99a0b2c&BACKTO=http%3A%2F%2F172.24.81.210%3A8080%2FzkInfoMargen%2F HTTP/1.1" 401 804 "http://172.24.81.210:8080/zkInfoMargen/" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36"

[...Here Chrome asks for user and password...]

172.24.81.210 - - [23/Sep/2016:15:27:43 +0200] "GET /sso/ntlmssov3?authtoken=3c820a7a-27d0-4ab2-a966-cd7ed99a0b2c&BACKTO=http%3A%2F%2F172.24.81.210%3A8080%2FzkInfoMargen%2F HTTP/1.1" 401 1397 "http://172.24.81.210:8080/zkInfoMargen/" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36"
172.24.81.210 - U874065 [23/Sep/2016:15:27:43 +0200] "GET /sso/ntlmssov3?authtoken=3c820a7a-27d0-4ab2-a966-cd7ed99a0b2c&BACKTO=http%3A%2F%2F172.24.81.210%3A8080%2FzkInfoMargen%2F HTTP/1.1" 301 916 "http://172.24.81.210:8080/zkInfoMargen/" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36"
172.24.81.210 - U874065 [23/Sep/2016:15:27:43 +0200] "GET /sso/ntlmssov3/?authtoken=3c820a7a-27d0-4ab2-a966-cd7ed99a0b2c&BACKTO=http%3A%2F%2F172.24.81.210%3A8080%2FzkInfoMargen%2F HTTP/1.1" 200 820 "http://172.24.81.210:8080/zkInfoMargen/" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36"

Both request were done from machines/users not in the AD domain, so automatically provided credentials are not valid.
VirtualBox_WinXP_23_09_2016_15_23_53.png
76.1 KB View Download

Comment 1 by eroman@chromium.org, Sep 26 2016

Components: Internals>Network>Auth

Comment 2 by asanka@chromium.org, Sep 27 2016

Components: -Enterprise
Labels: Needs-Feedback
Could you give us a net-internals log? Instructions can be found here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

That should give us more information about what happened in the client. There are some error conditions that we consider to be permanent and hence we stop trying to use that mechanism entirely for that connection.

Comment 3 by ek...@celestica.com, Oct 4 2016 

Chrome Version       : Google Chrome	55.0.2880.0 (Official Build) canary (32-bit)
URLs (if applicable) : http://eicc.labj.com/
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari: N/A
    Firefox: OK
         IE: OK

What steps will reproduce the problem?
(1) Visit http://eicc.labj.com
(2) 
(3)

What is the expected result?
Login prompt

What happens instead?
Error message:
This site can’t be reached

The webpage at http://eicc.labj.com/ might be temporarily down or it may have moved permanently to a new web address.
ERR_INVALID_HANDLE

Please provide any additional information below. Attach a screenshot if
possible.

Screenshot & net-internals attached.
We're experiencing similar difficulties trying to access http://eicc.labj.com/ behind a proxy server. Both the site and proxy use NTLM authentication, it is likely there is some confusion between proxy and site level auth. The issue is also seemingly intermittent, sometimes it does work as expected.
net-internals-log (2).json
185 KB View Download
CR_bug_report_649664.png
44.6 KB View Download

Comment 4 by asanka@chromium.org, Oct 5 2016 

Did the intermittent problems start recently?

The net log you sent indicates that Chrome received an invalid handle error from Windows when it attempted to authenticate with the server. The authentication handshake with the proxy appears to have suceeded.

Comment 5 by ek...@celestica.com, Oct 5 2016 

Hi,

According to our users, it's been seemingly happening since at least late August.

If it helps, attached is a log from 53.0.2785.143 (Official Build) m (32-bit). Are there any other troubleshooting steps you can recommend? 


NTLM proxy Auth is working fine, just the NTLM website Auth is failing, and Chrome isn't popping up the authentication box.
chrome_debug.log
47.9 KB View Download

Comment 6 by rdsmith@chromium.org, Oct 11 2016

Labels: -Needs-Feedback
Removing Needs-Feedback; doesn't look needed anymore.

Comment 7 by asanka@chromium.org, Oct 11 2016

Labels: M-56
Status: Available (was: Unconfirmed)
Yeah, INVALID_HANDLE is not an error we're handling particularly well. It's not one of the error codes which cause us to retry the authentication handshake. This shouldn't be difficult to address.

Do you see any relevant event logs on the client machine? I'm curious why this happens since we haven't seen this error condition before.

Comment 8 by ek...@celestica.com, Oct 11 2016 

Hi,

Nothing notable in the Windows event logs around this time of the page load. With SChannel event logging turned to 7 (https://support.microsoft.com/en-us/kb/260729), all it shows is that there is an information event, "Creating an SSL client credential", no errors.

Comment 9 by asanka@chromium.org, Nov 21 2016

Mergedinto: 648366
Status: Duplicate (was: Available)
I believe this should be addressed in  issue 648366 .
►

Sign in to add a comment