CAS - Interne und externe URLs

Diese Seite beschreibt die Bedeutung der Einstellungen zu InternalURL und ExternalURL

Achtung:
Die "internalURL" wird in Umgebungen mit mehreren CAS-Servern als Adresse für die "CAS zu CAS" Verbindung genutzt. Die Anfragen dürfen nicht über einen Proxy laufen. Wer also per GPO auch den Computern sagt, dass alles zum Proxy geht, stört die CAS zu CAS Kommunikation.

Wer eine Exchange 2007/2010 CAS-Rolle installiert hat, wird spätestens beim Einrichten oder Anpassen von OWA über eine Option stolpern, welche erklärungsbedürftig ist.

CASProxy Internal/External URL 

So könne Sie beim virtuellen Verzeichnis "/OWA" eine "internal URL" und eine "external URL" pflegen. Normalerweise steht in der "Internal URL" einfach der vollqualifizierte Name des aktuellen Servers und die "external URL" ist leer. Diese beiden Felder gibt es aber nicht nur bei OWA, sondern sehr oft (Siehe auch CASURLs) und nicht alle Einstellungen sind über die GUI erreichbar. Alles auf dieser Seite dreht sich letztlich um die Frage, was sie in den Feldern "Internal URL" und "External URL" steht.

Bedeutung der URLs

Die Konfiguration dieser URL ist kein reiner Selbstzweck der Exchange Server sondern eine fehlerhafte Konfiguration wird z.B. die Funktion von Outlook 2007 und höher empfindlich stören. Viele der neuen Funktionen werden nicht per per RPC genutzt, sondern über HTTPS-Verbindung vom Client zum Server aber auch zwischen den Servern. Exchange nutzt dazu verschiedene URLs (z.B. /EWS, /UM, /OAB, /ECP etc.) und damit diese Zugriffspunkte nicht statisch konfiguriert werden müssen, gibt es eine Einstiegshilfe, die über den Mechanismus Autodiscover erreicht wird. Clients als auch Server "suchen" also je nach Standorte über die Funktion Autodiscover nach den verschiedenen Zugriffspunkten.

Es obliegt damit dem Administrator in der Exchange Konfiguration die "richtigen" Zugangspunkte zu hinterlegen, damit die Autodiscover-Funktion diese auslesen und an die Clients übermitteln kann. Die Werte in "Internal URL" und "External URL" sind genau die Daten, die hierzu heran gezogen werden. Stark verkürzt können Sie sich merken.

  • Die Exchange Server selbst nutzen immer den FQDN für den die Server zu Server Kommunikation
    Unabhängig davon, was Sie in den URLs hinterlegen sprechen sich die Exchange Server immer mit ihrem FQDN an. Daher muss dieser Name auch immer im Zertifikat enthalten sein. Das kann ein Problem sein, wenn Sie eine "nicht öffentliche DNS-Domäne" verwenden, für die sie kein Zertifikat bekommen. Dann "müssen" sie davor einen Reverse Proxy mit öffentlichem Zertifikat stellen.
  • Die Exchange Server werden aber die „External URL“ aus um zu wissen, ob in dem jeweiligen Standort des Postfachs ein Server „extern“ erreichbar ist.
    Wenn keine External URL gesetzt ist, arbeitet der aktuell angesprochene Server als „Reverse-Proxy“ zum Postfachserver. Ansonsten sendet er einen Redirect zur anderen „External URL“ an den Client
  • Die Internal/External URLs sind primär für AutoDiscover relevant
    Eine Autodiscover-Anfrage eines Clients löst der angesprochene Exchange Server derart auf, dass er erst den Postfachserver sucht und dann einen Frontend/CAS-Service in der gleichen AD-Site. Von denen liest er dann die URL-Werte aus. Wenn es keinen Exchange Frontend mit einer External-URL gibt, dann sucht er den "nächsten" Exchange in einer anderen AD-Site, der dann als Reverse-Proxy agiert.
  • interne und externe URL gleich
    Dann muss per SplitDNS dafür gesorgt werden, dass interne Zugriffe auch intern bleiben und externe extern landen.
  • interne und externe URL unterschiedlich
    Unterschiedliche Namen erlauben u.a. die Nutzung privater Namensräume intern (mit eigenen Zertifikaten) aber birgt das Risiko, dass auch interne Clients mit unterbrochener Verbindung zum Service dann versuchten die andere External URL anzusprechen, was zu Kennwort-Nachfragen führen kann.
  • InternalURL
    Dieser Eintrag benennt die Adresse, über der diese Funktion intern (ohne Proxy oder Firewall) zu erreichen ist. Outlook 2007 oder neuer wird beim Kontakt mit einem DC per Autodisover dann versuchen, diese Adressen zu erreichen. Exchange Server, die zu einem anderen Server in der gleichen Organisation Kontakt aufnehmen müssen (z.B. für die Ermittlung von Frei/Belegt-Zeiten) werden diese Adresse nutzen, um den Server zu erreichen
  • ExternalURL
    Diese Adresse zeigt an, unter welchem Namen der Dienst aus dem Internet erreichbar ist. Der Name muss dazu gar nicht auf dem Server selbst bekannt sein. Wenn z.B. ein ISA-Server davor steht, dann reicht es wenn aus dem Internet die Anfragen eben auf dem ISA mit dem passenden Zertifikat beantwortet und dann an den CAS-Server weiter gereicht werden. Über diesen Wert ermitteln auch die Exchange Server, welcher Server aus dem Internet erreichbar ist und welcher Server nicht erreichbar ist. Damit werden Anfragen von Clients dann von aus dem Internet erreichbaren Servern an die nicht veröffentlichten Server weiter gegeben. (siehe auch CASProxy 2007 und  CAS Proxy 2010)

