Wie Windows-Authentifizierung über einen Reverse-Proxy aktivieren?

Question

Es tut mir leid, wenn es ein Duplikat ist, da ich weder ein Sicherheitsexperte noch ein Netzwerkexperte bin, habe ich den richtigen Jargon verpasst, um Informationen zu finden.

Ich arbeite an einer Anwendung zum Abfangen und Ändern von HTTP-Anfragen und Antworten zwischen einem Webbrowser und einem Webserver (Hintergrund siehe how to intercept and modify HTTP responses on server side?). Ich beschloss, einen Reverse-Proxy in ASP.Net zu implementieren, der Clientanforderungen an den Back-End-HTTP-Server weiterleitet, Links und Header von der Antwort an die korrekt "verkürzte" URL übersetzt und die Antwort an den Client sendet, nachdem relevante Informationen extrahiert wurden von der Antwort.

Es funktioniert wie erwartet, mit Ausnahme des Authentifizierungsteil: der Webserver NTLM-Authentifizierung standardmäßig verwendet, und nur Anfragen und Antworten durch die Reverse-Proxy-Weiterleitung ist nicht der Benutzer auf der Remote-Anwendung authentifiziert werden. Sowohl der Reverse Proxy als auch die Webanwendung befinden sich auf derselben physischen Maschine und werden auf demselben IIS-Server ausgeführt (Windows Server 2008/IIS 7, falls dies wichtig ist). Ich habe versucht, sowohl die Authentifizierung auf der Reverse-Proxy-Anwendung zu aktivieren und zu deaktivieren, ohne Glück.

Ich habe nach Informationen darüber gesucht, und es scheint mit dem "Doppel-Hop-Problem" verwandt zu sein, das ich nicht verstehe. Meine Frage ist: Gibt es eine Möglichkeit, den Benutzer in der Remote-Anwendung über den Reverse-Proxy mit NTLM zu authentifizieren? Wenn es keine gibt, gibt es alternative Authentifizierungsmethoden, die ich verwenden könnte?

Auch wenn Sie keine Lösung für mein Problem haben, würde mich nur auf relevante Informationen verweisen, die mir helfen, aus der Verwirrung herauszukommen, wäre großartig!

Answer 1

Ich habe festgestellt, was das Problem war (und es ist NTLM): Damit der Browser den Benutzer nach seinen Anmeldeinformationen fragt, muss die Antwort einen 401-Statuscode haben. Mein Reverse-Proxy leitete die Antwort an den Browser weiter, sodass IIS einen Standard-HTML-Code hinzufügte, um zu erklären, dass die angeforderte Seite nicht aufgerufen werden kann und somit verhindert wird, dass der Browser Anmeldeinformationen anfordert. Das Problem wurde durch Entfernen des Antwortinhalt gelöst, wenn der Statuscode ein 401.

Bei allem Respekt, die ich für die eine, die das vor einigen Jahren beantwortet, muss ich zugeben, diese offensichtlich falsch ist. Das Problem war in der Tat gelöst nach dem Entfernen der Antwort Inhalt, wenn der Status-Code ist eine 401, aber es hatte nichts mit dem anfänglichen Problem zu tun .. Die Wahrheit ist, dass Windows-Authentifizierung wurde zur Authentifizierung von Menschen über lokale Windows-Netzwerke, wo gemacht Es ist kein Proxy-Server vorhanden oder wird sogar benötigt. Das Hauptproblem bei der NTLM-Authentifizierung besteht darin, dass dieses Protokoll die HTTP-Sitzung nicht authentifiziert, sondern die zugrunde liegende TCP-Verbindung, und soweit ich weiß, gibt es keine Möglichkeit, über ASP-Code darauf zuzugreifen. Jeder Proxy-Server, den ich ausprobierte, brach die NTLM-Authentifizierung. Die Windows-Authentifizierung ist für einen Benutzer bequem, da er Ihr Kennwort niemals in eine beliebige Anwendung in Ihrem Intranet eingeben muss, was für einen Sicherheitsmann beängstigend ist, da es eine automatische Anmeldung ohne eine Eingabeaufforderung gibt, wenn die Standortdomäne vertrauenswürdig ist von IE, schockierend für einen Netzwerkadministrator, weil es die Anwendung, Transport und Netzwerkschicht in einige "Windows Ball of Mug" anstelle von einfach nur HTTP-Verkehr schmilzt.

