CASProxy mit Exchange 2007

Diese Seite beschreibt NUR die CAs-Funktion von Exchange 2010 ! Die CAS-Proxy Funktion von Exchange 2010 ist auf CASProxy 2010 beschrieben. Exchange 2000/2003 Frontend/Backend finden Sie auf Frontend/Backend. Denken Sie auch an die Absicherung des CAS-Servers. (Siehe auch OWA Absichern)

Mit Exchange 2007 wurde erstmals die Rolle des "Client Access Servers" eingeführt, welche bei Exchange 2000/2003 zwar schon in der Form des "Frondend-Servers" teilweise sichtbar war, aber der Exchange 2007 CAS hat diese Funktion noch stark verbessert aber auch etwas komplizierter gemacht. Auf dieser Seite geht es nun um die Kommunikation der CAS-Server mit den Mailboxserver, aber auch mit anderen CAS-Servern und Exchange 2003 Systemen und die Frage, wann die Anfrage eines Clients vom CAS selbst verarbeitet, weitergegeben oder der Client gar umgeleitet wird.

Die Rolle des CAS

Bei Exchange 2000/2003 waren die Funktionen klar getrennt. Die Aufgabe des Frontend Servers war die intelligente Umleitung von POP3, IMAP4 und HTTP-Anfragen auf den entsprechenden Mailbox Server. So konnte man nach außen einfach nur den Namen des jeweiligen Frontend Server (oder der Farm) veröffentlichen, über die alle Zugriffe (außer Outlook mit MAPI/RPC) erfolgt sind. Die Protokolle RPC/HTTP und ActiveSync sind hier nicht von Belang, da sie bei Exchange 2003 durch die DLLs so gelöst wurden, dass es faktisch immer ein kleiner "Frontend" war, d.h. auch ein Backend Server konnte diese Anfragen an den anderen Backend Server weitergeben.

Exchange 2007 hat diese Rolle aber nun deutlich aufgewertet, weil die Mailboxserver keine POP3, IMAP4 oder HTTP (OWA)-Funktion mehr bereit stellen, sondern der CAS-Server diese Anfragen annimmt und seinerseits vom passenden Mailbox Server per MAPI die Daten anfordert.

CAS Proxy und "Integrierte Authentifizierung"

Eigentlich ist die formularbasierte Anmeldung ("Form-Based") eine schöne Sache: Als Administrator kann man die Anmeldemaske gestalten und aus Sicherheitsaspekten kann man sich auch wirklich abmelden. Unschön ist aber nur, dass man beim Zugriff aus dem Internen Netzwerk gerne die integrierte Anmeldung verwenden würde, um eben ein "Single SignOn"-Gefühl zu haben. Der Anwender startet seinen Webbrowser und kann sofort loslegen. Auch wenn man OWA als Webpart/IFrame in Sharepoint und andere Webseiten integrieren will, ist die integrierte Anmeldung einfacher zu verwenden.

Im Hinblick auf den CAS-Proxy ist dabei jedoch einiges zu beachten. Natürlich ist es sehr einfach auf den virtuellen Verzeichnissen "/Exchange", "/owa", "/ExchWeb" und "/Public" die Anmeldung einfach auf "Windows integriert mit NTLM" umzustellen, aber schneller als Sie sich das vorstellen, laufen Sie wieder in das "Double Hop" Problem. Wenn sich ein Anwender am IIS per NTLM anmeldet, so hat der IIS nur die Hashwerte aber keine ausreichenden Daten, um sich an weiteren Servern (z.B. den Exchange 2003 Backend Servern) anzumelden.

Insofern funktioniert das nur richtig, wenn man sich dann doch wieder entweder mit "Basic Authentication" oder per Formularanmeldung (bitte beide mit SSL verschlüssel) oder per Kerberos anmeldet. Gerade Kerberos ist aber für viele Administratoren ein unbekanntes Terrain und entsprechend kryptisch. Aber erst in Verbindung mit der "Constraint Delegation" kann man dafür sorgen, dass der Exchange 2007 CAS-Server sich ein Kerberos Ticket im Auftrag des Benutzers für die Backend Dienste besorgt und damit eine nahtlose Verbindung erreichen. Dennoch gibt es dann noch einige "Probleme, speziell beim Zugriff auf anderen Postfächer per direkter Eingabe der URL

Benutzer Zugriff auf Integriert Formbased

E2K7 user

/owa (eigenes Postfach)

Eigenes E2K7 Postfach

Eigenes E2K7 Postfach

E2K7 user

/owa/2k7fremd

Fremdes E2K7 Postfach

Fremdes E2K7 Postfach

E2K7 user

/exchange (eigenes Postfach)

Anmeldung erforderlich

Eigenes E2K7 Postfach

E2K7 user

/exchange/e2k3fremd

Anmeldung erforderlich

Fremdes E2K3 Postfach

E2K3 user

/owa (eigenes Postfach)

Fehlermeldung

Fehlermeldung

E2K3 user

/owa/2k7fremd

