RDP Gateway und OA über eine statische IP

[derWachert 0]

Folgende Konstellation.

 

Netzwerk mit einer statischen DSL IP, keine Option auf weitere IPs.

 

In der Struktur läuft u.a. eine TS-Farm mit einem entsprechenden Gateway dazwischen. Ebenfalls läuft dort ein Exchange mit aktiviertem OWA OA.

 

Nun kommen sowohl das Gateway als auch der Exchange mit offenen 443 Ports für den jeweiligen Zugriff auf die Dienste.

 

Besteht, wie früher mal mit einem ISA, die Möglichkeit unter 2k8R2 oder 2k12 einen Webserver "davor" zu schalten welcher den Traffic entsprechend sortiert sodass die RDP->HTTPS Pakete zum RDP-Gateway und die OWA OA Anfragen zum OWA OA Server weitergeleitet werden?

 

Mit URL Catchern kann man da leider nicht mehr arbeiten da bei beiden die exakt gleich /proxyxy.dll angefragt wird, sowohl RDP->HTTPS als auch OWA OA wenn es um die Sessionaushandlung geht.

 

Bislang konnte mir da niemand weiter helfen, ich kann mir aber nicht vorstellen das NIEMAND das Problem hat?

 

Ich könnte natürlich über DNS Namen arbeiten, was man ja auch muss bezüglich SSL, die dann auf das gleiche Ziel leiten, was ist jedoch wenn die Struktur vorgibt das eben nur ein DNS Name und damit ein SSL Zert verwendet wird?

 

Ich kann mir eben nicht vorstellen das, im Gegensatz zu 2k3-2k8 die Anfragen nicht mehr unterschieden werden können. Damals gab es hinter den proxyxy.dll noch Parameter womit man eindeutig zuordnen konnte ob es eine RDP-Gateway Anfrage oder eben eine OWA OA Anfrage war. Das ist weggefallen... welcher ****** sich das bei MS auch immer ausgedacht hat ^^

bearbeitet 29. Juni 2014 von derWachert

[Dukel 451]

Sowas nennt sich Reverse Proxy und kann mit dem IIS (incl. bestimmter Module), mit dem Windows Server ab 2012 (R2?) (mit dem Feature WAP = Web Application Proxy) oder anderer Software (Apache, Squid,...) umgesetzt werden.

[DocData 85]

Entschuldige bitte, kann ich dein Posting noch mal in verständlicher Form haben? Was ich verstanden habe:

 

• eine öffentliche IP-Adresse (statisch)
• RDP Gateway und OWA sollen verwendet werden (beides über 443/tcp)
• nur ein SSL Zertifikat mit nur exakt einem FQDN

Ist das so korrekt? Wenn ja, dann ist deine Lösung ein Reverse Proxy (wie bereits von Dukel richtig erwähnt). Auf dem Reverse Proxy prüfst du die URL. Alles was nach externer URL des Exchange aussieht, geht an den Exchange, alles was ohne URL daherkommt, geht zum RDP-Gateway. Denkbar wäre NGINX oder Apache mit mod_proxy. Alles keine Raketenforschung.

[derWachert 0]

Ihr habt jetzt beide den wichtigsten Fakt dabei vergessen: Man kann anhand der URL NICHT unterscheiden ob es sich um eine OWA oder eine RDP-over-HTTPS Anfrage handelt. Bei beiden Diensten wird lediglich die rpcproxy.dll aufgerufen, gänzlich OHNE Parameter. Ein Reverse Proxy fällt damit leider flach ;) Das war ja auch mein erster Gedanke, hilft allerdings nix :P

 

Sagen wir der FQDN des SSL Zerts lautet test.lab.org, dann ist sowohl bei RDP-over-HTTPS sowie bei OWA der Aufruf für die Sessionaushandlung https://test.lab.org/rpcproxy.dll OHNE Parameter wie gesagt. Daher lässt sich eben anhand der URL nicht unterscheiden an welchen Server die Anfrage weiter geleitet werden müsste. Erst nach der Session Aushandlung könnte man zumindest die OWA Abfragen filtern, vorher allerdings nicht, und das ist der springende Punkt der mich verzweifeln lässt.

