Unsere Testumgebung besteht aus zwei virtuellen Exchange 2013 Servern, einem Windows Server 2012 Domain Controller und den zwei virtuellen Kemp Loadmaster VLM-1000 Appliances.

Hinweis: Auf unserem Infotag am 19.09.2013 können Sie sich Live von der Konfiguration überzeugen. Kommen Sie dazu an unseren Infostand 1.

Die beiden Loadmaster sind in einem Active/Passive Verbund konfiguriert. Die Loadmaster sind als 2-Arm Konfiguration ausgeführt, d.h die Exchange Server stehen in einem eigenen Subnetz und sind vom restlichen Client/Server Netzwerk getrennt. Die Loadmaster übernehmen gleichzeitig auch die Funktion des Default Gateways für die beiden Exchange Server. Zusätzlich wird auf den Loadmastern eine Preauthentication für OWA und ECP durchgeführt. Dies kann mit dem Kemp Edge Security Pack, welches seit der Firmware Version 7.0 mitgeliefert wird durchgeführt werden. Einzige Ausnahme sind die LM-2200 und der VLM-100 die nicht genügend Ressourcen für das ESP mitbringen.

Aber nun los. Nach der Grundkonfiguration des Loadmasters mit der Version 7.0-4 (inzwischen ist die 7.0-6 aktuell) sieht man schon, dass sich an der Oberfläche etwas getan hat. Diese gibt nun direkt mehr Informationen auf den ersten Blick als die der Version 6.

Vorher ist natürlich im Boot Modus die Netzwerkkonfiguration (mindestens) der eth0 Schnittstelle erforderlich. Diese sieht dann so aus.

Danach folgte die Konfiguration der eth1 Schnittstelle für das eigene Subnetz, in dem die beiden Exchange 2013 Server stehen.

Im Anschluß haben wir erstmal aus zwei einzelnen Kemp VLM ein HA Pair gemacht. Dafür habe ich dann noch die HA Parameter angepasst. Wichtig ist in diesem Zug die HA-Virtual ID von 0 auf irgendeinen anderen Wert (zwischen 0 & 255) zu stellen. Andere Netzwerkgeräte könnten sonst bei der Nutzung von VRRP in einen Konfigurationskonflikt geraten.

Weiter gehts mit der Layer7 Konfiguration und der allgemeinen Netzwerkkonfiguration. Bei der Layer 7 Konfiguration finde ich es wichtig, den Haken zu setzen “Drop Connections on RS failure”. Dieser beendet alle aktiven Verbindungen zu einem Host der nicht mehr erreichbar ist und lässt diese neu aufbauen.


Hier noch der Screenshot der Netzwerkkonfig. Da hier eine 2-Arm Konfiguration vorliegt muss auch der Haken für “Enable Server NAT” gesetzt sein.

Nach dem damit dann die Grundkonfiguration der beiden Loadmaster als HA-Pair abgeschlossen ist, geht es nun daran die virtuellen Dienste zu Konfigurieren. Eigentlich können wir, damit man nicht alles von Hand bauen muss, die Templates von Kemp nur empfehlen. Diese sind unter anderem für Exchange 2010 & 2013 zu haben. Aber auch für Lync 2010/2013. Hier beschäftigen wir uns aber jetzt mit denen für Exchange 2013 mit Edge Security Pack. Die Templates gibt es übrigens hier: Kemp Loadmaster Templates

Diese kann man dann herunterladen und ganz einfach importieren. Dies kann man über die Seite “Manage Templates” machen.

Die Templates bringen soweit, fast die komplette Konfiguration für das ESP schon mit.Die noch erforderlichen Konfigurationen schauen wir uns jetzt an.

Als erstes muss eine Single Sign On Domain erstellt werden. Dafür muss man den FQDN der Domain angeben und im Anschluss die Domain Controller (Leerzeichen separiert). Und natürlich noch ob SLDAP oder nur LDAP.

Nun geht es an das erstellen eines virtuellen Dienstes. Dafür wählen wir das Template aus und geben dem Dienst eine IP Adresse aus dem Zugriffs Netzwerk (hier 192.168.1.x).

Gleiches wiederholen wir mit dem Template für den SMTP Traffic. Dieses erstellen wir einfach auf die selbe IP Adresse wie den anderen virtuellen Dienst. Zusätzlich baut das Exchange 2013 ESP Template auch noch einen weiteren virtuellen Dienst für den Redirect von HTTP nach HTTPS. Dies sieht in der Übersicht dann wie folgt aus.

