407 Se requiere autenticación: no se envió ningún desafío

StackOverflow https://stackoverflow.com/questions/1443617

Pregunta

Actualización:
Si acaba de llegar a esta pregunta, la esencia general es que estoy tratando de hacer una HttpWebRequest a través de un proxy, y obtengo un 407 de nuestro extraño servidor proxy. IE, Firefox, Chrome logran negociar el proxy con éxito, al igual que las aplicaciones de Adobe Air. Puede ser importante que el instalador web de Google Chrome realmente falle y que tengamos que usar un instalador sin conexión.

Gracias al enlace de Ian, lo llevo a la siguiente etapa. Ahora está enviando un token de vuelta al proxy, sin embargo, la tercera etapa no se está completando, por lo que .NET no envía la solicitud con el hash de nombre de usuario / contraseña y, en consecuencia, no se devuelve HTML.

Estoy usando:

  • agente de usuario IE6
  • Windows 7
  • Proxy Scansafe
  • .NET 3.5

Aquí está el último código que equivale a los siguientes registros: 

HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
IWebProxy proxy = request.Proxy;
// Print the Proxy Url to the console.
if (proxy != null)
{
    // Use the default credentials of the logged on user.
    proxy.Credentials = CredentialCache.DefaultCredentials;
}
request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
request.Accept = "*/*";

HttpWebResponse response = request.GetResponse() as HttpWebResponse;
Stream stream = response.GetResponseStream();

La excepción

  

Se requiere autenticación WebException (407).

El proxy que se utiliza

El cliente proxy es un Scansafe dispositivo de hardware en nuestra sala de servidores, que (una vez autenticado con NTLM) luego dirige su tráfico HTTP a sus servidores para filtrar el tráfico.

Salida de seguimiento de System.Net

IE negociando con éxito el proxy

La solución

Realmente no he encontrado una solución, pero gracias a Feroze y Eric, he encontrado una solución y descubrí que el proxy real (y no su configuración) es el problema principal. Puede ser un problema oscuro con 3 variables: la implementación de .NET HttpWebRequest, Windows 7 y, por supuesto, el cliente de hardware Scansafe que se encuentra en nuestro rack; pero sin una solicitud de soporte de MSDN no lo descubriré.

¿Fue útil?

Solución

Si desea establecer credenciales para el proxy, ¿no debería establecer credenciales en el objeto request.Proxy en lugar del objeto request?

http://msdn.microsoft.com/ es-es / library / system.net.webproxy.credentials.aspx

Además, tenga en cuenta que debe realizar una solicitud HTTP / 1.1 (o técnicamente, cualquier solicitud con Keep-Alive) para utilizar con éxito la autenticación NTLM / Negotiate.

(El inspector de "Autenticación de Fiddler" descompondrá los blobs de autenticación NTLM por usted, si aún no lo ha examinado).

Otros consejos

Escribí una utilidad para decodificar los blobs NTLM que se enviaron en las sesiones IE y HttpWebRequest.

Cuando miro el HttpWebRequest y el IE, ambos solicitan cifrado de 56 bits y 128 bits del servidor. Aquí está el volcado de la sesión usando HttpWebRequest 

==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: E20882B7
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
RESERVED2
RESERVED3
RESERVED4
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLM_NEGOTIATE_OEM
NTLMSSP_NEGOTIATE_UNICODE)
Domain :
Workstation:
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA

Aquí está el volcado de IE: 

==== Type1 ----
Signature: NTLMSSP
Type: 1
Flags: A208B207
NTLMSSP_NEGOTIATE_56
NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP_NEGOTIATE_128
NTLMSSP_REQUEST_NON_NT_SESSION_KEY
NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
NTLMSSP_TARGET_TYPE_SHARE
NTLMSSP_TARGET_TYPE_DOMAIN
NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
NTLMSSP_NEGOTIATE_DATAGRAM
NTLMSSP_REQUEST_TARGET
NTLMSSP_NEGOTIATE_UNICODE)
Domain : XXXX.UK
Workstation: XXX-X31
==== Type2 ----
Signature: NTLMSSP
Type: 2
Flags: 201
NTLMSSP_NEGOTIATE_56
NTLMSSP_REQUEST_NON_NT_SESSION_KEY)
Context: D32FDDCB:63507CFA

