407 Authentifizierung erforderlich - keine Abfrage gesendet

8

Aktualisierung:
Wenn Sie gerade bei dieser Frage angekommen sind, besteht die allgemeine Aussage darin, dass ich versuche, eine HttpWebRequest über einen Proxy zu machen, und ich bekomme einen 407 von unserem seltsamen Proxy-Server. IE, Firefox, Chrome verwalten den Proxy erfolgreich, ebenso wie Adobe Air-Anwendungen. Es kann wichtig sein, dass das Google Chrome-Web-Installationsprogramm fehlschlägt und wir ein Offline-Installationsprogramm verwenden müssen.

Dank Ians Verbindung habe ich es bis zur nächsten Stufe geschafft. Es sendet jetzt ein Token zurück an den Proxy, aber die dritte Stufe kommt nicht durch, daher wird die Anfrage mit dem Benutzernamen / Passwort-Hash nicht von .NET gesendet und folglich wird kein HTML zurückgegeben.

Ich verwende:

  • IE6 Benutzeragent
  • Windows 7
  • ScanSafe-Proxy
  • .NET 3.5

Hier ist der neueste Code, der den folgenden Logs entspricht:

%Vor%

Die Ausnahme

  

WebException (407) Authentifizierung erforderlich.

Der verwendete Proxy

Der Proxy-Client ist ein Scansafe Hardware-Gerät in unserem Serverraum, das (sobald es mit NTLM authentifiziert wurde) Ihre Daten anleitet HTTP-Verkehr zu seinen Servern, um den Verkehr zu filtern.

System.Net Ablaufverfolgung

IE hat den Proxy

erfolgreich ausgehandelt

Die Lösung

Ich habe nicht wirklich eine Lösung gefunden, aber dank Feroze und Eric habe ich einen Workaround gefunden und festgestellt, dass der eigentliche Proxy (und nicht seine Konfiguration) das Hauptproblem ist. Es kann ein obskures Problem mit 3 Variablen sein: .NET HttpWebRequest-Implementierung, Windows 7 und natürlich der Scansafe-Hardware-Client, der in unserem Rack sitzt; aber ohne eine MSDN-Supportanfrage werde ich es nicht herausfinden.

    
Chris S 09.05.2010, 21:40
quelle

8 Antworten

8

Wenn Sie Anmeldeinformationen für den Proxy festlegen möchten, sollten Sie keine Anmeldeinformationen für das request.Proxy-Objekt und nicht für das Anforderungsobjekt festlegen?

Ссылка

Beachten Sie auch, dass Sie eine HTTP / 1.1-Anfrage (oder technisch gesehen, eine Anfrage mit Keep-Alive) machen müssen, um die NTLM / Negotiate-Authentifizierung erfolgreich zu nutzen.

(Fiddlers "Auth" -Inspektor wird die NTLM-Authentifizierungs-Blobs für Sie zerlegen, falls Sie sich das noch nicht angesehen haben.)

    
EricLaw 22.09.2009, 05:17
quelle
6

Ich habe ein Dienstprogramm geschrieben, um die NTLM-Blobs zu decodieren, die in den IE- und HttpWebRequest-Sitzungen gesendet wurden.

Wenn ich mir HttpWebRequest und IE anschaue, fordern beide vom Server 56-Bit- und 128-Bit-Verschlüsselung an. Hier ist der Dump der Sitzung mit HttpWebRequest

%Vor%

Hier ist der Dump von IE:

%Vor%

In beiden IE / HttpWebRequest fordern sie sowohl 64 & amp; 128-Bit-Sicherheit. Für Windows7 wurde jedoch 128-Bit-Sicherheit für NTLM als Standard festgelegt, und ohne diese wird die Authentifizierung fehlschlagen. Wie Sie anhand der Serverantwort sehen können, unterstützt der Server nur die 64-Bit-Verschlüsselung.

Der folgende Link enthält eine Diskussion über ein ähnliches Problem, auf das eine andere Person gestoßen ist. Ссылка

Der Grund dafür, dass IE anstelle der verwalteten App funktioniert, ist, dass der IE NTLMSSP_NEGOTIATE_SEAL | nicht tatsächlich anfordert NTLMSSP_NEGOTIATE_SIGN, die letztendlich eine Verschlüsselung erfordern. HttpWebRequest fordert jedoch beide SEAL | SIGN an. Dies erfordert eine 128-Bit-Verschlüsselung, während die Art und Weise, wie IE den NTLMSSP initialisiert (ohne SEAL & amp; SIGN), keine Verschlüsselung erfordert. Daher funktioniert IE, während HttpWebRequest nicht funktioniert. (siehe obigen Link)

Ich denke, wenn Sie Ihre Sicherheitsrichtlinie ändern, um 64-Bit-Verschlüsselung für NTLM zuzulassen, wird Ihre App mit verwaltetem Code funktionieren. Oder fragen Sie den Proxy-Anbieter alternativ, 128-Bit-Verschlüsselung für NTLM zu unterstützen.

Hoffe, das hilft.

    
feroze 26.09.2009 23:51
quelle
3

Ich hatte ein ähnliches Problem und habe die Tipps im folgenden Blogpost verwendet, um das Problem zu lösen:

Ссылка

    
Ian Kemp 18.09.2009 10:36
quelle
1

Überprüfen Sie die folgende Einstellung in secpol.msc . Es hat unser Problem behoben.

%Vor%

Legen Sie Folgendes fest:

%Vor%

    
Jay Walker 05.03.2013 17:13
quelle
0

Können Sie versuchen, den User-Agent-Header in Ihrem HttpWebRequest auf denselben Wert einzustellen, den IE8 setzt?

Manchmal werden Server nicht korrekt herausgefordert, wenn der User-Agent nicht den Erwartungen entspricht.

hoffe das hilft.

    
feroze 19.09.2009 03:11
quelle
0

Ist der Proxy so zugewiesen?

%Vor%

Als ich das Proxy zuletzt mit der HttpWebRequest benutzt habe, wurde es wie folgt zugewiesen:

Proxy der Anfrage zuweisen:

%Vor%

Ruft Methode:

%Vor%

Konfigurieren Sie den Proxy in web.config

%Vor%     
CRice 25.09.2009 04:41
quelle
0

Es könnte damit in Verbindung stehen, was in Ihrem "CredentialCache" enthalten ist. Versuchen Sie es stattdessen:

%Vor%     
Shiraz Bhaiji 25.09.2009 14:55
quelle
0

Wie wäre es damit:

%Vor%     
lod3n 25.09.2009 21:39
quelle