[zahni 550]

Wie wäre es mit einer 2. Site und einem SAN- oder Wildcard-Zertifikat ?

 

http://blogs.msdn.com/b/varunm/archive/2013/06/18/bind-multiple-sites-on-same-ip-address-and-port-in-ssl.aspx

[derWachert 0]

Dazu müsste ich das RDP Gateway und den OWA, sprich Exchange, auf dem gleichen Server betreiben... ne :D niemals. Das widerspricht ja aller Vernunft. Da sich beide Dienste per rpcproxy authentifzieren, müsste ich einen zentralen IIS davor schalten der die Anfragen dann wiederum an den OWA oder das Gateway weiterleitet was jedoch nicht vernünftig lösbar ist (zumindest wüsste ich nicht pauschal wie, technisch sicherlich machbar).

 

Es läuft, aufgrund des Aufwands der anderen Lösungen, wohl am ehesten darauf hinaus zumindest nen zweiten FQDN mit eigenem Zert zu verwenden. Dann wäre es ein Klacks die nötigen Configs zu setzen, z.B. in der Firewall davor.

 

Was mich einfach immer wieder wundert wenn ich an diese Konstellation denke: Wieso zum Henker hat Microsoft die Parameter entfernt die früher noch an die rpcproxy Anfragen übergeben wurden? Damit wäre es per Reverse so kinderleicht die Requests zu unterscheiden, aber nöööööööööööööö...... ^^

bearbeitet 29. Juni 2014 von derWachert

[zahni 550]

Dazu müsste ich das RDP Gateway und den OWA, sprich Exchange, auf dem gleichen Server betreiben... ne :D niemals. Das widerspricht ja aller Vernunft.

 

Wieso das denn ? Wenn Du die interne Weiterleitung mit einer Site an unterschiedliche interne Server machen kannst, geht das auch mit 2 Sites. U.U. sogar einfacher. 

[NorbertFe 2.016]

Wieso ruft owa denn eine rpcproxy.dll auf? Oder meinst du oa? Welche Exchange Version ist es denn? Eventuell hilft ja Mapi over http. Ab Exchange 2013 sp1 möglich für Outlook 2013sp1.

 

Bye

Norbert

[derWachert 0]

Arghs... Natürlich Norbert... OA und nicht OWA... In der Konstellation wo ich das Problem gerne lösen würde ist es ein Exchange 2010.

[Dukel 451]

Ihr habt jetzt beide den wichtigsten Fakt dabei vergessen: Man kann anhand der URL NICHT unterscheiden ob es sich um eine OWA oder eine RDP-over-HTTPS Anfrage handelt. Bei beiden Diensten wird lediglich die rpcproxy.dll aufgerufen, gänzlich OHNE Parameter. Ein Reverse Proxy fällt damit leider flach ;) Das war ja auch mein erster Gedanke, hilft allerdings nix :p

 

Aber beide rufen die Datei nicht im selben Ordner auf.

https://server/Microsoft-Server-ActiveSync wird zu Exchange weitergeleitet

und

https://server/rds an den Remote Desktop Server.

[NorbertFe 2.016]

/RPC statt Active Sync. ;) Aber ansonsten paßt es wohl.

 

Bye

Norbert

[DocData 85]

Ihr habt jetzt beide den wichtigsten Fakt dabei vergessen: Man kann anhand der URL NICHT unterscheiden ob es sich um eine OWA oder eine RDP-over-HTTPS Anfrage handelt.

Ähh... wie bitte?

 

Bei beiden Diensten wird lediglich die rpcproxy.dll aufgerufen, gänzlich OHNE Parameter. Ein Reverse Proxy fällt damit leider flach ;) Das war ja auch mein erster Gedanke, hilft allerdings nix :P

Ähh... dann denke deinen ersten Gedanken noch mal weiter, statt mit Halbwissen zu prahlen. Was hat OWA mit RPC zu tun??

 

