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

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

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:


Bitte klicken zum öffnen

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.


Root
Cert

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.


Cert2

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


Root
Cert

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 !!!


Hier muss das Stammzertifikat hinein, ansonsten vertraut der ISA-Server, der als LocalSystem gestartet ist, nicht dem selbst ausgestellten Zertifikat des Frontendservers.

Testen Sie nach dem Import erneut den Zugriff vom ISA-Server auf den Frontend Server. Diesmal muss der Zugriff ohne eine Warnung funktionieren.


Cert1

Damit die Systeme aus dem Internet per SSL zugreifen können, muss auch der ISA-Server ein Zertifikat erhalten. In diesem Zertifikat muss stehen:
  • Der Name, unter dem die Clients später zugreifen
  • Das Zertifikat muss gültig sein
  • Die ausstellende CA sollte eine allgemein bekannte CA sein

Werden eigene Zertifikate erstellt, dann sollten Sie das Stammzertifikat den Clients zum Download anbieten oder innerhalb des Netzwerks mit einer Gruppenrichtlinie verteilen.


Root
Cert

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.


CA-Zert

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


frontend.pfx

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


isa.pfx

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.
Allerdings hat dies reproduzierbar zu "400 Bad Request"-Antworten des Exchange 2010 Server auf die Anfragen des ISA-Servers geführt, d.h. die Anmeldemaske von OWA 2010 war noch erreichbar aber nach Eingabe des Kennworts war keine weitere Nutzung mehr möglich.

Fehlersuche und Behebung

Wenn wieder erwarten etwas nicht funktioniert, dann gibt es folgende kleine Fehlersuchanleitung.

Test 1:
Backendserver

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:
Frontendserver

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:
Frontend SSL

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:
SSL vom ISA

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:
PC intern
auf ISA

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:
Zugriff von Außen

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
Sicherheit

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