EAS mit Zertifikaten und ISA 2006

Kaum jemand wird seinen Exchange Server "einfach so" über das Internet erreichbar machen und selbst ein NAT-Router mit Portfilter auf 443/TCP ist noch kein echter Schutz, wie Sie auf OWA Absichern auch nachlesen können. Ein ISA-Server oder ähnliches System, welches die HTTPS-Anfragen annimmt, entschlüsselt und die angeforderten URLs auf Gültigkeit überprüft ist sehr empfehlenswert.

Bis zum ISA2006 war es nur möglich, den Exchange ActiveSync mit Zertifikaten über eine Serververöffentlichung oder den Tunnel-Mode des ISA erreichbar zu machen. Oder gleich ein anderes Produkt einzusetzen. In diesen Fällen beschränkt sich die Prüfung auf die URLs aber nicht auf eine Authentifizierung. Und eine Anmeldung per Zertifikate ist auch konfigurationsabhängig.

Mit dem ISA 2006 ist es nun aber möglich, dass die Clients sich mit einem Zertifikat am ISA-Server authentifizieren und der ISA-Server dann mit dem Zertifikat sich ein Kerberos Ticket für den Zugriff auf den nachfolgenden Exchange Server beschafft. Und genau das wird auf dieser Seite beschrieben.

Achtung
Wenn Sie einen ISA 2006 als Web Publisher einsetzen, dann MUSS der ISA-Listener die Clientzertifikate anfordern und per Constraint Delegation und Kerberos an den Exchange Server gehen, da die 403.7-Fehlermeldung des Exchange nicht vom Mobilegerät gesehen wird.
Alternativ wäre nur der "Tunnelmode" oder eine Serververöffentlichung möglich, die dann aber die Authentifizierung auf den Exchange Server durchreichen würde. Angriffe würden dann nicht vom ISA abgewehrt.

Funktionsschaltbild

Wenn Sie den ISA-Server als Endpunkt für den ActiveSync Client konfigurieren, dann sieht die Umgebung etwa wie folgt aus:

Der Client greift auf den ISA-Server zu und meldet sich dort mittels Zertifikat an. Der ISA hat durch eine passende Konfiguration die Erlaubnis, sich für den Zugriff au den Exchange Frontend-Server ein Kerberos Ticket im Auftrag des Benutzers (Siehe auch Kerberos Constraint Delegation) zu beschaffen, um auf den Frontendserver, oder bei einer EinzelUmgebung auf den Postfachserver, zuzugreifen.

Wenn ein Frontend zum Einsatz kommt, dann muss dieser auch per Kerberos sich ein Ticket für den Backend Server beschaffen um dort auf das Verzeichnis /Exchange" zugreifen zu können. für beide Webserver muss natürlich die "Integrierte Authentifizierung" hierfür zusätzlich aktiviert werden.

Optionen ohne ISA

Wird kein ISA 2006 Server eingesetzt, dann muss die Firewall die Verbindungen direkt auf den Frontendserver oder den Mailboxserver (wenn nur ein Server vorhanden ist) durchreichen. Damit der Frontend Server natürlich das Kerberos Ticket gegen den Mailboxserver einsetzen kann, muss diesem Server "vertraut" werden. Entsprechend sollten folgende Wege auch gehen:

  • PDA(Zert) - Internet -> ISA2006(Domain/Auth) -> Frontend (Domain)  -> Backend (Domain)
  • PDA(Zert) - Internet -> Router(NAT) -> Frontend (Domain/Auth)  -> Backend (Domain)
  • PDA(Zert) - Internet -> ISA2006/2004(reverseProxy) -> Frontend (Domain/Auth)  -> Backend (Domain)
  • PDA(Zert) - Internet -> Apache(reverseProxy) -> Frontend (Domain/Auth)  -> Backend (Domain)

Wenn man nur einen Exchange Server hat, kann man auf den Frontend verzichten. Allerdings sollte man dann bedenken, dass die Authentifizierung ohne I    SA2006 erste der Backend Server macht.

  • PDA(Zert) - Internet -> ISA2006(Domain/Auth) -> Backend (Domain/Auth)
  • PDA(Zert) - Internet -> Router(NAT) -> Backend (Domain/Auth)
  • PDA(Zert) - Internet -> ISA2006/2004(reverseProxy) -> Backend (Domain/Auth)
  • PDA(Zert) - Internet -> Apache(reverseProxy) -> Backend (Domain/Auth)

Nicht gehen dürfte dabei:

  • PDA(Zert) - Internet -> ISA(Standalone/Auth) -> Frontend (Domain)  -> Backend (Domain)

Die Einführung einer "zertifikatbasierten Anmeldung" deaktiviert die Anmeldung ohne Zertifikate !. Wenn beide Wege erlaubt sein sollen, dann benötigen Sie zwei virtuelle Webserver bzw. Frontendserver mit unterschiedlicher Konfiguration und unterschiedlichen DNS-Namen.

Das Client Zertifikat muss von dem ersten HTTP-Service ausgewertet werden. Es ist nicht möglich, über einen Reverse Proxy oder eine ISA Webveröffentlichung ohne Authentifizierung den Zugriff per Zertifikat zu erlauben. Nur Systeme, die die Pakete unverändert durchreichen (ISA Tunnel/Serververöffentlichung oder NAT/ReverseNAT von Routern) sind erlaubt.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.

Einrichtung

Die Einrichtung selbst erfolgt in mehreren Schritten. Die Beschreibung umfasst NUR die Konfiguration auf dem ISA Server und Exchange. Lesen Sie auch die prinzipiellen Funktionsseiten EASCert Provisioning und anderes.

  • Exchange Backend einstellen