Answer 2

Obwohl dies ein alter Beitrag ist, möchte ich nur berichten, dass es mit einem Apache2.2 Reverse Proxy und der Option keepalive = on recht gut funktioniert. Offensichtlich wird dadurch die Verbindung zwischen dem Proxy und dem SharePoint-Host geöffnet und an den Client <> Proxy-Verbindung "angeheftet". Ich kenne die Mechanismen nicht genau, aber es funktioniert ziemlich gut.

Aber: Manchmal stoßen meine Benutzer auf das Problem, dass sie als ein anderer Benutzer angemeldet sind. Es scheint also einige Durchmischungen durch Sitzungen zu geben. Ich werde das noch ein bisschen testen müssen.

Lösung für alles (falls Sie ein gültiges, signiertes SSL-Zertifikat haben): Schalten Sie IIS auf Basic Auth. Dies funktioniert absolut gut, und sogar Windows (d. H. Office mit SharePoint-Verbindung, alle WebClient-basierten Prozesse etc.) wird sich überhaupt nicht beschweren. Aber sie werden, wenn Sie nur http ohne SSL/TLS verwenden, und auch mit selbstsignierten Zertifikaten.

Answer 3

ich bestätigen, es funktioniert mit "Keep-Alive = on" auf apache2.2

I examinated Rahmen mit wireshark und ich weiß, warum es nicht funktioniert. NTLM funktioniert nicht, wenn die TCP-Pakete nicht genau weitergeleitet werden, da sie vom Reverse-Proxy empfangen wurden. Aus diesem Grund funktionieren viele Reverseproxys nicht mit der NTLM-Authentifizierung. (wie nginx) Sie leiten HTTP-Anfragen korrekt weiter, aber nicht die TCP-Pakete.

Für NTLM ist ein TCP Reverse Proxy erforderlich.

Answer 4

NTLM funktioniert nicht, wenn die TCP-Pakete nicht genau weitergeleitet werden, da der Reverse-Proxy> sie empfangen hat. Aus diesem Grund funktionieren viele Reverseproxys nicht mit der NTLM-Authentifizierung. (wie nginx)> Sie leiten HTTP-Requests korrekt weiter, aber nicht die TCP-Pakete.

Nginx verfügt über die Funktionalität für die NTLM-Authentifizierung. Keepalive muss aktiviert werden, was nur über http_upstream_module möglich ist. Außerdem müssen Sie im Standortblock angeben, dass Sie HTTP/1.1 verwenden und dass das Headerfeld "Verbindung" für jede Proxyanfrage gelöscht werden soll. Nginx Config sollte in etwa so aussehen:

upstream http_backend { 
    server 1.1.1.1:80; 

    keepalive 16; 
} 

server { 
... 

location/{ 
     proxy_pass http://http_backend/; 
     proxy_http_version 1.1; 
     proxy_set_header Connection ""; 
    ... 
    } 
} 

ich meinen Kopf schon seit geraumer Zeit mit dieser Frage gekratzt, aber die oben genannten Arbeiten für mich. Beachten Sie, dass ein separater Upstream-Block als notwendig erachtet wird, wenn Sie HTTPS-Datenverkehr übertragen möchten. Um ein bisschen mehr zu klären, "keepalive 16;" Gibt die Anzahl der gleichzeitigen Verbindungen zum Upstream an, die Ihr Proxy behalten darf. Passen Sie die Anzahl entsprechend der erwarteten Anzahl gleichzeitiger Besucher auf der Website an.