Grâce au lien de Ian, j'ai eu la suivante. Il envoie maintenant un jeton de retour au proxy, mais la 3ème étape ne réussit pas, de sorte que la demande avec le nom de nom d'utilisateur / mot de passe n'est pas envoyée par .NET et, par conséquent, aucun code HTML n'est renvoyé. < P> J'utilise: Voici le dernier code qui équivaut aux journaux ci-dessous: l'exception WebException (407) Authentification requise.
Le client proxy est un scansafe < / a> Dispositif matériel dans notre salle serveur, qui (une fois authentifié avec NTLM), dirige ensuite votre trafic HTTP sur ses serveurs pour filtrer le trafic. Je n'ai pas vraiment trouvé de solution, mais grâce à Feroze et à Eric j'ai trouvé une solution de contournement et découvrit que le proxy réel (et non sa configuration) est le principal problème. Il peut s'agir d'un problème obscur avec 3 variables: .NET HTTPWEBREQUEST's Mise en œuvre, Windows 7 et bien sûr le client Hardware ScanSafe qui se trouve dans notre rack; Mais sans une demande de support MSDN, je ne le découvrirai pas.
Si vous venez d'arriver à cette question, le Gist général est que j'essaie de faire un httpwebrequest via un proxy et que je reçois un 407 à partir de notre serveur proxy étrange. IE, Firefox, Chrome parvient tous à négocier le proxy de manière successive, de même que les applications Adobe Air. Il est peut-être important que le programme d'installation de Google Chrome Web échoue et que nous devons utiliser un programme d'installation hors ligne.
Le proxy étant utilisé
sortie de traçage système.net
c'est-à-dire négocier successivement le proxy
la solution
8 Réponses :
J'avais un problème similaire et j'ai utilisé les conseils dans le blog suivant pour résoudre le problème:
Merci pour le lien. Il reçoit maintenant à la demande / réponse 2 comme ci-dessus et obtient un 407
Pouvez-vous obtenir un journal System.net et collez-le ici? Voici les instructions: Ferozedaud.Blogspot.com/2009/08/RACING -with-systemnet.html
Ok, j'ai regardé le fichier journal System.net que vous avez attaché. Il semble qu'il existe une incompatibilité entre les capacités d'auth / sécurité de la machine client et du proxy. Pouvez-vous nous dire quel est le système d'exploitation sur le client et le système d'exploitation sur le proxy? En outre, quel type de serveur proxy utilisez-vous?
De plus, pouvez-vous condenser votre code à un fichier simple, compilable, un fichier de console qui démontre le problème? Je pense que je pourrais avoir une idée pourquoi cela ne fonctionne pas pour vous, mais j'ai besoin de voir le code en premier. De plus, comme mentionné précédemment, j'ai besoin de connaître le système d'exploitation que vous exécutez sur le serveur client et proxy, ainsi que le logiciel de serveur proxy.
Proxy Server est un client ScanSafe (et serveur) et Windows 7
En regardant le journal System.net, je vois que le package NTLM sur le client n'aime pas le jeton authentifiant envoyé par le serveur. Quand j'ai googlé, j'ai trouvé des liens qui pourraient aider à comprendre ceci:
Ou alternativement, vous pouvez afficher votre question sur la NCL Microsoft Newsgroups (social.msdn.microsoft.com/forums/en-us/ncl) et certains DV NCL peuvent vous aider à sortir. Ou, vous pouvez ouvrir un incident de support avec Microsoft PSS.
Si vous voulez obtenir le journal NTLM, je peux regarder et voir si je peux comprendre ce qui se passe. Ou sinon, vous pouvez vous suivre avec NCL Newsgroup ou Microsoft PSS. Bonne chance!
Windows 7 Ultimate. Le proxy est un ScanSafe One, un périphérique matériel. Mon installation Windows 7 n'a pas eu le nœud INET dans l'arborescence de la visionneuse d'événements, donc je ne peux pas obtenir les journaux NTLM. Les journaux de violoneux avaient très peu dans l'onglet d'authentification que Eric parlait de. Je suis toujours un peu confus quant à la raison pour laquelle certaines applications (qui n'utilisent pas le wrapper .NET autour de Wininet) n'ont aucun problème, mais cela rampe probablement dans les domaines d'un ticket de support MSDN au lieu de l'utiliser. .
Lorsque vous dites que c'est-à-dire que c'est capable de se connecter, fournissez-vous explicitement explicitement votre nom d'utilisateur / mot de passe / domaine à IE, ou est-ce que c'est-à-dire en ramenant les informations d'identification connectées aux utilisateurs? Lorsque je regarde la différence de demande NTLM entre les sessions IE et httpwebrequest, je vois que c'est-à-dire que c'est-à-dire d'envoyer des informations de domaine (xxxx.uk) et du poste de travailInfo, alors que httpwebrequest n'est pas. Pouvez-vous essayer de définir des informations d'identification explicites sur le proxy et voir si cela fonctionne?
Pouvez-vous essayer de définir l'en-tête d'agent utilisateur sur votre httpwebrequest, à la même valeur que cE8 se définit?
Parfois, les serveurs ne défieront pas correctement si l'agent utilisateur n'est pas ce qu'ils attendent.
J'espère que cela aide.
Même se produit quel que soit l'agent utilisateur
Si vous souhaitez définir des informations d'identification pour le proxy, ne devriez-vous pas définir les informations d'identification sur la demande.proxy objet plutôt que l'objet de la demande?
http://msdn.microsoft.com/ fr-US / bibliothèque / system.net.webproxy.credentials.aspx
Aussi, gardez à l'esprit que vous devez effectuer une demande HTTP / 1.1 (ou techniquement toute demande avec Keep-Vive) pour utiliser avec succès l'authentification NTLM / négociation.
(L'inspecteur "Auth" de Fiddler décomposera la NTLM Authentication Blobs pour vous, si vous n'avez pas encore examiné cela.)
Les informations d'identification des proxy sont en cours de définition, j'ai l'impression que la deuxième partie de l'authentification est l'endroit où les détails de NTLM ne sont pas retournés, mais dans
La demande est HTTP 1.1 à la manière - httpwebrequest # 39785641 - Demande: obtenez http://www.yahoo.com/ http / 1.1
La demande est HTTP / 1.1, mais il est intéressant de noter que la réponse indique que la sémantique HTTP / 1.0 doit être utilisée.
Fait intéressant, le serveur proxy ne renvoie pas l'en-tête de réponse HTTP «Proxy-Support: Authentification basée sur la session». Cet en-tête est absolument nécessaire pour l'utilisation de NTLM / négociate pour l'authentification www, et je ne serais pas terriblement surpris d'apprendre que .Net le requiert pour l'authentification proxy. Il devrait être assez simple de tester avec violoneur ...
Ma solution a été de télécharger le proxy CC et de passer via ceci au proxy pour l'instant, ce qui corrige le problème. C'est-à-dire d'être envoyé les bons en-têtes que je ne peux pas comprendre, et c'est le proxy CC. J'ai mis à jour le message pour que vous puissiez voir ce qu'il enverra. Serait-il une raison pour laquelle cela n'enverrait pas les bons en-têtes de retour à un client, mais les bons à un autre?
Les commentaires de Feroze ci-dessous point sur le jeton NTLM ne sont pas envoyés correctement
Si vous publiez réellement le fichier .saz de Fiddler ou utilisez simplement l'onglet Auth, vous pouvez voir les blobs NTLM décomposés et voir ce qui diffère entre le cas IE et votre cas d'application. La ligne n ° 192 semble être la clé de votre logiciel System.net. Le code appelle InitialiseSecurityContext avec le drapeau délégué, mais le package NTLM ne prend pas en charge ISC_REQ_DELEGATE, de sorte que ISC renvoie SEC_E_UNSUPPORTED_Function.
Consultez mon commentaire ci-dessous, vous devez développer la liste de commentaires pour le voir. Comme je l'ai déjà dit, cela pourrait être dû à des mises à jour de sécurité à Vista. Pour enquêter plus avant, nous aurons besoin d'un journal NTLM de votre ordinateur client ayant la défaillance, ainsi qu'un journal NTLM du cas de réussite avec IE. Cela peut nous aider à déboguer cela plus loin.
Je vois aussi une légère différence dans la sortie violoneuse vs le journal .net. C'est-à-dire semble envoyer un cookie dans la demande d'obtention. Cela pourrait-il avoir quelque chose à voir avec ça? Peut-être que le proxy nécessite ce cookie?
Eric, j'ai remarqué que le drapeau délégué est passé à ISC. Toutefois, notez que lorsque ISC a été appelé avec le drapeau des délégués, cela a fonctionné bien et a rendu le jeton Auth pour envoyer au serveur. C'est juste que cela n'aime pas le jeton d'authentifié renvoyé par le serveur.
Chris, est-il possible d'essayer le scénario .NET avec un nom d'utilisateur / mot de passe différent que le proxy prend en charge?
Je vais avoir les journaux (violoncière et NTLM) demain. Le cookie vient d'une visite précédente dans IE, j'aurais dû effacer le cache d'abord.
Chris, pouvez-vous clarifier à nouveau sur le système d'exploitation? Sont à la fois client et serveur WIN7? Également par Win7, voulez-vous dire Windows Server 2008R2 pour serveur (et client) ou voulez-vous dire Windows7, c'est-à-dire l'une des nombreuses saveurs du client Win7?
(Les commentaires ici sont la vraie réponse)
Devinez ce que j'ai aussi ce problème - je n'ai pas de solution mais j'ai un peu plus d'informations. Le code regarde bien pour moi et je fais pas pense que NTLM est sensible au modèle du code. Cependant, j'ai trouvé que le même code qui échoue sur Vista / Win7 / 2008 / Lors de la construction avec VS2008 Ciblage .NET35 fonctionnera lors de la compilation avec le ciblage VS2010 .NET4. Ce problème ne semble affecter que Vista / Win7 / 2008, le code .NET 35 et .NET 4 fonctionne bien sur XP / 2003.
Est-ce la façon dont le proxy est attribué?
<system.net>
<defaultProxy enabled="true">
<proxy
autoDetect="False"
bypassonlocal="True"
scriptLocation="http://www.proxy.pac"
proxyaddress="http://proxy1.blah.com" />
</defaultProxy>
</system.net>
J'ai essayé toutes les variantes de chaque propriété possible avec le proxy et les informations d'identification :) C'est définitivement la négociation NTLM
Cela pourrait être lié à ce qui se trouve dans votre "CredentialCache". Essayez cela à la place:
proxy.Credentials = new NetworkCredential("username", "pwd", "domain");
Que diriez-vous:
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();
J'ai écrit un utilitaire pour décoder les blobs NTLM envoyés dans les sessions IE et httpwebrequest.
Lorsque je regarde le httpwebrequest et, c'est-à-dire qu'ils demandent à la fois un cryptage 56 bits et 128 bits à partir du serveur. Voici la vidage de la session à l'aide de httpwebrequest Voici la décharge de IE: dans les deux c.-à-Pro Httpwebrequest, ils demandent la sécurité de 64 et 128 bits. Toutefois, pour Windows7, la sécurité 128 bits pour NTLM a été faite par défaut et sans cela, l'authentification échouera. Comme vous pouvez le constater à partir de la réponse du serveur, le serveur ne prend en charge que 64 bitscryption. Le lien suivant présente une discussion sur un problème similaire rencontré par une autre personne.
http: //social.msdn .microsoft.com / Forums / FR-US / NCL / Fil / F68E8878-53E9-4208-B589-4208-B589-420878-53E9-420878-53E9-420878-53E9-9DBEDF851198 La raison pour laquelle cela fonctionne, au lieu de l'application gérée, est que c'est-à-dire ne demande pas réellement ntlmsp_negotiate_seal | Ntlmsp_negotiate_sign, qui finit par nécessiter de cryptage. Cependant, httpwebrequest demande à la fois sceau | signe. Cela nécessite un cryptage 128 bits, alors que c'est-à-dire que c'est-à-dire initialise le NTLMSSP (sans scelle et signe), il ne nécessite pas de cryptage. Par conséquent, c'est-à-dire fonctionne, alors que httpwebrequest ne le fait pas. (Voir le lien ci-dessus) Je pense que si vous modifiez votre stratégie de sécurité pour permettre au cryptage 64 bits pour NTLM, votre application de code gérée fonctionnera. Ou alternativement, demandez au fournisseur de proxy de prendre en charge le cryptage 128 bits pour NTLM. J'espère que cela aide.
Je ne peux malheureusement pas changer la politique de sécurité car elle est large pour environ 600 personnes. Merci pour le temps que vous avez passé à creuser ces informations
Vérifiez le paramètre suivant dans secpol.msc code>. Il a fixé notre problème. require 128 only for client.