Hallo lieber Leser.
Einige Ungereimtheiten im Zusammenhang mit der Veröffentlichung von Exchange 2007 über ISA 2006 habe mich dazu veranlasst tiefer in das Thema einzusteigen. Daraus hat sich eine Schritt für Schritt Anleitung ergeben. Grundlegende Exchange und ISA Kenntnisse sind für das Nachvollziehen sicher nicht falsch. 
Ziel des Versuchsaufbaus:
Übersicht über den Aufbau:
Die CAS Server sind als Windows NLB im Multicast Modus auf einer dedizierten Netzwerkkarte konfiguriert. NLB wird dabei auf Port 443 eingeschränkt. Für die Veröffentlichung ist dieses NLB nicht von Bedeutung. Da alle Anfragen vom ISA Server zu kommen scheinen, würde das NLB den gesamten Verkehr zu einem CAS Server leiten. Daher erscheint diese Methode wenig geeignet. Hinzu kommt das Problem der KCD Delegierung. Sie muss auf ein Computer Konto erfolgen. Leider hat der virtuelle NLB kein Konto und fällt damit als Ziel aus. Über DNS werden die IP Adressen der primären Netzwerkkarten sowie die virtuelle IP Adresse des NLB aufgelöst.
Für das ISA Array ist lediglich auf den externen Adaptern ein NLB konfiguriert. Er dient nicht als Proxy so dass intern keine Redundanz erforderlich ist. Es sind zwei virtuelle IP Adressen gebunden.
Da sich KCD mit NTLM Authentifizierung nicht mit der FBA / Basic Authentifizierung gemeinsam auf einem Listener konfigurieren lässt sind zwei IP Adressen und zwei externe DNS Namen erforderlich:
Vorbereitungen KCD
Für KCD müssen folgende Schritte gemacht werden:
Delegation der Anmeldung.
Dies muss auf den Computer Konten von allen ISA Servern des Arrays durchgeführt werden:
Prüfen / Hinzufügen der SPN’s.
Leider werden diese bei der Installation auf W2k8 immer noch nicht automatisch gesetzt. Dies muss auf allen CAS Server ausgeführt werden:
Mit dem Befehl SETSPN -L <shortname> werden die vorhandenen SPN’s angezeigt. In der Regel fehlen die SPN’s für den Dienst „http”: http/<shortname> und http/<fqdn>
Diese können mir den Befehlen SETSPN -A http/<shortname> <shortname> und SETSPN -A http/<fqdn> <shortname> nachgetragen werden.
Beispiel: SETSPN -A http/gt-cas01 gt-cas01 und SETSPN -A http/gt-cas01.xxxxx.local gt-cas01
Vorbereitungen Exchange
Darüber lasse ich mich hier nicht weiter aus, denn dafür gibt es genug Anleitungen. Grundsätzlich reichen alle Standardeinstellungen. Zudem sollten alle externen URL’s gepflegt und gültige Zertifikate installiert sein. Diese müssen auf den FQDN des jeweiligen CAS Servers sowie zusätzlich auf den FQDN des CAS NLB ausgestellt sein.
Für Outlook Anywhere ist RPCoverHTTP zu installieren und Outlook Anywhere an sich zu aktivieren. Für Outlook Anywhere muss die NTLM Authentifizierung eingestellt werden. SSL Offloading sollte aus Sicherheitsgründen nicht aktiviert werden!
Für OWA muss die FBA abgeschaltet und die Integrierte sowie die Basic Authentifizierung und aktiviert werden!
Besonderheit Windows Server 2008 / IIS7:
Um die integrierte Authentifizierung der Webseite mit ISA 2006 und KCD nutzen zu können muss der “Kernel Mode” deaktiviert werden. Diese Option kann global auf dem ganzen IIS abgeschaltet werden. Ich persönlich deaktiviere es lieber auf der “Standard Webseite” der Exchange Dienste. Die Option ist unter den “Advanced Options” der Eigenschaften der integrierten Authentifizierung zu finden.
Vorbereitung ISA Server
Auch auf die Basisinstallation eines ISA Arrays gehe ich nicht näher ein. Je nach Wusch kann in dieser Konfiguration mit HOSTS Datei Einträgen oder Split DNS gearbeitet werden. Auf jeden Fall muss er in der Lage sein die CAS Server, den CAS NLB sowie das Active Directory aufzulösen. Letzteres legt nahe dass eine DNS Auflösung der HOSTS Datei überlegen sein könnte.
Selbstverständlich benötigt die Veröffentlichung valide Zertifikate auf allen Array Mitgliedern. In diesem Fall ist es ein SAN Zertifikat mit folgenden Einträgen:
Hinweis: Optimalerweise sollte der FQDN, welcher für Outlook Anywhere genutzt wird, der subject name des Zertifikates sein. Zwar funktioniert auch der SAN Eintrag, in Outlook muss jedoch die Prüfung des Zertifikatsnames abgeschaltet werden.
Nach der Einrichtung des externen NLB ist die Vorbereitung soweit abgeschlossen.
Vorbereitung Client PC
Das externe Netz des ISA ist ein virtuelles Phantasie Netz meiner Testumgebung. Daher kann man den PC recht sorglos dort hinein stecken. Die Namensauflösung erfolgt über die HOSTS Datei. Damit Outlook überhaupt versucht eine Verbindung aufzubauen muss ein Standard Gateway eingetragen sein. Dieses zeigt aber auf eine nicht vorhandene IP Adresse.
Outlook wurde zuvor im internen Netz installiert und kurz synchronisiert. Theoretisch ist dies auch im „Internet” möglich. Ich habe jedoch aus Zeitgründen auf Autodiscover verzichtet.
Im Client muss nun die Exchange Proxy Funktionmit NTLM Authentifizierung aktiviert werden:
Die Prüfung des Zertifikats klappt bei mir nicht, da ich ein SAN Zertifikat verwenden bei dem der FQDN als SAN-DNS Eintrag und nicht als Principal Name (Subject) eingetragen ist. Legt man Wert auf dieses Sicherheitsfeature sollte für beide Listener ein eigenes Zertifikat angelegt oder “MOBILE” als Subject eingetragen werden. Autodiscover kann als SAN-DNS Eintrag dann mit in das MOBILE Zertifikat.
Test der internen Verbindungen
Sowohl Aufbau als auch Troubleshooting sollte bei der Exchange Veröffentlichung über ISA immer von innen nach außen erfolgen! Es macht schlicht keinen Sinn von außen nach Fehlern zu suchen wenn schon intern eine Seite nicht funktioniert. 
Also starten wir mit dem Test der bekannten URL’s von einem internen Rechner aus. Dabei sollten alle URL’s vom Internet Explorer als „lokales Intranet” erkannt werden um eine integrierte Anmeldung zu erlauben. Alle URL’s müssen ohne Anmelde PoP Up und ohne Zertifikatswarnung ausführbar sein:
Jede URL sollte mit den FQDN alle CAS Server sowie dem FQDN des CAS NLB erfolgreich getestet werden, bevor es weiter geht!
Als Nächstes wird der URL Test vom ISA Server aus wiederholt. Auch hier müssen alle URL’s sauber dargestellt werden. Dafür kann eine Zugriffsregel erforderlich sein, welche HTTPS von „Local Host” auf alle IP Adressen der CAS Server und des CAS NLB erlaubt.
Konfiguration der Listener
Die beiden Listener werden wie folgt konfiguriert:
Konfiguration der Veröffentlichungsregeln
Nun folgt die OWA Veröffentlichung. Hier folgen wir dem Assistenten:
Die Veröffentlichung von Active Sync wird auf dem gleichen Listener und der gleichen Farm durchgeführt:
Die Veröffentlichung von Outlook Anywhere ist etwas anders:
Anschließend ist noch eine Änderung zu machen:
Externer Test
Wenn die Änderungen zu allen Array Mitgliedern repliziert wurden kann der Test auf dem Client weiter gehen.
Zunächst müssen, wie schon bei den internen Tests, die URL’s ohne Anmelde Pop Up und ohne Zertifikatswarnung im IE darstellbar sein. Bei OWA erscheint selbstverständlich die FBA. Um dies zu gewährleisten müssen die „mobile” und „autodiscover” URL’s in der lokalen Intranet Zone sein.
Sollte trotz der lokalen Intranet Zone anmelde Pop Ups erscheinen könnte es an diesem Haken liegen:
Wenn er entfernt wurde sollte es funktionieren. Warum ist hier zu lesen:
http://blog.super-networking.net/2008/02/internet-explorer-enable-integrated-windows-authentication/
Wenn dies alles Funktioniert kann Outlook gestartet werden. Es sollte sich nun automatisch verbinden. Erscheint ein Anmelde Pop Up, was erfolgreich bedient werden kann, so kann folgender Registry Eintrag helfen (auf dem Client):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LmCompatibilityLevel = 2 oder 3
Der Grund dafür ist hier zu finden: http://support.microsoft.com/kb/820281/en-us
Hinweis: Ich veröffentliche diese Informationen wie sie sind und ohne jegliche Gewährleistung auf Vollständigkeit und Richtigkeit! Bitte prüfen Sie meine Angaben zunächst unter Laborbedingungen nach, bevor Sie sie in eine produktive Umgebung übertragen!
Ich freue mich über jedes konstruktive Feedback!
Andy
More Options ...
Kategorien
Tag Cloud
Blog RSS
Comments RSS
Void 
Life « Default
Earth 
Wind 
Water 
Fire Light 
Previous 
Next 
Comment Meta:
Last 50 Posts
Back