Web Application Proxy in einer DMZ

[VolZim 0]

Hallo Leute,

 

um verschiedene Anwendungen im Internet zu veröffentlichen habe ich momentan folgende Konstellation:

 

Firewall -> Squid Reverse Proxy in der DMZ -> Firewall -> z.B. OWA im internen Netz

vom Internet zur DMZ sowie von der DMZ zum internen Lan ist nur der Port 443 freigegeben.

 

Bleiben wir mal bei dem Beispiel OWA, dieser soll über den neuen WAP Server veröffentlicht werden. Die Anmeldung soll via SSO über ADFS laufen.

 

Nun würde ich das System gerne umstellen und den Web Application Proxy mit ADFS nutzen. Der ADFS Server soll ins interne Netz, der WAP Server jedoch in die DMZ. Der WAP Server soll kein Domänemitglied werden.

Ich finde es nun aber absolut widersprüchlich von Microsoft, dass der WAP Server in der DMZ stehen soll, andererseits aber ein Domänemitglied sein muss um die Authentifizierung über ADFS machen zu können. Wenn ich alle Ports für die Domänenmitgliedschaft freigebe, brauche ich auch meine DMZ nicht mehr. :suspect:

 

Mich würde man brennend interessieren wie ihr das gelöst habt?

[NilsK 2.781]

Moin,

 

wo hast du denn her, dass der WAP Domänenmitglied sein müsse? Meines Wissens muss er das nicht, und Microsoft rät auch explizit davon ab.

 

Gruß, Nils

[VolZim 0]

Das ist die Beschreibung von Microsoft die ich am durcharbeiten bin.

 

https://technet.microsoft.com/de-de/library/dn528827(v=ws.11).aspx

 

hab ich da was falsch verstanden? :confused:

[NilsK 2.781]

Moin,

 

 

To allow users to authenticate using Integrated Windows authentication, the Web Application Proxy server must be joined to a domain.

 

(Hervorhebung von mir)

 

das heißt: Wenn der Backend-Server mit Windows-integrierter Anmeldung die User anmelden soll, dann muss der WAP Domänenmitglied sein. Ziemlich klar, denn sonst wird er ja die AD-Anmeldung nicht prüfen können.

 

Das ist aber deiner Aussage nach gar nicht das, was du machen willst, denn du willst ja ADFS nutzen. In dem Fall ist der Reverse Proxy (also hier der WAP) natürlich kein Domänenmitglied, sondern nur der dahintergeschaltete ADFS.

 

Gruß, Nils

[VolZim 0]

kannst du dir mal diese Anleitung anschauen?

http://news.digicomp.ch/de/2013/09/23/veroeffentlichen-von-exchange-2013-ueber-den-web-application-proxy-in-windows-server-2012-r2/

 

da wird das ganze auch nochmal beschrieben. Ich glaub ich verwechsele da was mit den ganzen Authentifizierungsarten :D  

[NilsK 2.781]

Moin,

 

na, da steht es doch auch noch mal ausdrücklich dabei: Der WAP kann entweder "claims-based" ADFS oder Kerberos. Wenn Kerberos, dann Domänenmitgliedschaft. Wenn Claims-based ADFS, dann keine Domänenmitgliedschaft.

 

Für die Auswahl der passenden Authentifizierung ist das gewünschte Szenario wichtig: Wer soll denn von wo aus auf den Exchange zugreifen? Vermutlich geht es ja um den Zugriff von außen, wo der User ohnehin kein Kerberos-Ticket übermitteln kann. Da ist dann Claims-based ADFS das Mittel der Wahl: Der User bekommt eine Anmeldeseite von ADFS präsentiert, an der er sich mit seinem Domänenkonto anmeldet. Damit erhält er ein SAML-Token und kann dann auf den Exchange zugreifen. Und dafür muss der WAP kein Domänenmitglied sein, weil er dann nur Reverse Proxy für den ADFS-Server im LAN spielt.

 

In dem von dir beschriebenen Artikel wird zwar Kerberos verwendet - aber da der User eben nicht mit einem gültigen Kerberos-Ticket ankommt, muss WAP dann doch die Anmeldeseite des ADFS anzeigen. Also kein Vorteil für den User, dafür ein Nachteil für die Sicherheit (weil eben der WAP Domänenmitglied sein und daher mit dem DC im LAN kommunizieren muss). Man könnte auch sagen: Hübscher Artikel, aber am Thema vorbei.

 

Um Claims-based ADFS zu machen, dürfte diese Anleitung hilfreich sein:

https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx

 

Gruß, Nils

 

 

Gruß, Nils

bearbeitet 20. September 2017 von NilsK

[magheinz 100]

wir haben in der DMZ zwei readonly-openldaps als proxy zur AD und zwei haproxys als reverseproxy und loadbalancer.

Das Konstrukt läuft jetzt seit jahre ziemlich gut. Im unserer Umgebung kommt so schnell kein Windows in die DMZ.

[VolZim 0]

vielen Dank für die gute Erklärung Nils :thumb1: . Jetzt ist mir das ganze um einiges klarer :)

 

genau, es geht um den externen Zugriff auf OWA. Ich habe mich zu sehr an dem Artikel orientiert, weil mir das mit der Authentifizierung nicht klar war.

bearbeitet 20. September 2017 von VolZim

[NilsK 2.781]

Moin,

 

da bist du nicht der einzige, wie man dem Artikel ja entnehmen kann. :D

Ist aber auch wirklich komplex.

 

Gruß, Nils

PS. Danke für die Rückmeldung! :)