En IE / HttpWebRequest, solicitan 64 & amp; Seguridad de 128 bits. Sin embargo, para Windows 7, la seguridad de 128 bits para NTLM se ha convertido en la predeterminada, y sin eso, la autenticación fallará. Como puede ver en la respuesta del servidor, el servidor solo admite el cifrado de 64 bits.

El siguiente enlace tiene una discusión sobre un problema similar encontrado por otra persona. http: //social.msdn .microsoft.com / Forums / es-ES / ncl / thread / f68e8878-53e9-4208-b589-9dbedf851198

La razón por la que IE funciona, en lugar de la aplicación administrada, es que IE no solicita NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_SIGN, que terminan requiriendo cifrado. Sin embargo, HttpWebRequest solicita ambos SEAL | SIGN. Esto requiere un cifrado de 128 bits, mientras que la forma en que IE inicializa el NTLMSSP (sin SEAL & amp; SIGN), no requiere cifrado. Por lo tanto, IE funciona, mientras que HttpWebRequest no. (ver el enlace de arriba)

Creo que si cambia su política de seguridad para permitir el cifrado de 64 bits para NTLM, su aplicación de código administrado funcionará. O, alternativamente, solicite al proveedor de proxy que admita cifrado de 128 bits para NTLM.

Espero que esto ayude.

Estaba teniendo un problema similar y usé los consejos en la siguiente publicación de blog para resolver el problema:

http://blogs.msdn.com/jpsanders/archive/2009/03/24/httpwebrequest-webexcepton-the-remote-server-returned-an-error-407-proxy -authentication-required.aspx

Verifique la siguiente configuración en secpol.msc . Solucionó nuestro problema. 

Local Security Policy 
    Local Policies
        Security Options
            Network security: Minimum session security

Establecer en: 

require 128 only for client.

ingrese la descripción de la imagen aquí

¿Puede intentar configurar el encabezado User-Agent en su HttpWebRequest, con el mismo valor que está configurando IE8?

A veces, los servidores no desafiarán correctamente si el agente de usuario no es lo que esperan.

espero que esto ayude.

¿Es la forma en que se asigna el proxy? 

proxy.Credentials = CredentialCache.DefaultCredentials;

La última vez que utilicé proxy con HttpWebRequest se asignó así:

Asignar proxy para solicitar: 

request.Proxy.Credentials = Credentials.GetProxyCredentials();

Método de llamadas: 

    public static ICredentials GetProxyCredentials()
    {
        return new NetworkCredential(AppConstants.Proxy_username, AppConstants.Proxy_password);
    }

Configurar proxy en web.config 

<system.net>
  <defaultProxy enabled="true">
    <proxy
      autoDetect="False"
      bypassonlocal="True"
      scriptLocation="http://www.proxy.pac"
      proxyaddress="http://proxy1.blah.com" />
  </defaultProxy>
</system.net>

Podría estar relacionado con lo que está en su " CredentialCache " ;. Intente esto en su lugar: 

proxy.Credentials = new NetworkCredential("username", "pwd", "domain");

¿Qué tal esto? 

        HttpWebRequest request = HttpWebRequest.Create("http://www.yahoo.com") as HttpWebRequest;
        WebProxy proxyObject = new System.Net.WebProxy("http://10.0.0.1:8080/", true); //whatever your proxy address is

        proxyObject.Credentials = CredentialCache.DefaultCredentials;
        request.Proxy = proxyObject;

        request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705;)";
        request.Accept = "*/*";

        HttpWebResponse response = request.GetResponse() as HttpWebResponse;
        Stream stream = response.GetResponseStream();
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top