reverse Proxy Exchange 2010 via Port 456 verhindert OWA Zugriff

[Wolke2k4 11]

Hallo,

 

nach diesem Artikel: http://blogs.technet.com/b/exchange/archive/2013/07/19/reverse-proxy-for-exchange-server-2013-using-iis-arr-part-1.aspx gibt es die Möglichkeit einen reverse Proxy für Exchange in der DMZ zu installieren. Dieser nimmt die Anfragen entgegen und leitet sie an den Exchange weiter.

 

Da wir nicht unbedingt den Standardport 443 für den Zugriff verwenden wollten haben wir einen alternativen Port verwendet (bspw. 456). Der Active Sync Zugriff lässt sich damit auch umsetzen und funktioniert.

 

Allerdings ist es nun so, dass beim OWA Zugriff hier das Problem auftritt, dass der Exchange scheinbar eine URL zurückliefert die über den 456 bzw. aus dem Internet nicht zugegriffen werden kann.

Nachdem wir einiges probiert haben, haben wir es einfach mal auf den Port 443 zurückgestellt und siehe da geht natürlich sofort.

 

Es scheint somit, dass beim Aufruf des OWA mit einem anderen als dem Standard WAN Port 443 nicht ohne weiteres funktioniert... :confused:

 

Jetzt ist die Frage, ob jemand weiß was da genau schief liegt?

Alternativ stellt sich die Frage, ob es sinnvoll ist den Port für den OWA auf dem Exchange umzustellen um ggf. damit die notwendige Anpassung zu erreichen?

 

Hoffe das war soweit verständlich.

 

Gruß Tom

bearbeitet 25. Juni 2014 von Wolke2k4

[RobertWi 81]

Moin,

 

IMHO ist ein anderer Port als 443 für OWA nicht supported und die Änderung dafür zwar wohl angeblich möglich, aber nicht trivial und fehlerträchtig.

 

Wie hast Du es denn geschaft, dass Active Sync auf einem anderen Port funktioniert? Beim Client ist ein anderer Port offiziell gar nicht vorgesehen und man kann ihn bei den meisten Clients auch gar nicht eintragen. Also selbst, wenn das jetzt bei Dir geht, kann das nächste Update das wieder kaputt machen. 

 

Außerdem darfst Du nicht vergessen, dass Deine Anwender in fremden Netzen eventuell gar keinen anderen Port benutzen dürfen, weil die ausgehend geblockt werden.

 

Und schlussendlich bleibt die Frage nach dem Sinn. Der Sicherheitsgewinn ist sehr gering (bis gar keiner), die Komplexität steigt aber rapide und die Fehlersuche wird auch sehr schwer.

[Wolke2k4 11]

Wir haben das nicht primär aus Sicherheitsgründen gemacht sondern aus dem Grund, da unsere Kunden auf dem 443 zumeist bereits einen anderen Dienst laufen haben. Da war es für uns am logischsten das neue Zugriffszenario anzupassen. Das MS scheinbar derartige Szenarien nicht berücksichtigt ist natürlich unschön.

 

Der Active Sync Zugriff funktioniert aktuell über den 456 mit iOS, Android und Windows Phone. In allen Fällen kann man an die Server IP bzw. den Namen einfach mittels :456 den notwendigen Port hängen, mehr braucht es nicht. Das haben wir bei insgesamt 4 Kunden so umgesetzt und bisher gab es da keine Probleme.

 

Es ist ja so, dass es letztendlich egal ist, welche Anwendung man nimmt. Sobald ich mehr als eine habe die 443 nutzt muss ich immer irgendwie etwas verbiegen. Es sei denn ich haben einen Company Connect wo ich mehr als 2 WAN IPs ansprechen kann. Aber diesen haben nun mal leider die wenigsten unserer Kunden.

Somit ist es eigentlich eine Frage was die Hersteller für Möglichkeiten offerieren derartige Szenarien ohne große Vergewaltigungen abzubilden...

[RobertWi 81]

Der Active Sync Zugriff funktioniert aktuell über den 456 mit iOS, Android und Windows Phone. In allen Fällen kann man an die Server IP bzw. den Namen einfach mittels :456 den notwendigen Port hängen, mehr braucht es nicht. Das haben wir bei insgesamt 4 Kunden so umgesetzt und bisher gab es da keine Probleme.

 

Würde ich mir gut merken. Ist wie gesagt, weder supported und vorgesehen und ich kenne sowohl iOS als auch Windows Phone Versionen, die quittieren die Eingabe von "server:port" mit "ungültiger Servername". Selbst, wenn es jetzt funktioniert, kann sich das also jederzeit und ohne Ankündigung wieder ändern.

 

