oWA 2003 am ISA 2004 veröffentlichen

[MikeKellner 10]

Hallo, ich möchte die OWA Site des Exchange 2003 auf dem ISA 2004 so v eröffentlichen, dass der ISA die Anfrage auf die Site auf den Exchange entsprechend weiterleitet. Leider nur habe ich kaum Ahnung von ISA und wäre über jede Hilfe Dankbar.

 

Gruß Mike

[s.k. 11]

http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/OWA_FBA.htm

oder

http://www.isaserver.org/tutorials/Enabling-ISA-Firewall-Forms-based-Authentication-OWA-Connections-Internal-External-Clients-Part1.html

http://www.isaserver.org/tutorials/Enabling-ISA-Firewall-Forms-based-Authentication-FBA-OWA-Connections-Internal-External-Clients-Part2.html

 

Gruß

Steffen

[GuentherH 61]

Hi.

 

Ist auch noch empfehlendswert - http://blogs.technet.com/mkalbe/archive/2005/09/09/ALF_firewall_exchange2003.aspx

 

LG Günther

[MikeKellner 10]

Danke für die Hilfe. Nun möchte ich noch folgende Konstellation testen.

 

Client-ISA2004 als CacheProxy-Trendmicro VirusWall Proxy

 

Doch wie kann ich dem ISA den Trendmicro als Proxy aufdrücken?

 

Gruß Mike

[MikeKellner 10]

zu Owa noch eine Frage.

 

Würde eigentlich auch eine einfache Webveröffentlichúngsregel oder Mailserverregel funktionieren oder muss FBA oder die SSL Variante zwingend genutzt werden?

 

Gruß Mike

[s.k. 11]

Hallo Mike,

 

MikeKellner:

Client-ISA2004 als CacheProxy-Trendmicro VirusWall Proxy

Doch wie kann ich dem ISA den Trendmicro als Proxy aufdrücken?

Die VW ist in diesem Fall Upstreamproxy. Geht ganz simpel über eine Webverkettung: http://www.msisafaq.de/Anleitungen/2004/Konfiguration/Webverkettung.htm

Angenehmer Nebeneffekt einer solchen Verfahrensweise: Du kannst einen (wegen der Clientauthentifizierung gegenüber AD) intern stehenden und in die Domäne eingebundenen ISA-Proxy sowie die daran angeschlossenen Clients im Hinblick auf externe DNS-Auflösungen "dumm" halten. Eine externe DNS-Auflösung muss nur der Upstreamproxy können. Dieser steht idealerweise in einer DMZ.

 

MikeKellner:

Würde eigentlich auch eine einfache Webveröffentlichúngsregel oder Mailserverregel funktionieren oder muss FBA oder die SSL Variante zwingend genutzt werden??

Man muss hier ein paar Fragen trennen:

1. Authentifizierungsverfahren:

Die per default verwendete windowsintergrierte Auth. macht meines Erachtens wenig Sinn, wenn der Zugriff aus dem Internet erfolgt. Da diese Hosts ohnehin nicht die Logininfos der Domäne verwenden werden, klappt der Single sign on nicht - es kommt eine Eingabemaske hoch. Da die Standardauth. die Passwörter aber unverschlüsselt überträgt, ist die formularbasierte Auth. i.V.m. SSL-Verschlüsselung die beste Wahl.

Damit die User dort nicht immer Domänenname\Username eintragen müssen, sorge ich dafür, dass der User Pricipal Name mit der email-Adresse übereinstimmt. Dann können sich die User sowohl beim OWA als auch bei der Windows-Anmeldung im LAN mit ihrer email-Adresse als Benutzernamen anmelden. Das verstehen auch die dümmsten User...

2. Zugriffsregelung per Firewall:

Der einfachste Weg wäre es natürlich, Zugriffe von außen über TCP-Port 443 einfach zum intern stehenden IIS/Ex weiterzuleiten. Dies ist aber nicht empfehlenswert.

1. Nachteil: Du kannst nicht in den Datenverkehr reinschauen und auf Applikationsebene filtern.

2. Nachteil: Du lässt direkten Datenverkehr zwischen WAN und LAN zu. Das widerspricht zu Recht den Grundsätzen für einen sicheren Betrieb. Ein Zugriff von extern aufs LAN sollte nie direkt möglich sein, sondern nur über einen "Mittler", den Du gesondert kontrollieren kannst.

 

Ich favorisiere folgende Konfig:

 

~Internet~

|

o

[Drittanbieter-Firewall]o--(DMZ)--[iSA2004]

o

|

(LAN)

|

[Exchange]

 

Die Firewall lässt SSL nur zwischen Internet und DMZ sowie zwischen DMZ und LAN zu. Der direkte Zugriff WAN-->LAN ist verboten.

Am ISA wird der SSL-Tunnel aus dem Internet terminiert, der darin übertragene Verkehr so gut es geht auf Layer 7 inspiziert (siehe der Link von GuentherH) und über einen gesonderten SSL-Tunnel zum Exchange übertragen.

Hinweis: der ISA ist natürlich nicht Mitglied der Domäne, sondern dient bestenfalls einem intern stehenden (und die Clients erforderlichenfalls gegenüber AD authentifizierenden) Proxy als Upstreamproxy (siehe oben).

 

Gruß

Steffen