Do you know if the site is using session-based-authentication? I would guess that MWG is prompting for auth again because the server requests it. If you are POSTing data then I have seen funky behavior with browsers from time to time not maintaining the creds, but I cant really comment without connection traces (for which it would be best if a support case was opened).
Hi Jon, and sorry for my late response.
Yes, it is a POST command
Yes, the site is using session based authentication.
From a network trace on the client (the webservers first 401 unauthorized, negotiate)
Via: <name of McAfee Web Gateway>
Proxy-support is listed twice, but that is also the case in the web servers response to a GET command.
And authentication to the web server works fine for GET commands.
The authentication sequence is exactly the same for GET and POST:
1. Client sends anonymous GET/POST
2. Webserver responds with 401 unauthorized, negotiate
3. Client replies with a new GET/POST using NLMP authorization (NTLM negotiate message)
4. Webserver replies with 401 unauthorized, using NLMP authentication (NTLM challenge message)
5. Client replies with a last GET/POST using NLMP authorization (NTLM authenticate message)
In step 3 and 5 the client sends a cookie with ASP.NET_sessionid.
The sessionid is the same in both.
For a GET command the webservers reply to step 5 is:
6. 200 OK
For a POST command the webservers reply to step 5 is:
6. 401 unauthorized, negotiate (back to step 2 above).
Since the whole authentication proccess, step 1 to 5, flows as normal also for the POST command, I suspect that MWG doesn't forward the clients NTLM authenticate message (step 5) correct.
I haven't managed to get a tcpdump taken on the MWG yet, I don't have access to do it myself.
In our configuration we use squid as next hop proxy.
Bypassing the next hop proxy for the site authentication failed on solved the problem.
Message was edited by: Arild on 6/10/10 4:14:05 AM CDT