Du meinst ganz sicher Outlook Anywhere. Und in diesem Fall hast du ein Problem. Das geht in der Tat nicht, außer du betreibst das RDP Gateway auf dem Server mit der CAS Rolle. Und auch dann hast du ein Problem. Hotfix KB954034 wäre eine Lösung. Aber trotzdem ist das Ganze so unfassbar hässlich, dass ich das im Leben nicht installieren und/ oder betreiben würde.

 

EDIT: Im Thread-Titel steht ja OA. Dann will ich mal nicht so böse sein. Du nast nur offenbar immer wieder OWA geschrieben, aber OA gemeint.

bearbeitet 29. Juni 2014 von DocData

[derWachert 0]

Aber beide rufen die Datei nicht im selben Ordner auf.

https://server/Microsoft-Server-ActiveSync wird zu Exchange weitergeleitet

und

https://server/rds an den Remote Desktop Server.

 

OWA ja, OWA nein! rds? Keinesfalls... RDP-over-HTTPS ruft die rpcproxy.dll auf, genauso wie OA und nein, beide verwenden nicht unterschiedliche Pfade, es ist exakt der gleiche und nicht zu unterscheiden, sonst bestünde das Problem doch gar nicht.

 

Ähh... wie bitte?

 

Ähh... dann denke deinen ersten Gedanken noch mal weiter, statt mit Halbwissen zu prahlen. Was hat OWA mit RPC zu tun??

 

Du meinst ganz sicher Outlook Anywhere. Und in diesem Fall hast du ein Problem. Das geht in der Tat nicht, außer du betreibst das RDP Gateway auf dem Server mit der CAS Rolle. Und auch dann hast du ein Problem. Hotfix KB954034 wäre eine Lösung. Aber trotzdem ist das Ganze so unfassbar hässlich, dass ich das im Leben nicht installieren und/ oder betreiben würde.

 

EDIT: Im Thread-Titel steht ja OA. Dann will ich mal nicht so böse sein. Du nast nur offenbar immer wieder OWA geschrieben, aber OA gemeint.

 

Interessantes Niveau... alles lesen, dann meckern. Hab halt OWA anstatt OA geschrieben am Anfang. OWA hat natürlich nix mit RPC zu tun, OA hingegen schon. Deswegen muss man nicht gleich "den Dicken" makieren.

 

Das ich Exchange und das Gateway nicht auf einem Server betreiben werde steht auch schon weiter oben, weils sinnfrei ist, danke das du es also nochmal wiederholst ^^ Über die sinnfreiheit eines solchen Unterfangens brauchen wir uns, denke ich, nicht unterhalten :D

[DocData 85]

Interessantes Niveau... alles lesen, dann meckern. Hab halt OWA anstatt OA geschrieben am Anfang. OWA hat natürlich nix mit RPC zu tun, OA hingegen schon. Deswegen muss man nicht gleich "den Dicken" makieren.

 

Dann nimm dir bitte das nächste Mal die Zeit deine Beiträge in verständlicher Form und technisch korrekt zur formulieren.

 

Das ich Exchange und das Gateway nicht auf einem Server betreiben werde steht auch schon weiter oben, weils sinnfrei ist, danke das du es also nochmal wiederholst ^^ Über die sinnfreiheit eines solchen Unterfangens brauchen wir uns, denke ich, nicht unterhalten :D

 

Wer redet denn von einem kompletten Exchange Server? Ich rede maximal von der CAS Rolle. Die kannst du vom Rest trennen. Es ist deine Entscheidung welchen Tod du sterben willst. Was du in deinem ersten Beitrag möchest, lässt sich zwar realisieren, aber die einzige Möglichkeit es zu realisieren, willst du ja nicht.

[derWachert 0]

Ich würde es schon wollen ;) Meine Variante wäre zweiter FQDN mit eigenem Zert. So bleibt man unabhängig. Allerdings will das leider nicht jeder der ein solches Problem in seiner Struktur hat, daher habe ich mir natürlich Gedanken gemach wie man es noch lösen könnte.