nginx Reverseproxy mit Windows-Authentifizierung, die NTLM verwendet

Question

nginx Reverseproxy mit Windows-Authentifizierung, die NTLM verwendet

8

Wer weiß, ob es möglich ist, Reverse-Proxy mit Windows-Authentifizierung, die NTLM verwendet, zu tun? Ich kann kein Beispiel dafür finden. Was sollten die Werte des Feldes more_set_headers sein?

%Vor%

Wenn ich direkt auf den Host zugreife, gelingt die Authentifizierung, wenn ich mit dem Reverse Proxy auf die Authentifizierung stehe, jedes Mal fehlgeschlagen.

nginx reverse-proxy ntlm

matheus 22.01.2014, 13:57

quelle

3 Antworten

Tags und Links nginx reverse-proxy ntlm

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Ändere die Farbe von Select2 glow

score 9 · Answer 1

9

Um NTLM-Pass-Through mit Nginx zu aktivieren -

%Vor%

- Ramon

Fizz 13.10.2015 07:34

quelle

score 3 · Answer 2

Soweit ich weiß, ist dies derzeit mit nginx nicht möglich. Ich habe das vor einiger Zeit selbst gründlich untersucht. Das grundlegende Problem besteht darin, dass für die NTLM-Authentifizierung der gleiche Socket für die nachfolgende Anforderung verwendet werden muss, der Proxy jedoch nicht. Bis das nginx-Entwicklungsteam irgendeine Art von Unterstützung für dieses Verhalten bietet, habe ich dies mit der Authentifizierung im Reverse-Proxy selbst gemacht. Ich mache das gerade mit Apache 2.2, mod_proxy, mod_auth_sspi (nicht perfekt, aber funktioniert). Viel Glück! Sorry, nginx, ich liebe dich, aber wir könnten wirklich Hilfe für diesen häufigen Anwendungsfall gebrauchen.

score 3 · Answer 3

Seitdem habe ich eine andere Lösung gefunden. Das ist immer noch nicht dasselbe wie nginx, das den NTLM erledigt (was nett sein wird, wenn das nginx-Team dies jemals implementiert). Aber vorerst funktioniert das, was ich tue, für uns.

Ich habe einen Lua-Code geschrieben, der ein verschlüsseltes Cookie verwendet. Das verschlüsselte Cookie enthält die ID des Benutzers, die Uhrzeit der Authentifizierung und die IP-Adresse, von der aus er sich authentifiziert hat. Ich befestige dieses Zeug hier als Referenz. Es ist nicht poliert, aber vielleicht können Sie es verwenden, um Ihr eigenes ähnliches Schema zu entwickeln.

Grundsätzlich funktioniert es wie folgt:

Wenn der Cookie NICHT verfügbar ist oder wenn er abgelaufen oder ungültig ist, führt nginx einen Service-Aufruf (pre-auth) zu einer Back-End-IIS-Anwendung durch, wobei die IP-Adresse des Clients weitergegeben und der Client dann an eine IIS-Webanwendung weitergeleitet wird. Windows-Authentifizierung "aktiviert. Der Pre-Auth-Dienst der Back-End-II-Anwendung generiert eine GUID und speichert einen Eintrag in der DB für diese GUID und ein Flag, das angibt, dass diese GUID authentifiziert werden soll.
Der Browser wird von nginx zur GUID an die Authenticator App weitergeleitet.
Die IIS-Anwendung authentifiziert den Benutzer über die Windows-Authentifizierung und aktualisiert den Datenbankdatensatz für diese GUID und die Client-IP-Adresse mit der Benutzer-ID und der authentifizierten Uhrzeit.
Die IIS-Anwendung leitet den Client zurück zur ursprünglichen Anfrage.
nginx lua code fängt diesen Aufruf ab und führt erneut einen Hintertür-Serviceanruf zur IIS-App aus (post-auth) und fragt nach der Benutzer-ID und der authentifizierten Uhrzeit. Diese Informationen werden in einem verschlüsselten Cookie gespeichert und an den Browser gesendet. Die Anfrage darf passieren und der REMOTE_USER wird mitgeschickt.
nachfolgende Anfragen durch den Browser übergeben das Cookie und der nginx lua-Code sieht das gültige Cookie und proxies die Anfrage direkt (ohne sich natürlich erneut zu authentifizieren), indem er den REMOTE_USER-Request-Header übergibt.

access.lua:

%Vor%

strings.lua:

%Vor%

enc.lua:

%Vor%

Beispiel nginx conf:

%Vor%