Dabei sollten Sie immer bedenken, dass eine Verbindung per HTTP idealerweise per SSL abgesichert wird (also HTTPS) und dass dazu natürlich Zertifikate erforderlich werden

Single Site

Der einfachste und zugleich häufigste Fall ist die Konzentration aller Exchange Server an einem Active Directory Standort. Hier sind CAS-Server und Mailbox Server beisammen und der CAS-Server bedient natürlich seine Mailbox Server.

CAS Proxy Single Site 

Da viele Firmen auch die Optionen von Exchange 2007 zur Konsolidierung nutzen, werden sich hier sicher die meisten Leser wohl fühlen und brauchen gar nicht mehr weiter zu lesen. Hier kann als zusätzliche Komplexität nur noch Exchange 2003 mit ins Boot kommen, was aber etwas später beschrieben wird.

Zweite Site ohne Internet

Wenn Sie aber mindestens einen weitere Standort mit Exchange haben, der intern per VPN oder Standleitung angebunden ist und selbst über keine Verbindung zum Internet verfügt, dann wird die Situation schon interessanter. Das Exchange 2007 Setup weist Sie bei der Installation schon darauf hin, dass zu einem Mailbox Server in einem Active Directory Standort auch immer ein CAS und Hub-Server gehört. Daher ist schon ausgeschlossen, dass der CAS-Server im Hauptstandort direkt den Mailbox Server in der Niederlassung erreichen wird.

CAS Proxy remote Site

In diesem Fall arbeitet der CAS nämlich als Proxy und gibt die Anfragen aus dem Internet direkt an den CAS in der Niederlassung weiter. Dieser Server verbindet sich dann per RPC mit dem Mailboxserver der Niederlassung um die Daten zu holen.

Auch wenn in dem Beispiel die "External URL" leer bleiben sollte, und die Exchange Server anhand der AD-Standorte den besten "internet facing"-CAS-Server ermitteln, so kann es sein, dass Sie dies manuell übersteuern wollen. Dann können Sie auch in einer Site ohne Interneterreichbarkeit einfach die externalURL der Site pflegen, die Sie für den Zugriff vorsehen. Der Client bekommt dann bei einer Autodiscover-Anfrage diese URL als Antwort, unabhängig von den AD-Sitelink-Kosten

Zweite Site mit Internet

