7
Nginx Reverse Proxy, HTTP AUTH User eingrenzen
Hallo,
ich möchte eine interne Webanwendung per Nginx auch extern, bereitzustellen.
Ich nutze den Nginx also als Reverse Proxy für ein IIS Web. Dieses Web nutzt HTTP Auth.
Das funktioniert soweit, die Seite ist nun über den Nginx mit dem dort hinterlegte SSL Zertifikat erreichbar. Auch die HTTP Auth - Authentizierung klappt.
Nun reicht der Nginx die Auth Daten ja erstmal nur zum IIS durch.
Kann ich den Zugriff über den Nginx dennoch beschränken?
Es gibt 4 gültige User für die Authentizierung auf dem IIS.
Kann ich erreichen, dass von extern (über den NginX) nur einer der 4 Benutzer sich anmelden können?
Also auf dem Nginx nochmal eine Art Whitelist mit Benutzernamen pflege, die überhaupt zur Anmeldung zugelassen sind?
Viele Grüße
Christoph
ich möchte eine interne Webanwendung per Nginx auch extern, bereitzustellen.
Ich nutze den Nginx also als Reverse Proxy für ein IIS Web. Dieses Web nutzt HTTP Auth.
Das funktioniert soweit, die Seite ist nun über den Nginx mit dem dort hinterlegte SSL Zertifikat erreichbar. Auch die HTTP Auth - Authentizierung klappt.
Nun reicht der Nginx die Auth Daten ja erstmal nur zum IIS durch.
Kann ich den Zugriff über den Nginx dennoch beschränken?
Es gibt 4 gültige User für die Authentizierung auf dem IIS.
Kann ich erreichen, dass von extern (über den NginX) nur einer der 4 Benutzer sich anmelden können?
Also auf dem Nginx nochmal eine Art Whitelist mit Benutzernamen pflege, die überhaupt zur Anmeldung zugelassen sind?
Viele Grüße
Christoph
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 359563
Url: https://administrator.de/contentid/359563
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
7 Kommentare
Neuester Kommentar
Moin.
Du könntest auf dem IIS eine weitere Site anlegen die auf einem anderen Port lauscht oder auf einen anderen Hostheader reagiert, welche aber auf die selbe Webanwendung zeigt. Darauf dann die externen User beschränken. Intern bleibt es dann wie gehabt. Nur der Proxy zeigt nach intern auf die andere Site.
So bleibt dann auch die Rechtevergabe gebündelt weiterhin auf dem IIS.
Guten Rutsch.
Gruß @135051
Du könntest auf dem IIS eine weitere Site anlegen die auf einem anderen Port lauscht oder auf einen anderen Hostheader reagiert, welche aber auf die selbe Webanwendung zeigt. Darauf dann die externen User beschränken. Intern bleibt es dann wie gehabt. Nur der Proxy zeigt nach intern auf die andere Site.
So bleibt dann auch die Rechtevergabe gebündelt weiterhin auf dem IIS.
Guten Rutsch.
Gruß @135051
1
Moin,
steht der nginx in der DMZ oder im selben Subnetz wie der IIS Webserver?! Bei letzterem empfehle ich dir mal nach einen nginx LDAP Modul umzuschauen. Ich habe dazu vor langer, langer Zeit etwas gelesen. Finde es aber auf die Schnelle nicht mehr.
Gruß,
Dani
steht der nginx in der DMZ oder im selben Subnetz wie der IIS Webserver?! Bei letzterem empfehle ich dir mal nach einen nginx LDAP Modul umzuschauen. Ich habe dazu vor langer, langer Zeit etwas gelesen. Finde es aber auf die Schnelle nicht mehr.
Gruß,
Dani
Moin,
du könntest User-Zertifikate benutzen und nur den Usern ein Zertifikat geben, die rauf sollen.
Gruß, V
du könntest User-Zertifikate benutzen und nur den Usern ein Zertifikat geben, die rauf sollen.
Gruß, V
Moin,
Gruß,
Dani
du könntest User-Zertifikate benutzen und nur den Usern ein Zertifikat geben, die rauf sollen.
bei der Umsetzung sind einige Punkte zu beachten:- Es wird eine Zertifizierungsstelle benötigt. Die Sperrliste muss aus dem Internet erreichbar sein. Anderenfalls kann nicht geprüft werden, ob das Zertifikat noch gültig ist.
- Rollout der Zertifikate auch im lokalen Netzwerk.
- Rollout auf private Geräte würde ich auf jeden Fall vermeiden. Da du nicht ausschließen kannst, dass das Zertifikat dort inkl. privater Schlüssel entwendet wird.
- Zusätzlicher wiederkehrender Wartungsaufwand und evtl. Helpdesk Anfragen.
Gruß,
Dani
Zitat von @Dani:
Moin,
Gruß,
Dani
Moin,
du könntest User-Zertifikate benutzen und nur den Usern ein Zertifikat geben, die rauf sollen.
bei der Umsetzung sind einige Punkte zu beachten:- Es wird eine Zertifizierungsstelle benötigt. Die Sperrliste muss aus dem Internet erreichbar sein. Anderenfalls kann nicht geprüft werden, ob das Zertifikat noch gültig ist.
- Rollout der Zertifikate auch im lokalen Netzwerk.
- Rollout auf private Geräte würde ich auf jeden Fall vermeiden. Da du nicht ausschließen kannst, dass das Zertifikat dort inkl. privater Schlüssel entwendet wird.
- Zusätzlicher wiederkehrender Wartungsaufwand und evtl. Helpdesk Anfragen.
Gruß,
Dani
Ja gut ok...sollte auch nur ein Denkanstoß werden ;)
Guten Rutsch
Hallo und frohes neues Jahr!
Danke für die Vorschläge,
im Moment stehen Proxy und Webserver im gleichen Subnetz, aber mit der Option, den Nginx woanders zu hosten, würde ich gern bei reiner HTTPS Kommunikation bleiben.
Den Aufwand mit Zertifikaten möchte ich eigentlich auch nicht machen, das wäre im Moment etwas aufwendig, für diese recht kleine Anwendung.
Ich schaue mir das mit der zweiten Site mal an, Danke für den Gedanken.
Der Nginx selber scheint sich selber keine Option zu bieten was?
Danke für die Vorschläge,
im Moment stehen Proxy und Webserver im gleichen Subnetz, aber mit der Option, den Nginx woanders zu hosten, würde ich gern bei reiner HTTPS Kommunikation bleiben.
Den Aufwand mit Zertifikaten möchte ich eigentlich auch nicht machen, das wäre im Moment etwas aufwendig, für diese recht kleine Anwendung.
Ich schaue mir das mit der zweiten Site mal an, Danke für den Gedanken.
Der Nginx selber scheint sich selber keine Option zu bieten was?
Moin,
Gruß,
Dani
Der Nginx selber scheint sich selber keine Option zu bieten was?
Naja, als Reverse Proxy geht es primär darum, die Verbindung "weiterzuleiten". Der verarbeitende Webserver ist in deinem Szenario der Microsoft IIS. Schau dir diesen Artikel einmal an. Eine separate Authentifizierung (unabhängig vom Active Directory) ist denkbar. Getestet habe ich dies bisher nicht.Gruß,
Dani
