407 Authentification requise - pas de défi envoyé
https://stackoverflow.com/questions/1443617
-
22-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Mise à jour:
Si vous êtes juste arrivé à cette question, l'essentiel est que j'essaye de créer un HttpWebRequest via un proxy, et que je reçois un 407 de notre étrange serveur proxy. IE, Firefox et Chrome parviennent tous à négocier le proxy, de même que les applications Adobe Air. Il peut être important que le programme d’installation Web de Google Chrome échoue et que nous devions utiliser un programme d’installation hors connexion.
Grâce au lien de Ian, je parviens à l'étape suivante. Il envoie maintenant un jeton au proxy, mais la 3ème étape ne passe pas. Par conséquent, la requête contenant le hachage nom d'utilisateur / mot de passe n'est pas envoyée par .NET et, par conséquent, aucun code HTML n'est renvoyé.
J'utilise:
- agent utilisateur IE6
- Windows 7
- Proxy Scansafe
- .NET 3.5
Voici le dernier code correspondant aux journaux ci-dessous:
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();
L'exception
WebException (407) authentification requise.
Le proxy utilisé
Le client proxy est un périphérique Scansafe dans la salle des serveurs, qui (une fois authentifié avec NTLM) dirige ensuite votre trafic HTTP vers ses serveurs afin de le filtrer.
Sortie de suivi System.Net
IE négocie avec succès le proxy
La solution
Je n'ai pas vraiment trouvé de solution, mais grâce à Feroze et Eric, j'ai trouvé une solution de contournement et découvert que le proxy réel (et non sa configuration) est le problème principal. Cela peut être un problème obscur avec 3 variables: l'implémentation de .NET HttpWebRequest, Windows 7 et bien sûr le client matériel Scansafe qui se trouve dans notre rack; mais sans demande de support MSDN, je ne le saurai pas.
La solution
Si vous souhaitez définir des informations d'identification pour le proxy, ne devez-vous pas définir des informations d'identification sur l'objet request.Proxy plutôt que sur l'objet requête?
http://msdn.microsoft.com/ fr-us / library / system.net.webproxy.credentials.aspx
N'oubliez pas non plus que vous devez effectuer une requête HTTP / 1.1 (ou techniquement, toute requête avec Keep-Alive) pour utiliser avec succès l'authentification NTLM / Negotiate.
(L'inspecteur "Auth" de Fiddler va décomposer les blobs d'authentification NTLM pour vous, si vous ne l'avez pas encore regardé.)
Autres conseils
J'ai écrit un utilitaire pour décoder les blobs NTLM envoyés lors des sessions IE et HttpWebRequest.
Quand je regarde HttpWebRequest et IE, ils demandent tous les deux un chiffrement 56 bits et 128 bits au serveur. Voici le dump de la session utilisant 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
Voici le dump d'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
Dans les deux IE / HttpWebRequest, ils demandent à la fois 64 & amp; Sécurité 128bit. Toutefois, pour Windows7, la sécurité 128 bits pour NTLM est devenue la sécurité par défaut. Sans cela, l'authentification échouera. Comme vous pouvez le constater grâce à la réponse du serveur, celui-ci ne prend en charge que le cryptage 64 bits.
Le lien suivant contient une discussion sur un problème similaire rencontré par une autre personne. http: //social.msdn .microsoft.com / Forums / fr-fr / ncl / thread / f68e8878-53e9-4208-b589-9dbedf851198
Si IE fonctionne, et non l'application gérée, c'est parce que IE ne demande pas réellement NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_SIGN, qui nécessitent un cryptage. Cependant, HttpWebRequest demande les deux SEAL | SIGN. Cela nécessite un cryptage à 128 bits, alors que la manière dont IE initialise le NTLMSSP (sans SEAL & SIGN) ne nécessite pas de cryptage. Par conséquent, IE fonctionne, contrairement à HttpWebRequest. (voir le lien ci-dessus)
Je pense que si vous modifiez votre stratégie de sécurité pour autoriser le cryptage 64 bits pour NTLM, votre application de code géré fonctionnera. Vous pouvez également demander au fournisseur de proxy de prendre en charge le cryptage 128 bits pour NTLM.
J'espère que cela vous aidera.
J'avais un problème similaire et j'ai utilisé les astuces du billet suivant pour résoudre le problème:
Vérifiez le paramètre suivant dans secpol.msc . Cela a résolu notre problème.
Local Security Policy
Local Policies
Security Options
Network security: Minimum session security
Définir sur:
require 128 only for client.
Pouvez-vous essayer de définir l'en-tête User-Agent sur votre HttpWebRequest, avec la même valeur que celle définie par IE8?
Parfois, les serveurs ne contestent pas correctement si l'agent utilisateur ne correspond pas à leurs attentes.
espérons que cela aide.
Est-ce la manière dont le proxy est attribué?
proxy.Credentials = CredentialCache.DefaultCredentials;
La dernière fois que j'ai utilisé un proxy avec HttpWebRequest, il était attribué comme suit:
Attribuer un proxy à la demande:
request.Proxy.Credentials = Credentials.GetProxyCredentials();
Méthode d'appels:
public static ICredentials GetProxyCredentials()
{
return new NetworkCredential(AppConstants.Proxy_username, AppConstants.Proxy_password);
}
Configurer le proxy dans 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>
Cela pourrait être lié à ce qui se trouve dans votre "CredentialCache". Essayez ceci à la place:
proxy.Credentials = new NetworkCredential("username", "pwd", "domain");
Que diriez-vous de cela:
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();
