3 Replies Latest reply on Jun 18, 2010 8:04 PM by Arild

    Upload (http) to web sites that requires authentication fails through MWG

      When trying to upload files to web sites that requires windows authentication, I am prompted for credentials three times before the web server returns "401 Unauthorized".

      Download from the same server works fine.

      The web server is in a domain with trust relationship to the domain the MWG and the client are in, and I have necessary rights to upload files to the directory (it also work through another proxy (Isa Server) in same domain as the MWG).

      When monitoring the network traffic on the client I see that it sends the www authorization header in response to the servers www authenticate challenge.

      My guess is that MWG doesn't forward it, or alter it in some way, for uploads.

      Why it does so is beyond my understanding.

      It can't be for security reasons, since it forwards it perfectly when downloading.

      Whitelisting the webserver does not make any difference. Neighter does bypassing the ICAP server.

       

      Does anyone have a solution for this problem?

      Bypassing the proxy is not the answer I hope for.

       

      The MWG is v.6.8.6, running on Linux.

        • 1. Re: Upload (http) to web sites that requires authentication fails through MWG
          Jon Scholten

          Hello Arild,

           

          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).

           

          ~jon

          • 2. Re: Upload (http) to web sites that requires authentication fails through MWG

            Hi Jon, and sorry for my late response.

             

            Yes, it is a POST command

            and

            Yes, the site is using session based authentication.

            From a network trace on the client (the webservers first 401 unauthorized, negotiate)

            ProxyConnection:     keep-alive

            Proxy-support:          Session-Based-Authentication

            Proxy-support:          Session-Based-Authentication

            Server:                     Microsoft-IIS/6.0

            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.

            • 3. Re: Upload (http) to web sites that requires authentication fails through MWG

              Solved!

               

              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

               

               

              Message was edited by: Arild on 6/18/10 8:04:22 PM CDT