Es ist ja so, dass es letztendlich egal ist, welche Anwendung man nimmt. Sobald ich mehr als eine habe die 443 nutzt muss ich immer irgendwie etwas verbiegen. Es sei denn ich haben einen Company Connect wo ich mehr als 2 WAN IPs ansprechen kann. Aber diesen haben nun mal leider die wenigsten unserer Kunden.

Somit ist es eigentlich eine Frage was die Hersteller für Möglichkeiten offerieren derartige Szenarien ohne große Vergewaltigungen abzubilden...

 

Mit Windows fallen mir drei Möglichkeiten ein (mehr geht mit Zusatzprodukten wie TMG/UAG oder Dritt-Proxys):

 - SNI (gibt es ab Windows 2012): Setzt aber voraus, dass die Applikation das auch kann und bei Exchange geht das IMHO noch nicht

 - IIS ARR -> Vorteil: man kann ziemlich differenziert steuern; Nachteil: IMHO ziemlich aufwendige IIS Konfiguration und damit fehlerträchtig

 - WAP -> Vorteil: sehr einfache Konfig (Zertifikat einspielen, Hostnamen festlegen, fertig); Nachteil: ADFS muss konfiguriert sein (aber man muss es nicht verwenden)

 

Ich selbst benutze bei mir einen WAP. Der leitet die Subdomain "login.XXX" auf den ADFS weiter (für Office 365), die Subdomain "rd.XXXX" auf ein Remotedesktop Gateway und die Domain "mail.XXXX" auf Exchange. Dafür braucht es drei unterschiedliche Zertifikate die mit private Key sowohl auf dem WAP aus auch auf den Zielservern installiert sind. Geht aber alles über eine IP, die noch dazu dynamisch ist.

[Dukel 454]

Wir haben das nicht primär aus Sicherheitsgründen gemacht sondern aus dem Grund, da unsere Kunden auf dem 443 zumeist bereits einen anderen Dienst laufen haben. Da war es für uns am logischsten das neue Zugriffszenario anzupassen. Das MS scheinbar derartige Szenarien nicht berücksichtigt ist natürlich unschön.

 

Das kann man mit unterschiedlichen IPs/Domänen/Adressen machen.

Z.b. https://domain.de/owa geht zum Exchange, https://domain.de/app1 geht zum App Server.

[RobertWi 81]

Bei SSL sind Domänenname und Pfad normalerweise verschlüsselt, darum der Aufwand mit dem Proxy oder den unterschiedlichen IP-Adressen.

[Wolke2k4 11]

Das kann man mit unterschiedlichen IPs/Domänen/Adressen machen.

Z.b. https://domain.de/owa geht zum Exchange, https://domain.de/app1 geht zum App Server.

 

Wie soll das gehen, wenn ich eine WAN IP habe? Den HTTPS Port kann ich nur ein Mal ansprechen. In Deinem Beispiel würde bei einer WAN IP immer auch dort nur 443 auflaufen. Wenn ich zwei unterschiedliche Anwendungsszenarien habe (bspw. 1x Exchange und 1x Citrix Secure Gateway Zugriff via 443 in der DMZ) dann helfen mir die unterschiedlichen Pfade auch nicht.

 

 

 

 

 

 

 - IIS ARR -> Vorteil: man kann ziemlich differenziert steuern; Nachteil: IMHO ziemlich aufwendige IIS Konfiguration und damit fehlerträchtig

 

 

 

Soweit ich das verstanden habe (habe es selber technisch nicht umgesetzt) nutzen wir das aktuell...

 

Vielleicht reden wir hier auch von unterschiedlichen Dingen.

 

Ich kann den 443 oder irgendeinen anderen Port mittels Portforwarding immer auf einen Zielhost in die DMZ lenken. Nun habe ich bspw. schon bei den Kunden dort einen Dienst von Citrix am Laufen, der über WAN mittels 443 angesprochen wird.

Jetzt brauche ich für die OWA/Active Sync Geschichte einen weiteren Host in der DMZ... ergo kann ich den 443 nicht noch mal benutzen...

bearbeitet 26. Juni 2014 von Wolke2k4

[RobertWi 81]

Moin,

 

sowohl ARR als auch WAP arbeiten als Proxy (was übrigens auch der Titel Deiner Frage ist ;)).

 

Du lässt als ALLES, was 443 ist, auf dem Proxy ankommen und der kümmert sich um die Weiterleitung auf den korrekten internen Host.