Nehmen wir nun aber an, dass dieser zweite Standort auch eine Internetverbindung hat. Das kann aus Redundanzgründen sinnvoll sein, aber auch um eine unabhängigkeit zu wahren, wenn die Standorte z.B. in unterschiedlichen Ländern sind und ihre eigenen SMTP-Domains nutzen (also z.B. firma.de und firma.at).

Mit dem Aufbau dieser zweiten Internetverbindung kann man ja nun auch den CAS-Server des zweiten Standorts sicher im Internet veröffentlichen. Würde man nun keine weitere Konfiguration vornehmen, dann würde ein Mitarbeiter, der CAS1 anspricht um sein Postfach auf MB2 zu lesen, durch den CAS1 zum CAS2 gehen. Das wäre ungünstig, da die interne Leitung mit diesen Daten belastet wird. Besser wäre hier, dass der Mitarbeiter selbst sich mit CAS2 verbindet.

Man kann natürlich den Mitarbeitern "ihren OWA"-Server mitteilen, aber wirklich praktikabel ist das nicht. Exchange 2007 hat eine einmalige Funktion, dass es zu Mailboxserver immer den besten CAS-Server ermitteln kann und den Benutzer dann auf diesen CAS-Server umleitet.

CAS Proxy dual Internet

Also anstelle die Anfrage intern zum besten CAS-Server weiterzugeben (Proxy) wird an den Client eine HTTP-Umleitung gesendet, so dass der Clients selbst direkt zum CAS2 geht. Dazu ist es aber erforderlich, dass al die CAS-Server, die aus dem Internet erreichbar sind, auch den passenden Namen als "ExternalURL" gepflegt haben.

Mehrere CAS-Server in der gleichen AD-Site sollten aus Redundanzgründen entweder per NLB mit einem gemeinsamen Namen veröffentlicht werden, oder die davor liegende Firewall (z.B. ISA2006) sollte ein Load Balancing und Fehlerkorrektur erlauben. Die Veröffentlichung von CAS-Servern über DNS-RoundRobin kann ich nicht empfehlen.

CAS-Server in unterschiedlichen Active Directory Standorten, die auch im Internet erreichbar sind, dürfen nicht unter dem gleichen Namen veröffentlicht werden !

CAS und interner Verkehr - Outlook Autodiscover und Internal URL

Die Umleitung der CAS-Zugriffe auf den "naheliegenden" Server ist aber nicht nur für die Verbindung aus dem Internet interessant, sondern hat auch intern entsprechende Vorteile. Denn auch hier wird der Client dann auf diese URL weiter geleitet. Es ist durchaus interessant auch intern mit diesen URLs zu arbeiten, z.B. wenn Sie mehrere CAS-Server unter einem Namen als NLB-Farm betreiben.

Richtiger Einsatz von Internal und External URL

Server, die aus dem Internet unter einem Namen zu erreichen sind, sollten diesen Namen auch in "ExternalURL" konfiguriert haben. Damit ist sichergestellt, dass alle CAS-Server, die aus dem Internet erreichbar sind, in der Exchange Konfiguration korrekt definiert sind und das umleiten von Clients an einen "besseren" CAS-Server funktioniert.

Die InternalURL wird genutzt, wenn ein CAS die Daten an einen anderen CAS weiter geben soll oder wenn der Client den "falschen" CAS nutzt, damit er intern richtig umgeleitet wird. Haben mehrere CAS-Server in verschiedenen Sites eine (zwingend unterschiedliche) ExternalURL, dann kann der CAS den Client, der den "falschen" CAS nutzt, diesen auf die richtige externe URL eines "besseren" CAs umleiten. Diese URL wird beim Setup eigentlich immer richtig gepflegt und sollte nicht manuell geändert werden.

Knifflig, wird es wenn zwei Server sowohl Mailbox als auch CAS sind und beide CAS per NLB veröffentlicht sind. hier kann man den Client nicht zum CAS mit der Mailbox umleiten, sondern beides wird "geproxied". Das gilt auch für interne Zugriffe !. Frontend-CAS Server sollten also keine Mailboxrolle tragen, wenn diese unter einem Namen veröffentlicht werden sollen

Weitere Links