Einstellung Beschreibung Erledigt

Windows 2003 Domain im Native Mode

Dies ist erforderlich für die Funktion von Kerberos Constraint Delegation

 

ISA-Computer in die Domain aufnehmen

Der ISA-Server muss Mitglied der Domäne im gleichen Forest wie Exchange sein, um Kerberos Tickets erhalten zu können.

 

Exchange 2003 SP2 oder höher

ältere Exchange Versionen unterstützen nicht die Authentifizierung mit Zertifikaten

 

Kerberos Delegation für ISA einrichten

Über die MMC für Benutzer und Computer suchen Sie das Computerkonto des ISA-Servers und addieren die Exchange Server, auf die der ISA zugreift (Meist sind das ein oder mehrere Frontends oder der einzige Backend) und erlauben "JEDES" Authentifizierungsprotokoll für die Dienste HTTP und W3SVC.

Wenn Sie mehrere ISA-Server nutzen, müssen Sie diesen Schritt für alle Server wiederholen

 

Kerberos Delegation für ISA einrichten

Die gleichen Schritte sind für alle Frontend Server zu wiederholen, damit diese auf die Backend-Server kommen. Bearbeiten Sie auch hier wieder über die MMC für Benutzer und Computer die Computerkonten der Frontend Server und addieren sie nun alle Exchange Backend Server, auf die die Frontends zugreifen und erlauben "JEDES" Authentifizierungsprotokoll für die Dienste HTTP und W3SVC

Wenn Sie mehrere Frontend-Server nutzen, müssen Sie diesen Schritt für alle Server wiederholen

 

Authentifizierung auf Exchange URL "Microsoft-Server-ActiveSync"

Damit der ISA-Server später mit seinem frisch erlangten Kerberos-Ticket sich auch auf dem Exchange Server anmelden kann, muss dort die "integrierte Authentifizierung" aktiviert werden

Aktivieren Sie hier NICHT die Zertifikatbasierte Anmeldung auf den SSL-Einstellungen

Sie können aber natürlich schon die Verbindung vom ISA zum Frontend per SSL verschlüsseln, damit die Nutzdaten nicht abgehört werden. Kennworte werden Sie so aber nicht erhalten, da nur Kerberos-Tickets übertragen werden.

Auf als Backend konfigurierten Exchange Servern ist die NTLM-Authentifizierung sowieso schon aktiv. Ein Kontrollblick kann aber nicht schaden.

 

ISA Weblistener einrichten

Zuerst ein ein WebListener zu konfigurieren, welcher auf der von externen erreichbaren IP-Adresse auf Anfragen wartet. Einzustellen ist:

  • IP-Adresse
    Wählen Sie die IP-Adresse für den Listener aus. Der DNS-Name, der auf den Mobilgeräten eingetragen wird, muss per DNS auf diese Adresse verweisen bzw. auf eine Adresse, die dann auf diese per Reverse-NAT weiter geleitet wird. (Ich weisß, dass viele Firmen den ISA gerne noch einmal hinter einer "richtigen" Firewall verbergen.
  • Zertifikat
    Binden Sie das bereits installierte Zertifikat für diesen Webdienst mit ein. Der Name muss natürlich dem DNS-Namen entsprechen, der später von den Clients angesprochen wird.
  • Authentifizierung
    Geben Sie auf der Karteikarte "SSL Client Certificate Authentication" an.

Sonst ist nichts auf dem Listener zu konfigurieren.

 

ISA Webveröffentlichung einrichten

Zuletzt wird nun die Firewall-Regel eingerichtet, mit der "Exchange ActiveSync" veröffentlicht wird. Nutzen Sie dazu einfach den Assistenten zur Veröffentlichung einer Exchange Webseite und wählen Sie als Dienst nur ActiveSync aus.

Auf der Seite "Authentifizierung" müssen Sie dann "Kerberos Constraint Delegation" aktivieren. Der Kerberosname ist der Name der internen Size und wird automatisch gefüllt.

Prüfen Sie, dass sie diesen Namen auch vorher bei der Einrichtung der beim ISA-Computerkonto verwendet haben.

 

Danach ist die Installation soweit schon abgeschlossen. Über die ISA-Protokollierung sollten Sie nun jeden Zugriff der Clients sehen können und dort wird auch der Windows NT-Anmeldename (Domain/Benutzername) aufgelistet. Erst dann können Sie sicher sein, dass der ISA-Server das Clientzertifikat erkannt und umgesetzt hat.

Hier fehlt noch ein Bild des ISA-Logs beim Zugriff durch einen Client

Ob er jedoch ein Kerberos-Ticket für den Anwender bekommen hat (also Kerberos Contraint Delegation funktioniert) können Sie hier leider nicht sehen.

Doppelter Zugang

Dadurch, dass die Exchange Frontend Server bzw. der einzige Exchange Server selbst keine zertifikatbasierte Anmeldung durchführt, ist es durchaus denkbar, beide Zugangsvarianten in Verbindung mit dem ISA-Server einzurichten und damit eine langsame Migration oder sogar einen parallelen Zugang zu konfigurieren. Über die ISA-Regeln (dort haben sich die Anwender zu authentifizieren) können Sie sogar über Windows Sicherheitsgruppen steuern, wer welchen Zugang nutzen kann.

Richtigen Sie dazu einfach einen zweiten ISA-Listener mit einer eigenen IP-Adresse, DNS-Name und Zertifikat ein und reichen diese Anmeldung über die normale Konfiguration an den Exchange Server weiter.

Weitere Links