In dieser Übersicht sieht man nun, dass in dem Exchange 2013 virtuellen Dienst, mehrere “Unterdienste” (SubVS) erstellt wurden. Die Namen dürften den meisten Exchange Admins geläufig sein.

Beim klicken auf Modify erscheinen nun die Eigenschaften des virtuellen Hauptdienstes. Hier ist es wichtig, ein passendes Zertifikat für den Zugriffsnamen zu importieren. Wir haben es uns hier einfach gemacht und einfach ein Wildcard Zertifikat der internen PKI importiert (das gleich Zertifikat ist übrigens auf den Exchange Server installiert). Wichtig ist, dass auch der Haken “reencrypt” gesetzt ist, da Exchange 2013 kein SSL Offload supportet. Es muss also HTTPS beim Exchange ankommen. Des Weiteren sollte man noch die Persistance Optionen und die Scheduling Method anpassen. Dafür gibt es verschiedene Optionen.

Im unteren Bereich sind nun die einzelnen Unter-Dienste zu sehen (SubVs). Auch hier gelangt man über den Button Modify an die Konfiguration der einzelnen Dienste. Beispielhaft schauen wir uns jetzt den OWA Dienst an.

Hier sind nur noch kleine Anpassungen aufgrund des Templates vonnöten. Dies betriff die SSO Domain die noch auf die neu konfigurierte umgestellt werden muss. Weiterhin müssen im Feld “Allowed Virtual Hosts” noch die Namen eingetragen werden, auf die der Loadmaster für Anfragen reagieren soll. Hier in unserem Fall also “ex.esp.org” und “mail.esp.org”. Alle anderen Anfragen werden abgelehnt. Hier sieht man nun auch die Authentication Methods für OWA. Leider kann das ESP aktuell zu den Exchange Servern nur Basic Authentication. Dies soll in zukünftigen Releases aber noch geändert werden. Dies bedeutet natürlich auch, dass die virtuellen Verzeichnise für OWA und ECP auf dem Exchange Server auf Basic Authentication umgestellt werden müssen. Weiterhin ist es wichtig, das im Feld “Pre-Authorization Excluded Directores” folgendes drin steht: /owa/exchangeserverGUID. Die entsprechende Guid kann man sich mit dem folgenden Befehl ausgeben lassen:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “OrganizationCapabilityClientExtensions”} | fl exchangeGuid, primarySMTPAddress

Das “SSO Image Set” ändert ausschließlich das Erscheinungsbild der Authentifizierungswebsite. Aktuell ist es leider nicht möglich eigene Bilder dort einzufügen oder das Farbset zu ändern. Auch dies soll noch in zukünftigen Releases nachgebessert werden. Die “SSO Greeting Message” wird dann später auf der Login Seite dem Bentuzer angezeigt. Nun muss noch der Logoff String konfiguriert werden. Dies erfolgt nach Vorgabe des Blogeintrags des Exchange Teams. Als letztes werden nun noch die sogenannten “Real Server” hinzugefügt. Das sind nun die reellen Exchange Server auf denen die wirklichen Dienste laufen.

Diese Schritte müssen wir soweit für die anderen Sub Dienste wiederholen. Jedoch benötigt nicht jeder Dienst Pre-Auth bzw. sogar eine Formbased Authenitcation. Formbased ist ausschließlich den Diensten OWA und ECP vorbehalten. ActiveSync nutzt sowohl als Client Authentication als auch für die Server Authentication Basic. Der Rest erforder keinerlei Pre-Auth.

Nachdem nun soweit alle konfiguriert ist sollte beim Aufruf der entsprechenden URL die Form Based Auth angezeigt werden.

Wenn nun alles richtig konfiguriert ist, sollte man sich einloggen können und auch danach Outlook Web App angzeigt bekommen.

Sollte etwas nicht so funktionieren wie man sich das vorstellt, sollte man zuerst am besten die Statistiken checken. Grobe Fehler werden dort direkt angezeigt (Probleme mit der Authentifizierung, Server Down).

Wie hier in unserem Fall ist zum Beispiel der Server 192.168.2.200 nicht per HTTPS zu erreichen.

Zur genaueren Fehlersuche empfiehlt es sich unter den “Logging Options” die entsprechenden Logfiles zu prüfen.

Wir hoffen damit einen kleinen Einblick in das aktuelle Kemp ESP gegeben zu haben. Es erhöht den Einsatzzweck der Geräte um ein vielfaches. Des Weiteren ist das Update für alle mit gültigem Support kostenlos und kann über den Kemp Support angefordert werden.

 

Viele Grüße

Ihre S&L

SUPPORT
X
X