Multiple Exchange Vero ffentlichungen mit einer Zugangs-URL Thema: Das Jahr 2010 hat es für Microsoft-Affine in sich! Es gibt Versionssprünge in allen Software- Produkten, die nicht bei 3 auf den Bäumen waren. Ein alter Klassiker in neuem Gewand ist der Exchange-Server. Wie beim letzten Versionswechsel steht für viele Unternehmen ein Umzug ins Haus. Zumindest in dieser Übergangsphase wird die alte sowie neue Exchange-Struktur parallel betrieben. Die Benutzer der betroffenen Netzwerke sollen von diesem Wechsel natürlich nur die Vor- und nicht die Nachteile zu spüren bekommen. Der Umzug der Mailboxen soll so transparent wie möglich erfolgen. Aufgabe: Damit der webbasierte Postfach-Zugriff für die betroffenen Benutzer so einfach wie möglich bleibt wäre es wünschenswert, wenn sich die Zugangswege nicht ändern würden. Im konkreten Fall von Outlook Web Access aka Outlook Web App aka OWA würde dies bedeuten: Der externe Benutzer greift auf die ihm bekannte alte OWA-URL zu und bekommt den Inhalt seines Postfachs angezeigt, egal auf welcher internen Infrastruktur sein Postfach liegen mag.
Umsetzung: Die oben genannte Aufgabe lässt sich mit einem TMG 2010 umsetzen. Der Clou hierbei ist die benutzerbezogene Weiterleitung. Es folgen Screenshots aus einem Testszenario welches nicht die oben erwähnten URLs verwendet. Im Einsatz sind drei interne Exchange-Versionen und zwar 2003, 2007 und 2010. Vorarbeiten: Nicht nur für dieses Szenario ist eine gute Vorbereitung Pflicht. Arbeiten, die im Vorfeld getätigt wurden: - Eine domänenintegrierte CA ist im Einsatz - Alle Exchanger haben passende Webserverzertifikate für die benötigten internen FQDNs gebunden. Für die internen Zugriffe sind ebenfalls HTTPS-Verbindungen empfehlenswert. - TMG hat ein Webserverzertifikat für den öffentlichen FQDN im Zertifikatsspeicher. - Alle OWA-Zugriffe werden intern im Vorfeld getestet. Auf allen Exchange-Versionen müssen für diese Test-Zugriffe Test-Postfächer zur Verfügung stehen. - Für die internen OWA-Zugriffe wird die formularbasierte Authentifizierung (FBA) auf den Exchangern abgeschaltet. Alternativ wird dann die Standard- und integrierte Windows- Authentifizierung angeboten. - Ist für interne OWA-Zugriffe ebenfalls eine FBA gefordert, dann zeigt Herr Grote hier wie sich dies mit einem virtuellen IIS-Verzeichnis realisieren lässt: http://www.it-training-grote.de/blog/?p=3693 - Ein gutes Grundverständnis über Webveröffentlichungen setze ich voraus und zeige nur die benötigten Konfigurationsschritte auf. Der Weblistener: Nachdem die Vorarbeiten erfolgreich abgeschlossen sind wird zuerst ein Weblistener erstellt. Der Weblistener stellt den Clients gegenüber die Schnittstelle dar, die vom Internet aus erreichbar ist. Hier wird z.b. die Pre-Authentifizierung des Benutzers abgefragt. In diesem Testszenario wird für den Exchange-Zugriff ein Single-NIC-Szenario des TMG eingesetzt. In der Praxis bin ich allerdings eher von der Dual-NIC-Lösung überzeugt. In der Toolbox lege ich einen neuen Weblistener an. Wer hier gerne den neuen FBA-Look einsetzen möchte erstellt am einfachsten den Weblistener im Rahmen des Exchange-Webpublishing-Assistenten.
Willkommen:
Intern wird SSL eingesetzt:
Da hier ein Single-NIC-TMG im Einsatz ist wird der Listener auf dem Netzwerk Internal aufgespannt:
Auswahl des vorher (!) im Zertifikatsspeicher des lokalen Computers abgelegten Webserverzertifikats:
Hier wird das Zertifikat auf eine IP des Listeners gesetzt. Dieser Konfigurationsschritt ist nur zwingend erforderlich wenn mehrere Sockets auf dem Listener verwendet werden sollen:
Die Authentifizierungsmethode auswählen:
SSO wird auf dem Listener nicht verwendet:
Der uralte Exchange 2003: Re:
Auswahl von Version und Funktion:
Das Veröffentlichen einer Webserverfarm wäre natürlich auch denkbar, so vorhanden:
Intern wird auch SSL verwendet:
Angabe des internen Exchange 2003 FQDN:
Öffentlicher FQDN:
Den bereits vorhandenen Weblistener auf die Regel binden:
Als Authentifizierungsdelegierung wird die Standardauthentifizierung verwendet:
Erstellen eines neuen Benutzersatzes: Im AD wurden vorher drei globale Gruppen für die jeweiligen Exchange-Versionen angelegt. Beim Verschieben der Mailbox muss das Benutzeraccount nur in die jeweilige Gruppe verschoben werden:
Hier wird der Benutzersatz auf die Regel gebunden:
Die erste Regel ist fertig. Ein beherzter Klick auf den Test-Button zeigt hoffentlich grünes Licht!
Der alte Exchange 2007: Die Vorgehensweise beim Exchange 2007 ist nahezu identisch. Der Unterschied ist der Einsatz eines anderen Benutzersatzes sowie ein anderes internes Ziel.
Hier wird der interne FQDN des Exchange 2007 (CAS) eingetragen:
Alle Veröffentlichungsregeln teilen sich denselben Listener:
Hier wird die speziell für den Exchange 2007 angelegte globale Gruppe aus dem AD verwendet:
Die zweite Regel ist nun fertig:
Der funkelnagelneue Exchange 2010: Ein weiteres Mal wird der Exchange-Webclientzugriffs-Assistent angeworfen. Die Einstellungen bleiben wieder nahezu gleich bis auf Ziel und Benutzersatz:
Angabe des internen Exchange 2010 (CAS) FQDN:
Die dritte Regel und immer noch derselbe Listener:
Hier die Referenz auf die globale Gruppe die für den Zugriff auf den Exchange 2010 verwendet werden soll:
Das finale Regelwerk: Drei Regeln lösen die Aufgabe, der Trick ist es das Regelwerk auf Benutzergruppen aufzubauen. Die Abwärtskompabilität der jeweiligen Exchanger erlaubt den Zugriff über einen Subfolder, nämlich /exchange. Fazit: Auf Benutzerkonten basierendes Regelwerk ist die Kernaussage eines Proxy-Servers. Diese Funktion lässt sich in Reverse-Proxy-Konfigurationen ebenfalls sehr gut einsetzen. Das Webpublishing mit nur einem Einstiegspunkt (sprich URL) spart nicht nur weitere Sockets und Zertifikate, sondern bietet den betroffenen Benutzern einen gewohnten Zugang zu den internen Strukturen.