Exchange 2010: OWA generell erlauben, ActiveSync nur intern erlauben?
Hallo,
wir haben Exchange 2010 im Einsatz und nutzen intern OWA per https und ActiveSync (von Android Smartphones) ebenfalls per https.
Zukünftig soll OWA auch von extern möglich sein, jedoch kein ActiveSync, Outlook Anywhere oder andere Funktionen, bei denen Daten das Haus verlassen.
Wenn wir ganz stumpf an der Firewall den Port 443 weiterleiten an den Exchange-Server, hat der Exchange-Server keine Möglichkeit zu unterscheiden, ob eine ActiveSync-Anfrage von intern oder extern kommt. Ist das richtig?
Mal angenommen, es ist richtig, welche Möglichkeiten gibt es? Ich nehme an, URL-Filtering ist das Stichwort. Es wird nur https://mail.firmal.tld/owa/ zugelassen. Ist das richtig?
Mit welchen Produkten kann man das realisieren. TMG kann das wohl, wird aber nicht mehr verkauft.
Wie ist es mit der TMG Appliance von SecureGuard. Ist die zu empfehlen?
Wäre Kemp ESP (http://kemptechnologies.com/microsoft-load-balancing/tmg-edge-security- ..) eine Alternative?
Welche Möglichkeiten gibt es noch?
Danke
Martin
wir haben Exchange 2010 im Einsatz und nutzen intern OWA per https und ActiveSync (von Android Smartphones) ebenfalls per https.
Zukünftig soll OWA auch von extern möglich sein, jedoch kein ActiveSync, Outlook Anywhere oder andere Funktionen, bei denen Daten das Haus verlassen.
Wenn wir ganz stumpf an der Firewall den Port 443 weiterleiten an den Exchange-Server, hat der Exchange-Server keine Möglichkeit zu unterscheiden, ob eine ActiveSync-Anfrage von intern oder extern kommt. Ist das richtig?
Mal angenommen, es ist richtig, welche Möglichkeiten gibt es? Ich nehme an, URL-Filtering ist das Stichwort. Es wird nur https://mail.firmal.tld/owa/ zugelassen. Ist das richtig?
Mit welchen Produkten kann man das realisieren. TMG kann das wohl, wird aber nicht mehr verkauft.
Wie ist es mit der TMG Appliance von SecureGuard. Ist die zu empfehlen?
Wäre Kemp ESP (http://kemptechnologies.com/microsoft-load-balancing/tmg-edge-security- ..) eine Alternative?
Welche Möglichkeiten gibt es noch?
Danke
Martin
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 241852
Url: https://administrator.de/contentid/241852
Ausgedruckt am: 25.11.2024 um 13:11 Uhr
11 Kommentare
Neuester Kommentar
Hallo Martin,
mal wieder eine hochtrabende Frage, nun: Was passiert, wenn dein Android Device (oder Laptop oder Tablet oder x) die Daten synchronisiert (Active Sync) und sie nach aussen trägt?) oder die Daten aus OWA heruntergetragen werden? Hier hinkt das Konzept gewaltig.
Damit ist nicht die Umsetzung das Problem, sondern das Konzept.
Grüße,
Christian
mal wieder eine hochtrabende Frage, nun: Was passiert, wenn dein Android Device (oder Laptop oder Tablet oder x) die Daten synchronisiert (Active Sync) und sie nach aussen trägt?) oder die Daten aus OWA heruntergetragen werden? Hier hinkt das Konzept gewaltig.
Damit ist nicht die Umsetzung das Problem, sondern das Konzept.
Grüße,
Christian
Zitat von @AlbertMinrich:
OK, ok. Auch da ist was dran. Aber vielleicht haben wir ja folgendes Szenario.
Sorry aber wenn du jetzt solange die Rahmenbedingungen änderst bis du eine Antwort bekommst die dir auch gefällt, dann wird's mir zu blöd.OK, ok. Auch da ist was dran. Aber vielleicht haben wir ja folgendes Szenario.
Entweder euer Szenario ist so oder so. Also gleich richtig erklären sonst wird das nicht's.
Zitat von @AlbertMinrich:
> Zitat von @certifiedit.net:
>
> Hallo Martin,
>
> mal wieder eine hochtrabende Frage, nun: Was passiert, wenn dein Android Device (oder Laptop oder Tablet oder x) die Daten
> synchronisiert (Active Sync) und sie nach aussen trägt?) oder die Daten aus OWA heruntergetragen werden? Hier hinkt das
> Konzept gewaltig.
>
> Damit ist nicht die Umsetzung das Problem, sondern das Konzept.
Hallo Christian,
ich dachte mir schon, daß dieser (berechtigte) Einwand kommt. Aber es ist schon noch ein kleiner Unterschied, ob jemand von
vornherein ActiveSync macht, die Daten landen also immer und auf jeden Fall auf dem Client, oder ob jemand nur "schaut"
(also OWA) und nur bei Bedarf, man könnte auch sagen mutwillig, Daten auf seinen Client runterlädt.
Aber danke für den Einwand. Trotzdem hast du keine meiner Fragen beantwortet. .
Gruß
Martin
> Zitat von @certifiedit.net:
>
> Hallo Martin,
>
> mal wieder eine hochtrabende Frage, nun: Was passiert, wenn dein Android Device (oder Laptop oder Tablet oder x) die Daten
> synchronisiert (Active Sync) und sie nach aussen trägt?) oder die Daten aus OWA heruntergetragen werden? Hier hinkt das
> Konzept gewaltig.
>
> Damit ist nicht die Umsetzung das Problem, sondern das Konzept.
Hallo Christian,
ich dachte mir schon, daß dieser (berechtigte) Einwand kommt. Aber es ist schon noch ein kleiner Unterschied, ob jemand von
vornherein ActiveSync macht, die Daten landen also immer und auf jeden Fall auf dem Client, oder ob jemand nur "schaut"
(also OWA) und nur bei Bedarf, man könnte auch sagen mutwillig, Daten auf seinen Client runterlädt.
Aber danke für den Einwand. Trotzdem hast du keine meiner Fragen beantwortet. .
Gruß
Martin
Da bist du mit OWA aber schlimmer dran. Wenn ich per OWA mutwillig Daten herunterlade: Futsch, und wech (außer Reichweite). Wenn ich es per AS/Mobile Device Anbindung mache, habe ich wenigstens prinzipiell die Chance per EX das Ding zu resetten. Well, und nun? Schiesst dir die Realität ins Bein, nicht? Ebenso bei dem Konzept Handheld nur intern, wenn das Ding aber verloren geht hast du außerhalb keine Chance es zu löschen. MD Management will gekonnt+ durchdacht sein.
Hi,
jetzt mal abgesehen von den Bedenken, es geht. Exchange ist grundsätzlich zu "doof" dafür, aber was z.B. gehen würde wäre einfach einen Reverse proxy zwischen das Interweb und den Exchange-Server zu klemmen. Port 443 kommt am Proxy an, wenn die Ziel-URL passt wird ein rewrite auf die interne Adresse des Exchange gemacht, ansonsten versandet die Anfrage im Proxy oder du kannst sie beliebig irgendwo hin leiten.
So was ähnliches nutzen wir bei einem Kunden für OWA und ActiveSync weil deren Firewall Port 443 für sich selbst beansprucht. Der Reverse Proxy lauscht auf 8443 und schreibt Anfragen auf die (externe) URL um auf exchange-IP:443. Geht mit Apache, man muss ihm dafür allerdings das Zertifikat des Exchange-Servers geben damit er die HTTPS-Anfragen umschreiben kann.
Könnte höchstens mit Anfragen von intern etwas schwierig werden, aber das sollte mit Hairpin-NAT machbar sein.
jetzt mal abgesehen von den Bedenken, es geht. Exchange ist grundsätzlich zu "doof" dafür, aber was z.B. gehen würde wäre einfach einen Reverse proxy zwischen das Interweb und den Exchange-Server zu klemmen. Port 443 kommt am Proxy an, wenn die Ziel-URL passt wird ein rewrite auf die interne Adresse des Exchange gemacht, ansonsten versandet die Anfrage im Proxy oder du kannst sie beliebig irgendwo hin leiten.
So was ähnliches nutzen wir bei einem Kunden für OWA und ActiveSync weil deren Firewall Port 443 für sich selbst beansprucht. Der Reverse Proxy lauscht auf 8443 und schreibt Anfragen auf die (externe) URL um auf exchange-IP:443. Geht mit Apache, man muss ihm dafür allerdings das Zertifikat des Exchange-Servers geben damit er die HTTPS-Anfragen umschreiben kann.
Könnte höchstens mit Anfragen von intern etwas schwierig werden, aber das sollte mit Hairpin-NAT machbar sein.
Reverse proxy zwischen das Interweb und den Exchange-Server zu klemmen
Könnte höchstens mit Anfragen von intern etwas schwierig werden, aber das sollte mit Hairpin-NAT machbar sein.
Warum so kompliziert? Den RP nur für externe Anfragen verwenden und gut ist. Ihr nutzt sicher Autodiscover oder?Könnte höchstens mit Anfragen von intern etwas schwierig werden, aber das sollte mit Hairpin-NAT machbar sein.
Geht mit Apache, man muss ihm dafür allerdings das Zertifikat des Exchange-Servers geben damit er die HTTPS-Anfragen umschreiben kann.
Apache ist die Kanone, dein Anliegen Ein Spatz. Ein einfacher Squid oder Ngnix reicht völlig aus.Grüße,
Dani