6
Exchange 2013: OWA-Zugriff nur für bestimmten User extern nutzbar machen - für Andere nur intern
Hallo Exchange-Freunde,
ich stehe vor folgendem Problem und bin mir icht 100%ig sicher wie ich es elegant lösen kann:
Es existiert ein Exchange 2013 für eine 10-Mann-"Organisation".
Teilweise wird OWA intern benutzt, nur ein Mitarbeiter, der kein vollwertiges Organisationsmitglied ist, und NUR auf die Mails Zugriff haben soll (deshalb scheidet für mich eine VPN Verbindung aus) soll einen OWA Zugriff für extern erhalten.
Funktioniert soweit auch ganz gut - nur hätte ich das Ganze gerne etwas besser abgesichert.
Externe und interne OWA Urls sind wg. Zertifikat (nur auf eine URL ausgestellt) gleich.
Wenn ich richtig recherchiert habe, kann ich nirgendwo im Exchange selbst festlegen, dass bestimmet User nur internen OWA Zugriff oder nur externen haben. Es geht nur intern und extern, oder nichts von beiden (je nachdem ob ichs im ECP aktiviere/deaktiviere).
Ich lese immer, dass dies mit ISA bzw. TMG funktionieren soll. Habe aber auch gelesen, dass dies mit (hohen?) Kosten verbunden ist, und ISA/TMG eigentlich nicht mehr vertrieben werden!?
Hab damit leider überhaupt keine Erfahrung.
Für Schlagworte und Tipps bin ich dankbar.
Aktuell ist für ActiveSync und dem externen User der Port 443 auf den Exchange weitergeleitet. Ich würde hier als zusätzlichen Sicherheitsaspekt gerne auch noch nen URL Filter aktivieren, sodass von extern nur server/owa und server/Microsoft-Server-ActiveSync weitergereicht wird; alles Andere soll blockiert werden. ( http://www.msxfaq.de/clients/owafirewall.htm )
Als kostengünstige und wohl effiziente Methode hätte ich nun an eine 3. Hyper-V Maschine (bisher 1DC, 1Exchange) gedacht, auf der die Linux Firewall ipFire nur für folgenden Zweck läuft:
router leitet port 443 an die ipFire Maschine ans rote Device weiter, der URL Filter lässt nur server/owa und server/Microsoft-Server-ActiveSync durch und leitet diese Anfragen an den Exchange (grünes Device) weiter.
Hab mir ipFire kurz angesehen und bin mir nicht sicher, ob das in der Praxis funktionieren wird.
Auf den 1. Blick sieht es für mich so aus, als wäre der URL Filter eher als Absicherung dafür gedacht, dass bestimmte Clients nicht auf verbotenen Seiten surfen dürfen (z.B. Jugendschutz)..und nicht umgekehrt (extern eine interne verbotene URL erreichen dürfen).
Habe ich hier einen Denkfehler, oder funktioniert das in beide Richtungen problemlos.
Hat damit schon jmd. Praxiserfahrung?
Ggf. kann ich ipFire auch für o.g. Zwecke verwenden (nur bestimmte User erhalten Zugriff von extern auf OWA) (aus diesem Grund die eigentlich 2 Fragen in eine Zusammengefasst; da sie für mich doch irgendwie zusammengehören)
Vielen Dank und viele Grüße,
Malungo
ich stehe vor folgendem Problem und bin mir icht 100%ig sicher wie ich es elegant lösen kann:
Es existiert ein Exchange 2013 für eine 10-Mann-"Organisation".
Teilweise wird OWA intern benutzt, nur ein Mitarbeiter, der kein vollwertiges Organisationsmitglied ist, und NUR auf die Mails Zugriff haben soll (deshalb scheidet für mich eine VPN Verbindung aus) soll einen OWA Zugriff für extern erhalten.
Funktioniert soweit auch ganz gut - nur hätte ich das Ganze gerne etwas besser abgesichert.
Externe und interne OWA Urls sind wg. Zertifikat (nur auf eine URL ausgestellt) gleich.
Wenn ich richtig recherchiert habe, kann ich nirgendwo im Exchange selbst festlegen, dass bestimmet User nur internen OWA Zugriff oder nur externen haben. Es geht nur intern und extern, oder nichts von beiden (je nachdem ob ichs im ECP aktiviere/deaktiviere).
Ich lese immer, dass dies mit ISA bzw. TMG funktionieren soll. Habe aber auch gelesen, dass dies mit (hohen?) Kosten verbunden ist, und ISA/TMG eigentlich nicht mehr vertrieben werden!?
Hab damit leider überhaupt keine Erfahrung.
Für Schlagworte und Tipps bin ich dankbar.
Aktuell ist für ActiveSync und dem externen User der Port 443 auf den Exchange weitergeleitet. Ich würde hier als zusätzlichen Sicherheitsaspekt gerne auch noch nen URL Filter aktivieren, sodass von extern nur server/owa und server/Microsoft-Server-ActiveSync weitergereicht wird; alles Andere soll blockiert werden. ( http://www.msxfaq.de/clients/owafirewall.htm )
Als kostengünstige und wohl effiziente Methode hätte ich nun an eine 3. Hyper-V Maschine (bisher 1DC, 1Exchange) gedacht, auf der die Linux Firewall ipFire nur für folgenden Zweck läuft:
router leitet port 443 an die ipFire Maschine ans rote Device weiter, der URL Filter lässt nur server/owa und server/Microsoft-Server-ActiveSync durch und leitet diese Anfragen an den Exchange (grünes Device) weiter.
Hab mir ipFire kurz angesehen und bin mir nicht sicher, ob das in der Praxis funktionieren wird.
Auf den 1. Blick sieht es für mich so aus, als wäre der URL Filter eher als Absicherung dafür gedacht, dass bestimmte Clients nicht auf verbotenen Seiten surfen dürfen (z.B. Jugendschutz)..und nicht umgekehrt (extern eine interne verbotene URL erreichen dürfen).
Habe ich hier einen Denkfehler, oder funktioniert das in beide Richtungen problemlos.
Hat damit schon jmd. Praxiserfahrung?
Ggf. kann ich ipFire auch für o.g. Zwecke verwenden (nur bestimmte User erhalten Zugriff von extern auf OWA) (aus diesem Grund die eigentlich 2 Fragen in eine Zusammengefasst; da sie für mich doch irgendwie zusammengehören)
Vielen Dank und viele Grüße,
Malungo
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: 255203
Url: https://administrator.de/contentid/255203
Ausgedruckt am: 24.11.2024 um 16:11 Uhr
6 Kommentare
Neuester Kommentar
Hi,
ISA/TMG ist gute Wahl, leider schwer zu beschaffen.
Schau mal bei
http://kemptechnologies.com/de/microsoft-load-balancing/microsoft-foref ...
Das soll auch ganz gut sein
Gruss RS
ISA/TMG ist gute Wahl, leider schwer zu beschaffen.
Schau mal bei
http://kemptechnologies.com/de/microsoft-load-balancing/microsoft-foref ...
Das soll auch ganz gut sein
Gruss RS
Moin,
nimm einen Linuxserver, pack Squid drauf, in die Domäne integrieren und an Hand einer AD-Gruppe definieren, ob der User berechtigt ist oder nicht - Anleitung.
Gruß,
Dani
nimm einen Linuxserver, pack Squid drauf, in die Domäne integrieren und an Hand einer AD-Gruppe definieren, ob der User berechtigt ist oder nicht - Anleitung.
Gruß,
Dani
Hallo,
Mal abgesehen davon das das mit VPN auch funktionieren würde und ich mich frage was die Absicherung damit zu tun hat das du nur 1 Zertifikat für intern und extern hast würd ich auch die Lösung von Dani empfehlen.
Mal abgesehen davon das das mit VPN auch funktionieren würde und ich mich frage was die Absicherung damit zu tun hat das du nur 1 Zertifikat für intern und extern hast würd ich auch die Lösung von Dani empfehlen.
Hallo,
der 2012er bringt einen eigenen Reverse Proxy, auf Basis des IIS, mit. Dort müsstest Du eigentlich über Gruppen was basteln können.
Die Kemp Load Balancer wollte ich auch für mich haben aber die stecken noch in den Kinderschuhen was die Authentifizierung angeht. Wenn man da in einer SubVS eine nicht existierende oder leere Gruppe einträgt - kommen alle User vom AD rein (anders herum finde ich logischer). Einmal authentifiziert z.B. owa kann man auch, wenn allgemein aktiviert, auch ins ecp rein. Soll mit V3 gefixt werden.
Dazu hier die Kopie vom Ticket:
I believe the issue here si the use of Permitted Groups across Sub VSs
Once a user is authenticated to one SubVs it will not seek to authenticate them again.
i.e. If Administrator is allowed access to OWA they will be allowed access to all SubVSs
This is something which we are planning to change with the next release of ESPV3
Gruß
der 2012er bringt einen eigenen Reverse Proxy, auf Basis des IIS, mit. Dort müsstest Du eigentlich über Gruppen was basteln können.
Die Kemp Load Balancer wollte ich auch für mich haben aber die stecken noch in den Kinderschuhen was die Authentifizierung angeht. Wenn man da in einer SubVS eine nicht existierende oder leere Gruppe einträgt - kommen alle User vom AD rein (anders herum finde ich logischer). Einmal authentifiziert z.B. owa kann man auch, wenn allgemein aktiviert, auch ins ecp rein. Soll mit V3 gefixt werden.
Dazu hier die Kopie vom Ticket:
I believe the issue here si the use of Permitted Groups across Sub VSs
Once a user is authenticated to one SubVs it will not seek to authenticate them again.
i.e. If Administrator is allowed access to OWA they will be allowed access to all SubVSs
This is something which we are planning to change with the next release of ESPV3
Gruß
wenn ich das richtig verstanden habe sollen einige Benutzer via Web APP auf den Exchange zugreifen können und andere nicht oder? Dies kannst du jedem Benutzer separat erlauben oder verbieten. (Oder du definierst dafür eine Richtlinie)
Im Exchange in der Postfachkonfiguration der Empfänger gibt es einen Menüpunkt "Postfachfunktionen" dort kannst du genau einstellen was der User machen darf und was nicht. (Also etwa Web App, Active Sync, Mapi usw.)
Natürlich wird die Login Seite dann immer noch angezeigt und man könnte sich versuchen anzumelden, bekommt dann jedoch die Meldung das diese Funktion deaktiviert wurde.
Was die Lösung mit der FW anbelangt, das ist natürlich die umfassendere Lösung weil man hier auch genauer festlegen kann von welchen Quellen, welche Dienste Zugriff auf den Exchange haben. Ich persönlich kann in dem Zusammenhang Sophos empfehlen, da mir persönlich die Arbeit damit einfacher von der Hand geht als etwa mit Ipfire. Nun ist die Sophos FW eigentlich ein kommerzielles Produkt, jedoch bietet Sophos soweit ich weiß auch eine abgespickte Version zur freien Verwendung an.
http://www.sophos.com/de-de/products/free-tools/sophos-utm-essential-fi ...
Gruß
Dante
EDIT: Oh sehe es gerade, geht mehr um den internen und externen Zugriff, dann ist mehr der letzte Absatz interessant ^.^
Im Exchange in der Postfachkonfiguration der Empfänger gibt es einen Menüpunkt "Postfachfunktionen" dort kannst du genau einstellen was der User machen darf und was nicht. (Also etwa Web App, Active Sync, Mapi usw.)
Natürlich wird die Login Seite dann immer noch angezeigt und man könnte sich versuchen anzumelden, bekommt dann jedoch die Meldung das diese Funktion deaktiviert wurde.
Was die Lösung mit der FW anbelangt, das ist natürlich die umfassendere Lösung weil man hier auch genauer festlegen kann von welchen Quellen, welche Dienste Zugriff auf den Exchange haben. Ich persönlich kann in dem Zusammenhang Sophos empfehlen, da mir persönlich die Arbeit damit einfacher von der Hand geht als etwa mit Ipfire. Nun ist die Sophos FW eigentlich ein kommerzielles Produkt, jedoch bietet Sophos soweit ich weiß auch eine abgespickte Version zur freien Verwendung an.
http://www.sophos.com/de-de/products/free-tools/sophos-utm-essential-fi ...
Gruß
Dante
EDIT: Oh sehe es gerade, geht mehr um den internen und externen Zugriff, dann ist mehr der letzte Absatz interessant ^.^
Zitat von @wiesi200:
Mal abgesehen davon das das mit VPN auch funktionieren würde und ich mich frage was die Absicherung damit zu tun hat das du
nur 1 Zertifikat für intern und extern hast würd ich auch die Lösung von Dani empfehlen.
Jetzt wo Du's explizit erwähnst, fällt mir das auch gerade auf. face-smile Danke für den Denkanstoß.Mal abgesehen davon das das mit VPN auch funktionieren würde und ich mich frage was die Absicherung damit zu tun hat das du
nur 1 Zertifikat für intern und extern hast würd ich auch die Lösung von Dani empfehlen.
@all
Danke für Eure Anregungen
Ich werd mir die einzelnen genannten Produkte näher ansehen und dann entscheiden - wobei ich aktuell zur Linux Lösung tendiere.
