Client Zugriff (CAS)

Diese Rolle ist das Bindeglied zwischen den Clients und der entsprechenden Datenbank. Es ist nicht mehr gewünscht, dass die Anwender sich direkt mit der Datenbank verbinden, sondern nur noch eine Verbindung zur "Client Access"-Rolle aufbauen, welche dann den "richtigen" Datenbankserver findet. Dazu gibt es einiges zu erfahren, wie auf den folgenden unterseiten beschrieben ist:

  • CAS Intern/Extern
    Was hat es mit der "internen URL" und "externen URL" auf sich, die konfiguriert werden können
  • CAS URLs
    Wo, außer in den paar per GUI erreichbaren Masken können noch entsprechende URLs konfiguriert werden
  • CASProxy 2007
    Proxy-Funktion der Exchange 2007 CAS-Rolle
  • CASProxy 2010
    Proxy-Funktion der Exchange 2010 CAS-Rolle
  • CAS und NLB
    Mehrere CAS-Server als Team mit NLB verfügbar machen
  • MOMT
    MAPI on the Middle Tier: Die Exchange 2010 CAS-Rolle übernimmt auch den Outlook RPC Traffic
  • OWA Absichern (Bereich Exchange Clients)
    Hinweise zur Platzierung von CAS und Firewall-Filtern.

Die CAS-Rolle übernimmt auch die Konvertierung und Codierung von Inhalten und die Verschlüsselung per SSL als auch die Authentifizierung. So kann die Last verteilt und Exchange besser skaliert werden. Zudem können mögliche Angreifer nicht mehr direkt die Datenbank selbst beeinflussen. Mehrere Server mit dieser Rolle verteilen die Last und erlauben auch eine höhere Verfügbarkeit.

Die Rolle bedient folgende Zugriffe:

  • Outlook Webzugriff (HTTP)
    Der klassische Zugriff per Webbrowser auf ihre Postfach. Die Client-Rolle agiert ähnlich einem Frontend Server in einer Exchange 2000/2003 Umgebung und ist der Endpunkt für die Kommunikation ihres Browsers. Diese Rolle übernimmt damit auch die SSL-Verschlüsselung und Authentifizierung.
  • Outlook Mobile Access (HTTP)
    Das gleiche gilt für den Zugriff per WAP auf ihr Postfach
  • Microsoft Server ActiveSync
    Auch die Replikation
  • Dateisystemzugriffe und Sharepoint
    Angeblich soll OWA auch den Zugriff auf interne Dateiserver und andere Ressourcen erlauben. Dies ist natürlich erforderlich, wenn auf den Einsatz von öffentlichen Ordnern verzichtet werden soll. Auf der anderen Seite stellt sich natürlich die Frage der Sicherheit

Ab Exchange 2007 Service Pack 1 funktioniert:

  • OWA auf Public Folder
    Angeblich soll es nicht mehr möglich sein, auf öffentlichen Ordner per OWA oder IMAP4 zuzugreifen. Das ist dann der erste Schubs in Richtung Friedhof

Ab Exchange 2010

  • MAPI over RPC (Kommt mit Exchange 2010 MOMT)
    Outlook Clients, die direkt per RPC mit dem Speicher sprechen, werden aber wohl auch zukünftig nicht die Client-Rolle nutzen, sondern direkt den entsprechenden Mailboxserver ansprechen. Um hier eine Trennung zu erhalten, ist demnach ein Update auf Outlook 2003 (RPC over HTTP) oder Outlook 2007 erforderlich.

Client Access und Exchange Update auf 2007/2010

Wenn Sie ihre bestehende Exchange 2000/2003 Organisation auf Exchange 2007 Updaten, dann kann der Client Access Server quasi auch als "Frontend" für die Exchange 2003 Server dienen. Meist werden Sie dies nach einiger Zeit auch so konfigurieren. Wenn Sie bisher aber noch keine "Frontend/Backend"-Struktur betrieben haben, dann wird ihr bisheriger "OWA-Server" natürlich per SSL geschützt sein.

Nun kommt das Problem, dass die Verbindung zwischen "Frontend" und Backend kein SSL unterstützt. (Sie können aber IPSEC zur Verschlüsselung nutzen). Aber vermutlich hab en Sie SSL auf dem Exchange 2003 erzwungen. Dies müssen Sie wieder rückgängig machen. Allerdings ist dann der direkte Zugang zum Exchange 2003 auch ohne SSL möglich. Abhilfe ?

  • Port 80 blockieren
    Verhindern Sie z B auf der Firewall, dass aus dem "unsicheren" Internet der Exchange 2003 OWA ohne SSL erreichbar ist
  • IP-Restrictions
    Auch auf dem virtuellen HTTP-Server können Sie einstellen, welche IP-Adressen den Exchange OWA-Server ansprechen dürfen.
  • ISA2004/2006
    Stellen Sie einen ISA-Server "davor", der die Anfragen von außen per SSL erzwingt und dann nach intern weiter gibt,
  • zweiter virtueller HTTP-Server
    Wenn der "default HTTP-Server" nicht mehr SSL erzwingen darf, damit die Exchange 2003 Frontends bzw. Exchange 2007 CAS auf den Server zugreifen können, dann können Sie einen zweiten virtuellen HTTP-Server mit SSL-Zwang konfigurieren und den Zugriff darauf aus dem Internet zulassen.

Leider kann ein Exchange 2010 CAS nicht als Reverse Proxy für Exchange 2003 oder 2007 dienen. Hier sind weitere Schritte zu tun. Sie sehen also dass speziell in größeren Umgebungen natürlich ein Blick in das Bereitstellungshandbuch oder die Einbindung externer Unterstützung nicht schaden kann.

Weitere Links