@ bobbyjose00: If shareable could you please provide a URL which you are using, that would help us in triaging the issue from TE-end

I cant.. since its an internal website. 
I thought this would be a more generic issue. Chrome is seriously having issues one after the another. My previous issue is still tagged as to be fixed in next release and i had to do a work around that time.

I guess I will have to advice to use Firefox at organization level.

Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

When i first land on the website, it gives the prompt and when the user enters the wrong password, its a 401 error status in fiddler. But all other browsers keep showing the prompt, and if the user enters wrong password 3 times, account gets locked (as per company policy) and my webserver redirects to my Unauthorized access page (Ideal behaviour). It was same even for chrome till last week.

But now in chrome, when user enters wrong password the first time, it shows the chrome internal error page (See attached) and no more shows the prompt. So is it some setting change in chrome ? Because its not like the user account is locked and its not showing the error page from web server. 

As far as reproducing, its just an internal website, which uses Active directory authentication. 

Deleted: Error.png 27.0 KB

	Error.png 27.0 KB View Download

Requesting someone from respective team to take a look into it.

Is the auth prompt you are expecting a browser dialog, or is the login screen on the webpage?

(in other words, is this issue about HTTP auth / NTLM)

browser dialog

Thank you for providing more feedback. Adding requester "eroman@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Can you capture a netlog dump of the problem and attach it here?

https://dev.chromium.org/for-testers/providing-network-details

Here is the export log

Deleted: chrome-net-export-log.json 823 KB

chrome-net-export-log.json 823 KB View Download

Thank you for providing more feedback. Adding requester "eroman@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for providing the log.

The log shows a navigation to http://testjoe.com, and the server gave an HTTP auth challenge using NTLM.

This was subsequently handled by the LastPass extension, which provided credentials, and then the request ultimately failed with ERR_ACCESS_DENIED.

So I imagine the reason you aren't seeing an auth prompt dialog is because it is being intercepted by LastPass, which is perhaps providing an incorrect password.

This looks to be an extension problem. Have you tried disabling Last Pass?

I think what's happening is InitializeSecurityContext fails with SEC_E_LOGON_DENIED which gets mapped to ERR_ACCESS_DENIED. Instead it should really be mapped to ERR_INVALID_AUTH_CREDENTIALS which signals to the HttpAuthController that the supplied credentials were rejected. The latter then allows the network transaction to have another go-around and prompt the user again. For comparison ERR_ACCESS_DENIED is a dead end.

SEC_E_LOGON_DENIED is documented to mean "The logon failed," which I believe is safe to interpret as ERR_INVALID_AUTH_CREDENTIALS. Both of these errors imply that either the password was incorrect for the user or the user wasn't allowed to authenticate in the first place.

In general, a password error or a login error shouldn't terminate the network transaction since that would preclude from recovering from a user error.

Also for comparison, we currently map SEC_E_NO_CREDENTIALS and SEC_E_WRONG_PRINCIPAL to ERR_INVALID_AUTH_CREDENTIALS. We should play around and see why we aren't seeing SEC_E_LOGON_DENIED more frequently (always falling back to NTLM where this problem is only detectable on the server side?).

So the work that needs to happen here is (feel free to disagree):

* Find out when the UA would see SEC_E_LOGON_DENIED during token generation.
* Map SEC_E_LOGON_DEINED to ERR_INVALID_AUTH_CREDENTIALS and make sure we can restart the transaction.

Even if i disable lastpass the issue remains the same.

And firefox has lastpass extension too and its not an issue there. Even in chrome, it was working till few weeks back.

As long as the users account is not locked, chrome must show the prompt so that the user can re-enter the password 2nd or 3rd time. 

Will this issue be fixed with next release ? Is there a timeline ?
Else I will have to advise at an organisational level to move to firefox, because of these inconsistencies.
Users will just create support tickets/call helpdesk when they see Access denied message on first attempt and will not realize it was wrong password issue.

I dont want to take that call, since we have been testing in chrome for all these years. IE and firefox has been like an after thought.