The first scenario is that of a successful communication (as you expect).
The second scenario (you referred to as case 3) is occurring because the browser is choosing the wrong header to send which is causing the failure.
The browser is sending a Negotiate step when it should be sending NTLM.
Proxy-Authenticate: Negotiate N1RM
It should be sending:
Proxy-Authenticate: NTLM N1RM
By sending the Negotiate step this is indicating that Kerberos authentication is being used, so the MWG acts accordingly.
For more information see here:
From my experience, we did try to make the Web Gateway accept NTLM tokens used with the "Proxy-Authenticate: Negotiate", but in the end the browser started having issues of its own (it rejected the challenge).
So to answer your question, MWG cannot had the NTLM authentication when Negoticate is used. The browser issue must be addressed for authentication to take place properly.
Let me know if any questions remain.
thank you for your answer. I was really looking for a confirmation of my suspects.
I ran out of time yesterday, but there is something that we can do with the rules, it will take a little magic though, I'll keep you posted.
I love magic! ;-)
Magic! See attached ruleset and screenshot below.
This appears to do the trick.
This is how it works:
1. Client makes request (no authentication information)
2. Proxy responds with all authentication methods it supports according to the auth settings used (Negotiate, NTLM, basic)
3. In the case that the client responds with the "Proxy-Authenticate: Negotiate NlRM...", Web Gateway will discard it, and respond with another 407, but WITHOUT the Negoticate auth method included.
4. The client will then reply with "Proxy-Authenticate: NTLM NlRM...".
5. The rest of NTLM authentication will take place without issue!
See screenshots below (labeled according to the steps listed above):
Please test it and let me know if it works.
it works like a charm!