OWA mit ISA-Server und SSL
Eine Besonderheit ist zu beachten, wenn Sie Exchange auf dem gleichen Server betreiben, wie einen ISA-Server. Der Microsoft ISA-Server hat die Eigenschaft, nicht nur als Firewall und Proxy auf Port 8080 zu agieren, sondern auch eine so genannte "Serververöffentlichung" zu unterstützen. Dazu bindet sich der ISA-Server per Default auf den Port 80 und 443. Damit kommt er natürlich ganz klar dem IIS mit Exchange in die Quere. Das Ergebnis ist ein nicht funktionierender OWA und Probleme mit der Verwaltung öffentliche Ordner, welche ebenfalls per HTTP administriert werden.
Lesen und verstehen Sie auch die SSL-Grundlagen, SAN-Zertifikate und OWA Absichern
Siehe dazu auch Exchange Webseite absichern - Überlegungen zur Absicherung der Exchange Webdienste
ISA Verbiegen
Wenn Sie die ISA-Veröffentlichung nicht benötigen, dann können sie dem ISA-Server einfach den Port 80 z.B.: auf 81 verbiegen. Damit kann ihr IIS direkt am Internet betrieben werden und sie haben kaum Probleme. Der IIS schreibt fleißig seine Protokolldateien zur Auswertung und und auch sonst haben Sie nahezu alle Möglichkeiten. Leider ist damit der IIS natürlich nicht besonders gesichert.
OWA über ISA/TMG-Server veröffentlichen
- White Paper - Publishing Exchange Server 2010 with Forefront
http://go.microsoft.com/fwlink/?LinkId=197136
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=894bab3e-c910-4c97-ab22-59e91421e022&displaylang=en - Using IPsec to Secure Access to Exchange
http://go.microsoft.com/fwlink/?LinkId=207227
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e0aef6d7-921b-4aa0-be86-ef56ba078a22&displaylang=en - Using TMG and UAG to Securely Publish Outlook Web App and Exchange
Activesync with Certificate Based Authentication
http://go.microsoft.com/fwlink/?LinkId=207228
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=04eea304-999b-41c4-a7b3-02c99681ae74&displaylang=en - Sichere Exchange Veröffentlichung mit ISA Server 2004
http://blogs.technet.com/mkalbe/archive/2005/09/09/ALF_firewall_exchange2003.aspx - "Application Layer Firewall protection für Exchange Server 2003 with
ISA Server 2004"
http://www.Microsoft.com/technet/prodtechnol/isa/2004/plan/firewall-exchange2003.mspx - Video: Securely publishing Exchange 2003 OWA using ISA Server 2004
http://msexchangeteam.com/videos/9/owamobility/entry427651.aspx -
IT's Showtime Sichere Exchange Veröffentlichung mit ISA Server 2004
http://www.Microsoft.com/germany/technet/itsshowtime/sessionh.aspx?videoid=138 -
Einschränkungen bei ISA mit einer Netzwerkkarte
http://www.microsoft.com/technet/isa/2004/plan/single_adapter.mspx - 308599 How to configure Internet Security and Acceleration Server to publish an internal Exchange server
-
PDF-Dokument für den Einsatz des ISA2004 mit Exchange 2003 bei
Bundesbehörden
http://download.microsoft.com/download/f/6/2/f6296fd3-169c-4c45-8391-d7c9afcd5269/Musterkonfiguration%20-%20Ver%C3%B6ffentlichung%20von%20Exchange%202003%20%C3%BCber%20ISA%20Server%202004.pdf -
Verwenden von ISA Server 2006 mit Outlook Web Access
http://technet.microsoft.com/de-de/library/aa996545%28EXCHG.80%29.aspx - 941293 Error message when you access a Web site through ISA Server 2006 or Microsoft Forefront Threat Management Gateway, Medium Business Edition: "HTTP 400 - Bad Request"
Bei diesem Weg laufen beide Server wie gehabt auf dem gleichen Port. Denn ein umkonfigurieren des IIS auf einen anderen Port als Port 80 ist nicht möglich. Sonst können Sie keine öffentlichen Ordner mehr administrieren und mehr.
Damit diese Konfiguration möglich ist, müssen Sie das so genannte "Socketpooling" abschalten. Erst dann gibt der ISA-Server Ports frei, die er nicht benutzt. Zudem müssen Sie zwei Netzwerkkarten haben. Eine Externe zum Internet und eine zweite zum internen Netzwerk. Die Details der Konfiguration finden Sie unter: Nachteilig ist hierbei, dass der Zugriff von Außen nicht mehr in den Protokollen des IIS auftauchen, sondern im ISA-Server. Dafür hat man aber den Schutz des ISA-Servers. Immer wieder ist es eine Frage, wie man den Exchange 2000/2003 Outlook Webzugriff sichert. Und die Verwirrung ist groß, da Begriffe wie ISA, Reverse Proxy, NAT, Frontendserver, SSL etc. immer vermischt werden. Etwas Klarheit soll diese Seite bringen.
Sicherheitslücke SSL !!!
Information zum Exploit
Deutsch:
http://www.Microsoft.com/germany/ms/technetservicedesk/
bulletin/bulletinMS04-011.htm
Englisch:
http://www.Microsoft.com/technet/security/bulletin/ms04-011.mspx
Lösung
Deutsch:
http://www.Microsoft.com/germany/ms/security/pctdisable.mspx
Englisch:
http://www.Microsoft.com/security/incident/pctdisable.asp
Wen Sie nur einen einzigen Exchange Server ohne ISA oder Frontend Server per SSL erreichbar machen wollen, dann laden Sie sich von weiter untern einfach das SSL-Zertifikat samt private Key des OWA-Servers herunter, installieren Sie es, und lassen den Zugriff auf Port 443 auf ihren Exchange Server zu.
Die hier zum Download angebotenen Zertifikate sind von
einer selbst installierten CA erstellt, kostenfrei und nicht
vertrauenswürdig. Sie ersparen sich bei der Nutzung dieser Zertifikate
lediglich den Aufbau einer eigenen Zertifizierungsstelle zu Testzwecken
(Siehe
CA installieren)
Die Zertifikate sind für den Testeinsatz gedacht und erlauben eine
schnelle prinzipielle Funktionskontrolle von SSL über ihren Webserver,
Firewall etc. Daten werden auch verschlüsselt. Allerdings können Sie beim
Zugriff aus dem Internet nicht sicher sein, dass ihre Anfragen auch
wirklich auf ihrem Server gelandet sind. Sie sollten im produktiven
Betrieb auf jeden Fall offizielle Zertifikate nutzen.
Unterstützung durch
Net at
Work:
Wir helfen ihnen gerne bei der Beantragung und
Installation eines offiziellen Zertifikats.
Risiko und Probleme
Der Exchange 2000/2003 OWA-Zugriff ist sehr leistungsfähig aber auch zugleich sehr angreifbar, wenn keine Schutzmechanismen erfolgen. Risiken und Probleme sind:
- Nicht verschlüsselt
Da die meisten Browser über das Internet und Proxies keine NTLM-Autorisierung können und Kerberos und Zertifikate noch nicht üblich sind, bleibt nur die "Basic Authentication". Dies bedeutet, dass die Klartextkennworte ohne entsprechenden Schutz sind. Die Antwort heißt SSL. Es muss aber nicht immer ein offizielles Zertifikat sein. Eigene tun es auch für einen Test oder wenn die Garantie auf dem richtigen Server zu sein weniger wichtig ist. - Unsicherer IIS
Outlook Webzugriff braucht nur einige weniger Verzeichnisse, die per URL erreichbar sein müssen (EXCHANGE, EXCHWEB) und optional PUBLIC und OMA. Ein IIS hat aber viel mehr Verzeichnisse. Und da man nie sicher sein kann, dass im Nachhinein niemand am IIS was macht, ist ein Filter davor sinnvoll, der die URLs entsprechend kontrolliert. Die Antwort hierzu heißt URLSCAN auf dem Server selbst oder ISA-Server Webveröffentlichung (oder ein andere Reverse Proxy mit selektiver Veröffentlichung. - Viele Server
Im Gegensatz zu Exchange 5.5 verbindet sich der Client immer direkt mit dem Postfachserver. Beim Zugriff auf den "falschen" Server wird der Client umgeleitet. Nun wird niemand alle Postfachserver mit eigenem Namen und SSL-Zertifikat im Internet erreichbar machen. Die Lösung hierzu heißt "Frontendserver". Ein Frontend Server ist einfach nur ein Exchange Server, der "intelligent" ist und die eingehenden Verbindung an den richtigen Backend weiterleitet. Die Funktion ist eher mit dem ReverseProxy zu verstehen
Sie sehen es ist gar nicht so schwer. Und sie brauchen einen Frontend Server eigentlich nur, wenn Sie mehrere Backend Server unter einem Namen veröffentlichen wollen.
Zu den Zertifikaten
Die Nutzung von SSL erfordert, dass die Server über entsprechende Zertifikate verfügen. die Verschlüsselung erfolgt über Public Key/Private Key Verfahren und die Gültigkeit des Zertifikats garantiert den richtigen Public Key. Die Gültigkeit wird durch die ausstellende CA bestätigt, die ihrerseits auch ein Zertifikat bereitstellt. Ein System vertraut nur den Zertifikaten, die von einer vertrauenswürdigen Stelle ausgestellt wurden. Damit das System weiß, was "vertrauenswürdig" ist, gibt es eine Liste dieser Zertifikate, die mit der Installation des Browsers eingerichtet wird. Sie vertrauen also dem Datenträger und Hersteller, der ihnen diese erste Liste mitliefert.
Hierbei gibt es genau genommen drei Zertifikate.
- Stammzertifikat der Zertifizierungsstelle
Dieses Zertifikat enthält den öffentlichen Schlüssel der Zertifizierungsstelle. Sie habe auf ihrem PC mit der Installation des Betriebssystems oder Browsers einige Stammzertifikate (Verisign, Thawte und andere) erhalten. - Zertifikat mit privatem Schlüssel auf dem Webserver
Der Webserver hat ein Zertifikat, dass er dem Client senden kann. An dieses Zertifikat ist der private Schlüssel gebunden, damit der Server die Daten verschlüsseln kann - Zertifikat auf dem Client
Beim Verbindungsaufbau per SSL sendet der Server sein Zertifikat unverschlüsselt und ohne privaten Schlüssel an den Client. Dieser kann nun die Daten dort prüfen (Ist die ausstellende Zertifizierungsstelle vertrauenswürdig) und dann entsprechend eine Warnung anzeigen oder vorsetzen. Der Client hat nun garantiert den richtigen öffentlichen Schlüssel. für die Kommunikation
Wenn Sie nun selbst eine Zertifizierungsstelle installiert haben und ihre eigenen Zertifikate ausstellen, dann kann damit eine verschlüsselte Verbindung aufgebaut werden, aber der Client bekommt die Warnung. Viele Programme (wie auch der ISA-Server) können die Warnung aber nicht anzeigen. Daher müssen Sie später nachhelfen.
Überlegen Sie sich, ob wie wirklich dann auf allen
Endgeräten ihr Stammzertifikat installieren wollen oder nicht einfach ein
offizielles Zertifikat einfacher zu nutzen ist. So bietet z.B. GoDaddy ein
Serverzertifikat für unter 20 US-$/Jahr an.
https://www.godaddy.com/gdshop/ssl/ssl.asp
Bei
http://www.comodo.com können sie
kostenfrei ein Zertifikat für 90 Tage erhalten
Alternativ können Sie einfach unter dem Link https://www.t-refer.com/t-refer/DENETATW-1 bei Thawte ein Zertifikat bestellen (Vermittlungsprovision kommt der MSXFAQ zugute). Natürlich beraten und unterstützen wie Sie auch bei der Beantragung und Installation.
Zertifikate könne auf dem PC in verschiedenen Zertifikatsspeichern abgelegt werden. So gibt es einen Speicher für den angemeldeten Benutzer aber auch einen für den Computer und für Dienstkonten etc. Dazu später mehr.
Die Kette
Folgende Konfiguration wird für die Beschreibung definiert
- Die Clients greifen aus dem Internet auf einen ISA-Server in einer DMZ per SSL zu. Die Firewall lässt dazu Port 443/TCP passieren. Da die DMZ schon mit privaten Adressen arbeitet, muss die Firewall die Adressen umsetzen.
- Der ISA-Server leitet die eingehenden Anfragen an den oder die Frontend Server im internen Netzwerk weiter. Am ISA-Server endet die SSL-Verbindung des Client von außen. Der ISA-Server hat als Default Gateway die externe Firewall und kennt über Leitwege die internen Netzwerke. Denkbar ist sogar die Beschränkung der Leitwege auf die Frontend Server.
- Die Verbindung zum Frontendserver kann ebenfalls per SSL gesichert werden. Die ist nicht zwingend. Die Frontend Server können über Network Load Balancing (Bis zu 32 Server teilen sich eine virtuelle IP-Adresse)
- Die Frontend Server leitet die Anfragen ihrerseits an die entsprechenden Postfachserver im Hintergrund weiter. Hier ist keine weitere Firewall eingeschaltet. SSL ist hier NICHT möglich. Wenn der Bedarf nach einer Verschlüsselung erforderlich ist, dann ist IPSec (Verschlüsselung auf IP-Layer) möglich.
Die Webserververöffentlichung auf dem ISA-Server können Sie mit dem SP1 mit einem eleganten Assistenten durchführen.
Die NetzwerkUmgebung für die folgende Beschreibung sieht so aus:
Im Bild sehen Sie insgesamt fünf Zertifikate, die für den Betrieb relevant sind und bei Bedarf installiert werden müssen. Dies ist insbesondere wichtig, wenn Sie eigene Zertifikate ausstellen.
|
Das Stammzertifikat auf den Frontend Servern ist für den Betrieb nicht zwingend. Es kann Systeme geben, die ein Webzertifikat nur dann verwenden, wenn auch das dazugehörige Stammzertifikat installiert ist. Dies erfordert Windows 2003 nicht. Allerdings erlaubt ihnen das installierte Stammzertifikat das problemlos "Surfen" auf dem Frontendserver auf https://servername:443/exchange für Testzwecke. |
|
Damit der Frontend Server den Zugriff des Client per SSL zulässt, muss für den Frontend Server ein Webserverzertifikat ausgestellt werden. Der Name
des Zertifikats "MUSS" auf den Namen oder die IP-Adresse lauten, mit der
später die Clients bzw. der ISA-Server auf den Frontendserver zugreift. TESTEN Sie diese Funktion, indem Sie mit einem Browser auf den Frontend Server zugreifen, z.B.: vom späteren ISA-Server aus. Kontrollieren Sie die Fehlermeldung: Der Name muss passen, der Zeitraum des Zertifikats muss gültig sein. Wenn die Zertifizierungsstelle nicht erkannt wird, dann lesen sie in der nächsten Zeile weiter |
|
Wenn der ISA-Server zum Frontendserver eine SSL-Verbindung aufbauen
soll, dann muss der Hostname in der URL, die in der Webveröffentlichung als
Weiterleitungsziel genutzt wird, identisch mit dem Namen im CERT2 sein. Weiterhin muss der ISA-Server der ausstellenden Zertifizierungsstelle vertrauen. ACHTUNG: Es reicht nicht, dass Zertifikat der CA als Benutzer zu installieren. Sie müssen die Management Konsole nutzen, um das Rootzertifikat der CA in den Zertifikatsspeicher des lokalen Computers zu importieren !!!
Testen Sie nach dem Import erneut den Zugriff vom ISA-Server auf den Frontend Server. Diesmal muss der Zugriff ohne eine Warnung funktionieren. |
|
Damit die Systeme aus dem Internet per SSL zugreifen können, muss auch
der ISA-Server ein Zertifikat erhalten. In diesem Zertifikat muss stehen:
Werden eigene Zertifikate erstellt, dann sollten Sie das Stammzertifikat den Clients zum Download anbieten oder innerhalb des Netzwerks mit einer Gruppenrichtlinie verteilen. |
|
Der Client erhält das Zertifikat des ISA-Servers und prüft die
Parameter. Findet der Client nicht die ausstellende CA in seiner Liste, dann
kommt die bekannte Fehlermeldung:
Sie können diese Meldung unterdrücken, wenn Sie die das Stammzertifikat der ausstellenden CA (Hier MSXFAQ intern CA) auf dem Computer als vertrauenswürdig hinzufügen. |
SAN Zertifikate:
Wenn Sie auf dem Exchange Server ein SAN-Zertifikat verwenden, dann muss der ISA
Server auf das erste Zertifikat in der Liste der "alternativen Namen" zugreifen.
Ansonsten bekommen Sie einen Serverfehler "500 Zielprizipalname ungültig"
Alles ganz einfach oder ?
Zertifikate
Bleibt nur das Problem, woher Sie ein entsprechendes Zertifikat erhalten. Natürlich können Sie bei Verisign, Thawte und vielen anderen vertrauenswürdigen Stammzertifikatstellen ein offizielles Zertifikat kaufen. Das sollten Sie später auch für den Einsatz in der ProduktionsUmgebung vorsehen. Aber für die ersten Tests und Installationen reichen auch einfache selbst erstellte Zertifikate. Diese können Sie mit dem Zertifikatsserver jederzeit erstellen.
Ale kleinen Service habe ich mir erlaubt, eine Muster CA zu installieren und damit zwei Webserverzertifikate zu erstellen und diese inklusive "private Key" zu exportieren. Sie können diese Zertifikate einfach herunterladen und auf dem korrekten Server importieren.
Zertifikat der ausstellenden Zertifizierungsstelle (Muster). Installieren Sie dieses Zertifikat (enthält KEINEN private Key) auf dem ISA-Server als vertrauenswürdiges Stammzertifikat. Ansonsten kann der ISA-Server die SSL-Verbindung zum Frontend Server nicht aufbauen. Gültig vom 19.6.2006 bis 19-6.2011 |
|
Zertifikat für den Frontend Webserver. Installieren Sie dieses Zertifikat auf dem IIS des Webserver (z.B.: über "Import aus einer pfx-Datei". Beim Import werden Sie nach einem "Kennwort gefragt. Dies ist der kleine Schutz, weil diese Datei auch den "private Key" enthält. Das Kennwort ist "Password!" Gültig vom 19.6.2006 bis 19-6.2007 |
|
Zertifikat für den ISA-Server. Installieren Sie dieses Zertifikat auf dem ISA-Server mit der Management Konsole - Zertifikate in den Bereich "Eigene Zertifikate" des "Local Computer". Auch hierbei wird wieder ein Kennwort abgefragt, diese Datei auch den "private Key" enthält. Das Kennwort ist "Password!" Gültig vom 19.6.2006 bis 19-6.2007 |
Nun müssen sie nur noch folgendes sicherstellen:
- Stellen Sie die Namenauflösung im DNS derart ein, dass ein Zugriff aus dem Internet auf das System "owa" auf dem ISA-Server landet. Dies kann durch die Pflege des Eintrags in der lokalen HOSTS-Datei erfolgen oder einen "owa"-Eintrag im DNS-Server der Zone, in der auch der Client ist. Windows hängt das eigene DNS-Suffix bei einer Anfrage mit an. Notfalls geht natürlich auch ein Zugriff auf die IP-Adresse, nur dass dann der Browser nicht nur die nicht vertrauenswürdige ausstellende CA meldet, sondern auch dass der Hostname nicht stimmt. Verschlüsselt wird aber trotzdem
- Stellen Sie sicher, dass der ISA-Server bei einem Zugriff auf den Hostname "frontend" auf die IP-Adresse des Frontend Servers gelangt.
- Stellen Sie in der ISA-Webveröffentlichung unter "Aktion" den Hostname "frontend" ein. Bitte hier KEINE IP-Adresse oder frontend.firma.local eintragen. Der Name hier MUSS mit dem Namen des Zertifikats auf dem Frontend Server übereinstimmen.
Wenn sie nun nichts falsch gemacht haben, dann haben Sie einen SSL Zugriff zu ihrem Server. Übrigens können Sie die internen Zertifikate durchaus weiter benutzen und nur das externe "OWA"-Zertifikat durch ein offizielles ersetzen.
ACHTUNG: Die Musterzertifikate sind nicht für den produktiven Gebrauch, sondern nur für Tests und ersparen ihnen die Installation einer eigenen CA für Testzwecke.
Überlegen Sie sich, ob wie wirklich dann auf allen
Endgeräten ihr Stammzertifikat installieren wollen oder nicht einfach ein
offizielles Zertifikat einfacher zu nutzen ist. So bietet z.B. GoDaddy ein
Serverzertifikat für unter 20 US-$/Jahr an.
https://www.godaddy.com/gdshop/ssl/ssl.asp
Bei
http://www.comodo.com können sie
kostenfrei ein Zertifikat für 90 Tage erhalten
Alternativ können Sie einfach unter dem Link https://www.t-refer.com/t-refer/DENETATW-1 bei Thawte ein Zertifikat bestellen (Vermittlungsprovision kommt der MSXFAQ zugute)
- Diese Zertifikate sind nur zum Test und laufen im Januar 2006 aus.
- Dies sind keine vertrauenswürdigen Zertifikate und sichern nicht, dass Sie ihren Webserver erreicht haben !
- JEDER kann diese Zertifikate installieren. Sie können nicht sicher sein ihren eigenen Server erreicht zu haben !
- Installieren Sie das Stammstellenzertifikat wirklich NUR auf dem ISA-Server und nie auf einem Client.
- Akzeptieren Sie später beim Test die Warnung auf dem Client aber vertrauen Sie der "Muster-CA" nicht.
- Die Anzeige auf dem Client kann verzögert sein, wenn der Client versucht die CRL (Rückrufliste) zu erhalten. Es gibt keine CRL zum Download.
Veröffentlichung.
Mit jeder neueren Version des ISA-Servers wurden die Assistenten zum Einrichten einer Veröffentlichung umfangreicher. Über das Kontextmenü können Sie direkt den Exchange Webzugriff einrichten.
Nach der Eingabe eines Namens für die neu anzulegende Regel bietet der ISA2006 die Exchange Version 5.5 bis 2007 an. Wenn Sie einen Exchange 2010 Server veröffentlichen wollen, dann nutzen Sie bitte einfach Exchange 2007 und ergänzen Sie danach die erforderlichen Pfade für /ECP und /EWS. Der Nachfolger namens Forefront Thread Management Gateway bietet auch Exchange 2010 an:
Wenn Sie z.B. Exchange 2007 auswählen, dann wird aus "Outlook RPC/HTTP(s)" auch noch schnell ein "Outlook Anywhere". Es bietet sich generell an, die verschiedenen Dienste über einzelne Veröffentlichungsregeln bereit zu stellen, so dass einzelne deaktiviert oder verändert werden können. Wenn Sie Exchange 2007 auswählen, dann werden Sie durch den Assistent dazu auch gezwungen. In den folgenden Fenstern werden Sie durch den Assistenten noch weitere Dinge gefragt, die ich aber nicht als Bilderflut hier wieder geben:
- Ziel: Server oder Farm
ISA2006 kann Anfragen von Außen auch auf mehrere interne CAS-Server verteilen. Ich denke mal, dass die meisten MSXFAQ-Leser einen einzelnen internen Server veröffentlichen wollen. Wer intern schon die CAS-Server per "NLB" betreibt, muss hier auch "Single Server" wählen. Eine Farm ist nur dann passend, wenn wirklich mehrere Server intern mit eigener IP-Adresse betrieben werden. - Zugriff nach innen auf den Exchange Server per SSL
oder ohne Verschlüsselung erfolgt
Sicherer ist, wenn der Weg zwischen ISA und Exchange auch per SSL gesichert ist. Sie müssen dann aber auf dem CAS ein passendes Zertifikat haben, welchem der ISA vertraut und vom Namen her übereinstimmt. Das kann auch ein Selbstzertifikat sein. Ist das Netzwerk ausreichend. - Interner Sitename und optional IP-Adresse
Dies ist der Name des internen veröffentlichten Webservers. Wenn der ISA-Server den Namen nicht auf die interne Adresse auflösen kann (z.B. weil ihre DNS-Konfiguration nicht passt), dann müssen Sie die IP-Adresse eintragen. Beachten Sie, dass der Name auch mit dem Namen im internen SSL-Zertifikat übereinstimmen muss und auch Hostheader passen müssen. - Filterung nach Domainname
Ein Listener des ISA kann über ein SAN-Zertifikat problemlos mehrere Hostnamen bedienen. Hierüber können Sie sich dann "ihren" Namen herausfiltern, so dass nur Anfragen an genau den Namen für die Regel zutreffen. - Listener Auswählen
Wählen Sie nun aus der Menge der konfigurierten Listener den passenden Eintrag aus. - Authentifizierung
Abhängig, ob der ISA nun eine Vorauthentifizierung macht, oder Sie die Anfragen "anonym" bis zum Anmeldeformular ihres CAS-Server zulassen, ist hier entsprechend die Authentifizierung einzustellen. Nett ist es schon, wenn der ISA eine Anmeldung prüft aber erzwungen ist es nicht. Sie können beides machen. - Benutzersätze
Wenn der ISA-Server keine Anmeldung prüft, muss hier "Alle Benutzer" stehen bleiben, damit die Anfrage durchkommt. Wenn der ISA aber die Anwender schon authentifiziert, dann können Sie hier z.B.: über eine Gruppe ebenfalls den Zugriff von Extern selektiv unterbinden.
Der Assistent legt die Regel an und sie müssen diese nur noch speichern.
OWA 2010 mit ISA 2006
ISA2006 unterstützt noch nicht Exchange 2010. Daher müssen Sie nach der Einrichtung über den Assistenten noch ein paar Dinge korrigieren. Die meisten Karteikarten sind einfach zu beantworten aber folgende drei Einstellungen sind wichtig:
|
In diesem Fenster ist die Linkübersetzung wichtig, damit alle URLs, die von intern mit dem internen Namen generiert werden, nach außen auf den offiziellen Namen umgesetzt werden. Ansonsten werden Sie feststellen, dass einige Links später nicht funktionieren |
|
Der Exchange 2007 Assistent unterschlägt natürlich die beiden virtuellen Verzeichnisse /ECP/ und /EWS, die aber für die Nutzung von OWA von extern benötigt werden. Addieren Sie einfach diese beiden Pfade. Die beiden Pfade /Public/ und /Exchange/ benötigt Exchange 2010 eigentlich nicht mehr aber da der Exchange Server diese automatisch über eine IIS-Umleitung nach /OWA umleitet und Mitarbeiter oft noch den alten Pfad verwenden, können Sie diese weiterhin durchlassen. |
|
Auf dieser Seite die die Übertragung
des ursprünglichen Hostheaders wichtig.
Eigentlich würde ich diese Checkbox ja
raus nehmen, damit der ISA-Server nach
intern hier über den Namen "NAWEX001"
auf den Exchange 2010 Server zugreift. |
Fehlersuche und Behebung
Wenn wieder erwarten etwas nicht funktioniert, dann gibt es folgende kleine Fehlersuchanleitung.
Test 1: |
Starten Sie einen Browser auf dem Frontend Server oder einem
PC im gleichen Netzwerk. Damit schließen wir Filter durch die Firewall aus.
Deaktivieren Sie den Proxyeintrag im Browser und geben Sie den BACKENDSERVER
mit dem passenden Postfach ein: HTTP://backendserver/exchange Da auf dem Backend keine SSL-Verschlüsselung aktiv ist, sollten Sie nach einer Anmeldung Problemlos ihr Postfach sehen. NEIN: dann suchen Sie den Fehler auf dem Backend Server, z.B. mit Eventlog, Active Directory, Exchange etc. Diese Funktion muss möglich sein. |
Test 2: |
Starten Sie einen Browser auf dem Frontend Server oder einem
PC im gleichen Netzwerk. Deaktivieren Sie den Proxyeintrag im Browser und
geben Sie diesmal den Frontendserver ein: HTTP://frontendservername/exchange Wenn Sie keine Verschlüsselung auf dem Frontend Server aktiv haben, sollten Sie nach der Anmeldung ebenfalls ihr Postfach sehen. die URL in der Browserleiste muss aber den Frontend Server Namen behalten. Springt die URL auf den Backend Server, dann ist der angebliche Frontend Server nicht als solcher konfiguriert (Checkbox auf den Servereigenschaften) oder die Information ist noch nicht repliziert. Können Sie sich nicht anmelden, dann prüfen sie, ob im Browser die NTLM-Anmeldung deaktiviert ist. Alternativ sollten sie im IIS-Manager auf dem Frontendserver die Basic-Authentication einschalten und die integrierte Authentifizierung abschalten. |
Test 3: |
Wie Test 2, nur diesmal mit HTTPS. Geben Sie genau den
gleichen Hostnamen ein, den sie auch bei der Ausstellung des
Webserverzertifikats eingegeben haben https://frontendservername/exchange Eventuell meldet der Browser, das der ausstellenden CA nicht vertraut wird. Die sollte durch die Installation der Zertifikats der CA gelöst werden. Danach sollte der Zugriff ohne weitere Meldungen nach der Anmeldung möglich sein. |
Test 4: |
Der nächste Schritt entspricht Test 3 nur dass der Zugriff
vom ISA-Server aus erfolgt. Über diesen Weg wird geprüft, ob die interne
Firewall die Ports korrekt durchlässt. Geben Sie ein: https://frontendservername/exchange Die Anmeldemaske muss ohne weitere Rückfragen kommen. Meldet der Browser, dass das Zertifikat nicht in Ordnung ist, dann müssen Sie den Fehler korrigieren, z.B. Tippfehler in der URL, falsche IP-Adresse im DNS ? Sollte sich gar nicht tun, dann können Sie auch unter Angabe der IP-Adresse die Verbindung aufbauen. Allerdings ist dann die Warnung, dass der Hostname nicht übereinstimmt zu ignorieren. So wissen Sie, dass die Firewall zumindest Port 443/TCP durchlässt und es an ihrer Namensauflösung des ISA-Servers liegt. Tragen Sie den Namen des Frontendservers mit der IP-Adresse in die lokale ETC\HOSTS ein. Nun müsste die Verbindung auch mit dem Namen funktionieren. Auf keinen Fall darf eine Warnung bezüglich des Zertifikats kommen. Der Zugriff vom ISA auf den Frontend muss ohne Rückfrage nach dem Zertifikat möglich sein. Ansonsten ist die Installation des Zertifizierungsstellenzertifikats nicht korrekt erfolgt. ACHTUNG: Pflegen Sie beim ISA-Server im Firewall Mode unbedingt die Liste der lokale Adressen (LAT) ansonsten erkennt der ISA-Server das Subnetz des Backend Servers als extern und die Paketfilter verhindern den Zugriff. Ein ISA-Server in dieser Konstellation muss keine Firewall sein, sondern nur Cachen. |
Test 5: |
Suchen Sie sich ein weiteres Endgerät in der DMZ und surfen
sie von dort aus auf den ISA-Server und testen die Webveröffentlichung. Wenn
Sie mangels DNS und NAT die IP-Adresse eingeben müssen ist dies für den Test
in Ordnung. Nach der Warnung, dass der Name und eventuell die
Zertifikatsstelle nicht vertrauenswürdig ist, sollte die Verbindung möglich
sein. Ansonsten ist die Webveröffentlichungsregel auf dem ISA-Server zu kontrollieren. Auf dem ISA-Server darf kein IIS laufen da sich sonst beide Dienste um den Port 80 und 443 schlagen. (Stichwort SocketPooling) |
Test 6: |
Nun kommt der Moment der Wahrheit, wenn der erste Client von
Außen zugreift. Wenn alles richtig ist, dann verweist der DNS-Name im
Internet aus eine offizielle IP-Adresse der externen Firewall, welche die
Pakete auf die private Adresse des ISA-Servers in der DMZ umsetzt. Meldet der Client, dass das Zertifikat nicht gültig ist, dann ist die Hauptarbeit schon erledigt: Die Firewall ist korrekt konfiguriert und der ISA-Server antwortet. Abhängig von der Fehlermeldung geht es weiter. Eventuell haben Sie einfach das falsche Zertifikat installiert oder einen Tippfehler im Namen. Die Warnung, dass die ausstellende CA nicht vertrauenswürdig ist, ist wieder auf das Fehlen des Stammzertifikats im lokalen Speicher zurückzuführen. Sie können das Zertifikat einfach installieren oder sich ein offizielles Zertifikat einer anerkannten CA ausstellen lassen (Kosten !). |
Test 7 |
Versuchen Sie andere URLs anzusprechen, z.B.
https://servername/IISHELP oder /IISADMIN oder /PRINTERS oder /SCRIPTS etc.
Ein Portscan von Außen auf auf die Systeme ist ebenfalls eine kurze
Kontrolle auf andere Ports. Sicherheit ist ein permanenter Prozess. Aktivieren und Kontrollieren Sie die IIS-Logs und ISA-Server Logs. Auch wenn der Frontend Server durch den ISA-Server von Außen gesichert ist, kann er auch von intern erreicht werden. Sichern Sie den IIS des Frontend und Backend Servers mit URLSCAN und IISLOCKD. |
Sollten Sie bei einem Test nicht weiterkommen und der Test ist erfolglos ohne, dass Sie wissen warum, dann kann ich ihnen nur anbieten, als Dienstleistung ihre Konfiguration zu kontrollieren und den Fehler zu beseitigen.
Was ist mit POP3, IMAP4, SMTP ?
Auch diese Dienste können sicher übertragen werden. Die Nutzung des ISA-Servers und speziell der Webveröffentlichung erlaubt sehr gute Filter für die HTTP-Pakete. Solche Filter sind im ISA-Server für POP3, IMAP4 und SMTP möglich, aber nur wenn diese auch im Firewall Mode läuft. Der ISA-Server ist dann etwas ähnliches wie ein Reserve-NAT-System, welches eingehende Verbindungen auf TCP/IP-Ebene umsetzt. Hier sind die Filter aber nicht so ausgeprägt und auch weniger notwendig. Solche Dienste können z.B.: direkt von den Firewalls per NAT auf den Frontend Server umgesetzt werden. Beim ISA-Server mit einer Netzwerkkarte ist diese Funktion nicht einsetzbar.
Unterstützung durch
Net at
Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.
Weitere Links
- OWA URL - URLs die von OWA und anderen Dienste genutzt werden.
- OWA Absichern
- WebProxy
- SAN-Zertifikate
- Apache
- ISA2004 - Troubleshooting SSL Certificates in ISA Server 2004
Publishing
http://technet.microsoft.com/en-us/library/cc302619.aspx - Troubleshooting OWA 2007 Publishing Rules on ISA Server 2006
http://blogs.technet.com/isablog/archive/2008/04/29/troubleshooting-owa-2007-publishing-rules-on-isa-server-2006.aspx - ISA2004 - Troubleshooting SSL Certificates in ISA Server 2004
Publishing
http://technet.microsoft.com/en-us/library/cc302619.aspx
841664 Clients may receive an "Error Code 500 Internal Server Error" error message when they try to visit a Web site that you publish by using ISA Server 2006 or ISA Server 2004 - Whitepaper: Publishing Exchange Server 2007 with ISA Server 2006
http://www.microsoft.com/technet/isa/2006/deployment/exchange.mspx - Q837865 You receive a "The request was rejected by the HTTP Security filter" error message when you try to open a message from an Exchange Server that is published in ISA Server 2004
- 837354 How to publish a Microsoft Exchange server für Outlook Web Access in ISA Server 2004
- 299525 HOW TO: Set up SSL using IIS 5.0 and Certificate Server 2.0
- 304340 The ISA Server response to client options requests is limited to a predefined set
- 320291 XCCC: Turning on SSL für Exchange 2000 Server Outlook Web Access
- 234022 XCLN: Configuring Exchange OWA to use SSL
- 327544 How to configure SSL connections to Outlook Web Access in Small Business Server 2000
- 823024 HOW TO: Configure Certificate Services and OWA in SBS 2000
- 830827 How to use forms based authentication with Outlook Web Access clients in Exchange Server 2003
- 823486 Administrative and registry key settings für Exchange Server 2003 Outlook Web Access
- 905013 on "Enterprise firewall configuration für Exchange ActiveSync Direct Push Technology"
- SSL Diagnostics Version 1.1 (x86)
http://www.microsoft.com/downloads/details.aspx?FamilyID=cabea1d0-5a10-41bc-83d4-06c814265282&DisplayLang=en - Exchange 2003 SP2 Direct Push mit ISA Server 2004
http://blogs.technet.com/dmelanchthon/archive/2006/02/18/419897.aspx - MSXFAQ - OWA mit ISA und SSL
- Ausführliche Anleitungen auf der ISA FAQ
http://www.msisafaq.de/Anleitungen/2000/Server/Exchange_OWA.htm
http://www.msisafaq.de/Anleitungen/2000/Server/Exchange_OWA_FP1.htm - Exchange und Firewalls
- www.Microsoft.com/isaserver
- IIS6 ResKit
http://www.Microsoft.com/reskit
SelfSSL Programm um Eigenzertifikate zu erstellen. - www.isaserver.org
-
http://www.tacteam.net/isaserverorg/exchangekit/default.htm
http://www.isaserver.org/news/exchangekitbeta1.html
ISA Server 2000 Exchange 2000/2003 Secure Remote Email Access Deployment Kit - Introducing the ISA Server 2000 Exchange Server 2000/2003 Deployment Kit
http://www.isaserver.org/pages/article.asp?id=1164
www.tacteam.net/isaserverorg/exchangekit/ISAEXCHANGEKIT.zip - www.msisafaq.de
-
http://www.Microsoft.com/isaserver/setupserver2003.asp
Hinweise, wie ISA2000 auf Windows 2003 installiert wird. - Thomas Shinder: Front-end Back-end Exchange Server Trihomed DMZ Network Scenario. http://www.ISAserver.org/pages/article.asp?id=1221
- http://www.Microsoft.com/germany/ms/security/server/firewall/index.htm
-
http://www.Microsoft.com/germany/library/xml/technet/download/isaexch.doc
Microsoft ISA Server 2000 - Konfigurieren und Sichern von Servern und Clients mit Microsoft Exchange 2000 Server - Joining the Branch Office to the Main Office with ISA 2000 Firewalls:
Connecting to the Main Office Exchange Server from the Branch Office using RPC
over HTTP
http://www.ISAserver.org/pages/article.asp?id=1187 - Providing E-Mail Defense in Depth für Microsoft Exchange with the ISA 2004
Firewall SMTP Message Screener
http://www.MSExchange.org/pages/article.asp?id=632 - Publishing Outlook Web Access (OWA) Sites using ISA Server 2004 Firewalls
http://www.ISAserver.org/pages/article.asp?id=1202 - 331062 Running ISA Server on Windows Server 2003
- 816460 ISA Server 2000 Service Pack 2 Release Notes
mit der Liste aller Fixes. (ganz schön viele)
http://www.ISAserver.org/pages/article.asp?id=1225 - ISA Firewall Fairy Tales -- What Hardware Firewall Vendors Don't Want You to Know. http://www.ISAserver.org/pages/article.asp?id=1229
- Plädoyer für ISA-Server als Domain Member
http://isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html - Exchange Services aus dem Internet testen
https://www.testexchangeconnectivity.com/ - Internet Explorer unterstützt kostenlose Zertifikate
http://www.heise.de/newsticker/Internet-Explorer-unterstuetzt-kostenlose-Zertifikate--/meldung/145948
http://www.startssl.com/