Fremdes Postfach

Fremdes Postfach

E2K3 user

/exchange (eigenes Postfach)

Eigenes E2K3 Postfach

Eigenes E2K3 Postfach

E2K3 user

/exchange/e2k3fremd

Fremdes E2K3 Postfach

Fremdes E2K3 Postfach

E2010 user

/owa

Kein Zugriff über CAS, Redirect auf Exchange 2010 CAS

Während bei der formularbasierten Anmeldung nur der Fall fehlschlägt, dass ein Exchange 2003 Benutzer über den Exchange 2007 CAS über "/owa" arbeiten will, gibt es bei der integrierten Anmeldung sogar drei Fälle, in denen es keinen Zugang gibt. Zusammen mit einem Kunden ist daher die ASP-Seite "OWARedirect" entstanden, auf die sich die Mitarbeiter verbinden. Dieser Code erkennt dann den Benutzer, fragt im Active Directory nach dem dazu gehörigen Homeserver und leitet den Benutzer dann auf den definierten CAS-Server oder Frontend Server samt URL um.

Was ist mit Exchange 2003 ?

Ein Exchange 2007 CAS kann natürlich auch einen Exchange 2003 Server bedienen. Das ist für die Migration natürlich auch erforderlich, weil man auch hier zuerst die Exchange 200x Frontend Server durch CAS-Server ablöst und erst danach langsam die Postfächer auf die neuen Server migrieren kann. Ein Exchange 2003 Frontend Server kann nämlich nicht auf einen Exchange 2007 Server zugreifen.

CAS - Exchange 2003 Backend

Der Exchange 2007 CAS erkennt, ob das Postfach auf einem Exchange 2003 oder 2007 Server liegt. Postfächer auf Exchange 2003 werden einfach als Reverse Proxy an den OWA, POP3, IMAP4-Server des Postfachservers weiter gegeben. Die Benutzer, die also über einen Exchange 2007 CAS auf Exchange 2003 Postfächer zugreifen, sehen von Exchange 2007 nur die neue Anmeldemaske. Danach sehen Sie einen echten Exchange 2003 OWA-Zugang, da der Backend Server die Daten generiert.

Voraussetzung dabei ist, aber dass der Backend Server NTLM-Authentifizierung erlaubt und SSL nicht erzwingt. Das ist immer der Fall, wenn man bisher schon Exchange 2003 Frontend Server einsetzt. Nur wenn man bisher einen Exchange 2003 Mailboxserver mit formularbasierter Anmeldung nutzt, dann kann der Exchange 2007 CAS diesen Server nicht als Backend ansprechen.

Diesen "Fehler" in der Konfiguration findet man auch wunderbar im IIS-Log des CAS-Servers (Hier am Beispiel von ActiveSync)

IISLog:
2007-12-18 14:07:09 W3SVC803421 10.1.1.1 OPTIONS /Microsoft-Server-ActiveSync/default.eas user=testuser&DeviceId=xxx&DeviceType=PocketPC&
Log=PrxTo:backend.msxfaq.de_Error:NTLM+not+on+the+destination+CAS_ 80 msxfaq\testuser 10.0.1.227 Microsoft-PocketPC/3.0 401 5 0

Im gemischten Betrieb kann auch die Eingabe der OWA-URL etwas tückisch sein, da es genau einen Fall gibt, bei dem der Anwender mit einer unschönen Fehlermeldung konfrontiert wird.

Postfachserver URL Ergebnis

Exchange 2007

https://owa.firma.tld/exchange

OK - Der Anwender kann arbeiten, auch wenn er irrtümlich die alte URL eingibt.

Exchange 2007

https://owa.firma.tld/owa

OK - Der Anwender kann arbeiten, auch wenn er irrtümlich die alte URL eingibt.

Exchange 2003

https://owa.firma.tld/exchange

OK - Der Anwender sieht zwar zuerst den Exchange 2007 Anmeldeschirm aber bekommt dann "nur" den Exchange 2003/2000 OWA zu sehen

Exchange 2003

https://owa.firma.tld/owa

FEHLER - Der Anwender bekommt leider eine Fehlermeldung, dass sein Postfach nicht auf einem Exchange 2007 Server liegt

Insofern kann man eigentlich auch weiterhin die URL mit "/exchange" verwenden und die Anwender müssen nicht umdenken. Allerdings wird der Pfad "/Exchange" in Zukunft verschwinden und daher sollten sich die Benutzer nach dem Wechsel auf Exchange 2007 und höher besser "/owa" merken.

CAS Proxy und Mailbox Rolle

Es gibt eine wichtige Abhängigkeit zwischen einem Server der neben der CAS-Rolle auch die Mailboxrolle hat. Die Installation der Mailboxrolle richtet auf einem Exchange 2007 Server auch das virtuelle Verzeichnis "/exchange" für den Zugriff per WebDAV ein. Der unschöne Nebeneffekt dabei ist, dass damit der CAS-Server nicht als Reverse Proxy für Exchange 2003 agieren kann.

Weitere Links