the error template is the same for all. The response essentially triggers the authentication process in the browser. In case the authentication isn't succesful the browser will display the error message, that's why it is being send.
basically the behaviour should be as follows (if I recall correctly):
1.) Client sends a GET request without any authentication information
2.) MWG replies with a 407 with an HTML body. Clients not capable to perform authentication will show this page to inform the user that access was not possible.
3a.) Integrated Authentication: Client sends NTLMSSP NEGOTIATE message to initate NTLM handshake
3b.) Basic Authentication: Client shows a popup, user enters credentials and submits them.
4a.) Integrated Authentication: MWG sends a 407 with NTLMSSP CHALLENGE message. This usually does not have an HTML body as we know the client is able to perform authentication
4b.) Basic Authentication: Website is delivered
5.) Integrated Authentication: Client sends GET request with NTLMSSP AUTH message
6.) Integrated Authentication: Website is delivered
So if you see this behaviour it should be OK. It is the same for all customers using authentication and should not cause you any delays. I am not aware of DNS related issues. I think it would be helpful if you could provide some more information about the issue you are encountering, so that we can think about where to start looking?
Thank you very much. That is the observed behaviour.
It appears that every HTTP GET is authenticated (as per troubleshooting logs) going through the cycle you described.
Authentication cache HIT aside the HTML content is still sent to the client for every GET. Considering a website may have 50+elements it seems inefficient considering the client has already authenticated.
this needs to be carefully looked at. When you say "every GET is authenticated" we should proof this. Looking at a deeper level to what I wrote above, this is how MWG decides whether to send a 407 or not:
1.) You browse to www.spiegel.de (just an example site with many objects)
2.) Firefox (or whatever browser you use) openes multiple TCP connections to MWG (the browser decides how many)
3.) In each TCP connection (identified by Src IP, Dst iP, Src Port and Dst Port) the first GET request will be answered with a 407.
4.) Authentication is performed
5.) Now this specific request is authenticated, which also means that the current TCP session is authenticated. After the first 200 OK by MWG, all following GET request on the same TCP connection (identified by Src IP, Dst iP, Src Port and Dst Port) will not be authenticated again.
So if Firefox opens 10 TCP connections, there will be authentication 10 times. If there are 500 objects transferred in this 10 connections, there will still be 10 times authentication, not 500 times, as authentication is per connection, not per request.
I recommend to run a tcpdump for a specific client IP and browse a website. Pick any GET request, and do "Follow TCP Dump" in Wireshark. If you scroll down, you should notice that the first request is authenticated, while the others (following the first 200 response) are allowed right away, with no further 407.
If this is the case, all is good. If you really see that all GET requests are answered with a 407, there may be something wrong in the policy. I have seen this once at a customer, which resulted in a very bad performance, as you would (following the example) perform 500x authentication, instead of 10.
Note: From time to time you can see that in one TCP session GET requests are coming in faster than they are authenticated and answered. You need to pay attention to this. If you find one 200 response you will need to find a GET request after that 200 response that has no NTLMSSP headers in it to proof what I explained above. If you see a 200 and then a GET with NTLMSSP headers this means that authentication is already "going on"... this authentication will be finished, we do not interrupt the authentication process for a request in the middle when a different request was authenticated.
I hope this helps.