Der letzte Artikel zu Kemp und Exchange ist nun schon wieder etwas länger her, daher folgt hier mal wieder eine aktualisierte Version. Für diesen Test habe ich einen Kemp Loadmaster VLM-5000 (den gibt es mit Leute mit MCP ID für das HomeLab kostenlos) und Exchange 2019 verwendet. Die eingesetzte Loadmaster Firmware ist 7.2.48. Der Loadmaster wird klassisch in der 2-Arm Konfiguration betrieben, soll heißen: Die Server (inkl. Exchange) befinden sich in einem anderen VLAN als die Clients. In meiner Testumgebung befindet sich Exchange im Subnetz 172.16.14.0/24 und die Clients im Netz 192.168.100.0/24. Der Loadmaster hat je ein Interface in beiden Netzen und fungiert als L7-Loadbalancer.
Grundkonfiguration Kemp Loadmaster für Exchange
Es gibt drei kleine Einstellungen die Kemp für den Einsatz von Exchange empfiehlt. Zum einen sollte “Subnet Originating Requests” unter “System Configuration > Miscellaneous Options > Network Options” aktiviert werden. Diese Einstellung macht eh in den meisten Konfigurationen Sinn. Hiermit leitet der Loadmaster den Traffic über das jeweilige Interface im Subnet des Real Servers und nicht über das Default Gateway, wenn sich die Server in unterschiedlichen Netzen befinden:
Um Probleme mit den den Exchange Webservices bzw. Outlook for Mac zu vermeiden, sind die Einstellungen “Additional L7 Header” und “100-Continue Handling” wichtig. Beide Einstellungen finden sich unter dem Punkt “System Configuration > Miscellaneous Options > L7 Configuration”:
Das war es auch schon mit den Grundeinstellungen und es kann mit der AD Konfiguration begonnen werden.
Konfiguration SSO / Active Directory
Damit später ESP funktioniert, muss die Verbindung vom Loadmaster zum Active Directory hergestellt werden. Auf dem Loadmaster wird dazu eine neue “Client Side Sigle Sign On Configuration” hinzugefügt:
Unter dem Punkt “Manage LDAP Configuration” können die Domain Controller zu einem LDAP Endpoint hinzugefügt werden:
Damit die Domian Controller hinzugefügt werden können, muss ein LDAP Enpoint angelegt werden:
Als LDAP Server werden die Domain Controller mit Port angegeben. Domain Controller verwenden den Port 636 für das Protokoll LDAPS. Zusätzlich muss ein Benutzer angegeben werden, welcher Leserechte auf das Active Directory hat. Ein normales Domain Benutzerkonto reicht hier aus:
Der neue LDAP Endpoint kann nun in der SSO Konfiguration ausgewählt werden. Das Logon Format sollte auf “Principalname” eingestellt werden:
Die neue Client Side SSO Configuration wird nun in der Übersicht angezeigt:
Jetzt kann das Exchange Template importiert werden.
Exchange Template
Für Exchange 2019 bietet Kemp Templates an, welche die Konfiguration erleichtern. Das Template für Exchange 2019 kann hier runtergeladen werden:
Nachdem das Template runtergeladen wurde, kann es im Loadmaster importiert werden:
Nach dem Import werden in der Übersicht drei Vorlagen angezeigt. Für dieses HowTo wird die Vorlage “Exchange 2019 HTTPS Reencrypted with ESP” verwendet, da es in der Regel keine Anpassung der Exchange Konfiguration erforderlich macht:
Für die Konfiguration werden noch ein paar Daten benötigt, diese werden im nächsten Abschnitt gesammelt.
Benötigte Daten
Für die Konfiguration von ESP in Verbindung mit Exchange 2019 in den folgenden Abschnitten des Artikels, sind drei URLs für die Exchange Umgebung wichtig:
- Allowed Virtual Hosts
- Pre-Authorization Excluded Directories
User Password Form
Beide URLs müssen zunächst ermittelt werden. Damit man alle nötigen Daten zur Hand hat, wenn es an die Konfiguration geht, kann man sich die URLs und Hostnamen ja schon einmal zusammen und in Notepad kopieren, so hat man alle Daten für die Konfiguration griffbereit.
Bei den “Allowed Virtual Hosts” handelt es sich um die Hostnamen unter den Exchange veröffentlicht werden soll. Die Hostnamen für “Allowed Virtual Hosts” ergeben sich aus den Exchange Einstellungen für die virtuellen Verzeichnisse. Hier mal ein Beispiel, wenn die konfigurierte MAPI URL “https://mail.frankysweb.de/mapi” entspricht, ist der “Allowed Virtual Host” für den Virtual Service “mail.frankysweb.de”:
Die “Allowed Virtual Hosts” werden für jedes Protokoll benötigt (Autodiscover nicht vergessen). Der Wert für “Pre-Authorization Excluded Directories” setzt sich aus der GUID des Arbitration Postfachs und der SMTP Domain zusammen. Die URL für “User Password Form” setzt sich aus der Externen URL für das OWA Verzeichnis und dem String “auth/expiredpassword.aspx?url=/owa/auth.owa” zusammen.
Ich hab ein kleines Script erstellt, welches die Daten automatisch zusammen sammelt. Das Script liefert die nötigen Daten, welche für die Konfiguration im nächsten Abschnitt benötigt werden. Die Ausgabe des Scripts sieht dann etwa wie folgt aus:
Kurz zur Erklärung: In der Farbe Grün ist der SubVS dargestellt, in gelb ist der Name der jeweiligen Einstellung für den SubVS dargestellt und in weiß der entsprechende Wert für die Einstellung des SubVS.
Das Script kann hier runtergeladen werden:
Zertifikat
Damit später keine Zertifikatswarnung im Browser oder Outlook auftreten, benötigt der Loadmaster ein SSL Zertifikat. Hier lässt sich ein Zertifikat einer internen PKI verwenden oder ein Zertifikat einer öffentlichen CA. Auch kostenlose Zertifikat von Let’s Encrypt lassen sich hier einspielen.
Für dieses HowTo verwende ich in Zertifikat von Let’s Encrypt. Der Einfachheit halber, habe ich das Let’s Encrypt Zertifikat über die Website SSLForFree bezogen. Für das Zertifikat ist es wichtig, dass alle DNS Namen auf dem Zertifikat vorhanden sind, welche auf den Exchange Servern konfiguriert wurden. Hier können die Daten aus dem oben genannten Script weiterverwendet werden.Alle Hostnamen die unter dem ersten Punkt “Exchange 2019 HTTPS Rencrypted with ESP – Authentication Proxy” als “Allowed Virtual Hosts” aufgeführt werden, müssen auf dem Zertifikat vorhanden sein. Hier lässt sich natürlich auch ein Wildcard Zertifikat verwenden.
Ein bereits vorhandenes Zertifikat lässt sich unter “Certificates & Security” unter dem Punkt “Import Certificate” hinzufügen:
Beim Import muss das Zertifikat im PEM oder PFX Format vorliegen:
Nachdem das Zertifikat importiert wurde, wird es in der Übersicht angezeigt:
Alle Vorbereitungen für die Konfiguration sind nun abgeschlossen und es kann mit der Konfiguration gestartet werden.
Konfiguration Loadmaster für Exchange
Da das Template für Exchange 2019 bereits importiert wurde, kann nun ein neues Virtual Service anhand des Templates erstellt werden. Neben einer IP für den Virtual Service muss auch das entsprechende Template angegeben werden, in diesem Fall “Exchange 2019 HTTPS Reencrypted with ESP”:
Nachdem der neue Virtual Service erstellt wurde, erscheinen direkt die Einstellungen. Unter den Einstellungen der SubVSs (SubVirtualServices“), wird nun der erste SubVS angepasst:
In den Einstellungen des SubVS werden nun zunächst die oder der Exchange Server als Real Server hinzugefügt:
Die IP-Adressen der Exchange Server werden nun als Real Server hinzugefügt. Damit die Exchange Server direkt zu allen SubVSs hinzugefügt werden, kann das Häkchen bei “Add to all SubVSs” aktiviert werden:
Nachdem die Exchange Server als Real Server hinzugefügt wurden, sollten die einzelnen SubVSs in der Übersicht mit einem grünen Häkchen dargestellt werden.Jetzt kann das zuvor importierte Zertifikat dem Virtual Service zugewiesen werden:
Das Zertifikat wird in der Liste “Available Certificates” angezeigt und kann dem Virtual Service zugewiesen werden:
Jetzt kann mit der Konfiguration von ESP begonnen werden. Um ESP zu konfigurieren, wird der Virtual Service mittels “Modify” angepasst:
Jeder einzelne SubVS muss nun die entsprechende ESP Konfiguration erhalten. Die erforderlichen Werte hat das Script geliefert, diese Einstellungen werden nun benötigt. Bis auf den SubVS “Exchange 2019 HTTPS Reencrypted with ESP – OWA” ist die Konfiguration für alle SubVSs gleich, daher hier einmal die Konfiguration für alle SubVSs (bis auf OWA):
In den ESP Einstellungen der SubVSs wird nun die zuvor angelegte “SSO Domain” ausgewählt und die “Allowed Virtual Hosts” konfiguriert:
Die Daten zu den Allowes Virtual Hosts liefert das Script, hier als Beispiel:
Manche SubVSs haben als “Client Authentication Mode” den Wert “Delegate to Server” konfiguriert. Diese Einstellung kann so belassen werden und es muss nur “Allowed Virtual Hosts” konfiguriert werden:
Für alle SubVS mit Ausnahme von “Exchange 2019 HTTPS Reencrypted with ESP – OWA” werden nun die “Allowed Virtual Hosts” und die “SSO Domain” konfiguriert. Dazu muss jeder einzelne SubVS angepasst werden.
Der SubVS “Exchange 2019 HTTPS Reencrypted with ESP – OWA” erfordert etwas mehr Konfiguration, daher hier einmal die Einstellungen, welche das Script liefert:
Die Daten aus dem Script werden nun in die ESP Konfiguration von OWA eingetragen:
Wenn alle SubVSs angepasst wurden, kann mit den Tests begonnen werden.
Tests
Um die Konfiguration zunächst zu testen, kann nun die HOSTS Datei auf einem Client angepasst werden. In meiner Testumgebung habe ich dazu “mail.frankysweb.de” und “autodiscover.frankysweb.de” umgeleitet:
Jetzt lässt sich Outlook und insbesondere OWA testen. Für den OWA-Test bietet es sich an, den Inkognito-Modus des Browsers zu verwenden um gespeicherte Anmeldungen zu umgehen. Der Kemp Loadmaster bietet nun für die OWA Seite eine Anmeldemaske an (nicht gerade hübsch):
Der Browser sowie Outlook sollten keine Zertifikatswarnungen liefern und normales Arbeiten sollte möglich sein. Wenn soweit alles funktioniert, kann die Anpassung am DNS und Router vorgenommen werden.
Anpassung DNS und Router / Firewall
Wenn die Tests erfolgreich waren, kann die Anpassung der HOSTS-Datei wieder rückgängig gemacht werden. Damit alle Clients nun den Weg über den Loadbalancer nutzen, wird die DNS Konfiguration angepasst. Die IP-Adressen für “mail.frankysweb.de” und “autodiscover.frankysweb.de” werden nun auf die IP-Adresse des Virtual Service des Loadmasters geändert:
Sobald die Clients den DNS-Cache aktualisieren, wird der Loadbalancer für den Zugriff auf Exchange verwendet. Zusätzlich zur Änderung im DNS, muss meistens der NDAT Eintrag auf Router oder Firewall geändert werden, hier wird nun ebenfalls für die NAT Einträger der Ports 443 und 80 die IP auf die IP des Virtual Service geändert. Somit nutzen auch externe Clients den Weg über den Loadbalancer.
Anpassung (optional)
Wenn das Kemp Login Form nicht gefällt, kann es ausgetauscht werden. Hier gibt es eine Vorlage mit der sich ein eigenes Login Form erstellt werden kann:
Somit lässt sich das Design an die Corporate Identity anpassen. Alternativ gibt es hier auch ein hübscheres Login Form zum Download bzw. einen Artikel wie dieses erstellt wird:
Hat vielleicht jemand eine Idee, warum Outlook 365 kein Problem hat zu starten wenn Userprofil ist im Online-Modus und wenn Cache-Modus benutzt wird, kommt beim Start ein Anmeldefenster und die Anmeldung nicht funktioniert obwohl gleiche Anmeldedaten verwendet werden wie beim Online-Modus?
Gute Anleitung, eine Anmerkung habe ich: Die „User Password Change URL“ und „User Password Change Dialog Message“ müssen nicht im OWA SubVS, sondern unter „AuthProxy“ eingetragen werden, da es sonst nicht möglich ist, das Kennwort via ESP OWA zu ändern. Der Link für die Passwortänderung wird nicht eingeblendet und es kommt nur Login failed. Zusätzlich ist es zwingend erforderlich, dass ein Text (z. B. „Your Account has expired. Please change your password.“) unter „User Password Change Dialog Message“ eingetragen ist, da es sonst nicht funktioniert. Ich habe es aber mit Exchange 2019 getestet und es hat nur funktioniert, wenn beide Felder im AuthProxy gefüllt sind. Wenn man es zusätzlich im OWA SubVS einträgt geht es auch noch, aber die Einträge haben keine Relevanz für die Funktion. Sofern man die Felder im OWA SubVS ausfüllt, können die User nur durch das direkte Öffnen des Links ihr Kennwort neu setzen. Aber welcher User kennt den Link auswendig ?
Die offizielle KEMP-Doku sagt hier zwar auch was anderes, bzw. es ist nicht eindeutig beschrieben.
https://support.kemptechnologies.com/hc/en-us/articles/115003676151-How-to-configure-ESP-Forms-Based-to-Forms-Based-Authentication-FBA-with-Exchange
„To enable the password reset feature, you must adjust the AUTH proxy and the OWA SubVS.“ – Das stimmt so nach meinen Tests nicht, es reicht wie gesagt, wenn beides unter AuthProxy eingetragen ist. Im OWA ist nur unter „Pre-Authorization Excluded Directories“ mit „/owa/GUID@contoso.de* /owa/auth/expiredpassword.aspx*“ erforderlich und natürlich der Logoff String.
Moin zusammen,
hat mal jemand getestet ob man bei einer Migration von Exchange 2016 auf Exchange 2019 die Kemp Konfigruation (explizit den virtuellen Service) belassen kann? Ich habs gemacht, hatte damals das normale 2016er Template (ohne reencrypt) verwendet. Es funktioniert auch soweit. Man kann aber keinen Chrome mehr nutzen?! Firefox, Safari, IE alles kein Problem nur kein Chrome :D Bzw. auch den neuen von Microsoft nicht. Wenn ich anstatt der Kemp VS URL direkt den Server DNS eingebe, kappt es auch mit Chrome. Liegt es wirklich an dem 2016er Template von Kemp in Verbindung mit 2019er Exchange Servern? Hängen halt 1000 Nutzer dran und das Zeitfenster ist knapp, da kann ich nicht lange experimentieren.
Hallo Frank,
danke für die gute Anleitung. Ich habe das Exchange ESP Template zusätzlich zu unserem normalen OWA Zugang auf einer anderen Public IP angelegt und die Hosts Datei auf dem Rechner entsprechend zum Testen modifiziert. Ich lande auch direkt auf der Kemp Seite und kann mich anmelden. Allerdings lande ich dann nicht direkt im OWA sondern erhalte die OWA Login Seite. Hast du einen Tip für mich?
Danke und Gruß
Sebastian
Hi Sebastian,
konntest du das Problem lösen? Hab das gleiche!
danke!
René
Hallo Rene,
nein, das Problem besteht weiterhin.
Gruß
Sebastian
Moin,
ich habe gerade meine ersten KEMP VLMs in Betrieb genommen und die Exchange 2016 Templates zur Einrichtung der Virtual Services verwendet.
Leider kann ich nun keine PSSession mehr per ConnectionUri zu den Exchange-Servern aufbauen.
Auzug aus der ISE:
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://mail.domain.de/powershell -AllowRedirection
Import-PSSession $session -AllowClobber
WARNUNG: Ihre Verbindung wurde an den folgenden URI umgeleitet: „https://mail.domain.de/powershell?PSVersion=5.1.17763.771 “
New-PSSession : [mail.domain.de] Beim Verbinden mit dem Remoteserver „mail.domain.de“ ist folgender Fehler aufgetreten: Error occurred during the Kerberos reponse.
Jemand ne Idee oder einen Tip für mich?
Danke und beste Grüße
Bent
Hi,
wenn ich das richtig sehe sollte eigentlich wenn https://mail.domain.tld/ aufgerufen werden automatisch https://mail.domain.tld/owa weitergeleitet werden. Zumindest sehe ich bei dem SubVS ein Content Rule die für denn Root Pfad greift.
Allerdings funktioniert das in meiner Testumgebung nicht. Aus irgendeinem Grund bekomme ich beim Root Pfad immer ein Access denied. Wenn ich /owa ode /ecp aufrufe funktioniert alles wie es soll.
Hab ich vielleicht irgendwo was vergessen einzustellen?
LG
Daniel
Hallo Daniel,
damit die Umleitung funktioniert, musst du im OWA SubVs in den ESP Einstellungen unter „Allowed Virtual Directories“ noch „/“ (Schrägstrich ohne ANführungszeichen hinzufügen. Die Einstellung für „Allowed Virtual Directories“ sollte also so aussehen:
/owa* /
Gruß,
Frank
Hallo Frank,
danke genau das wars nun funktioniert alles wie es soll.
HI Daniel,
ganz einfach die Regel steht hinter dem ESP Modul. UNd das erlaubt nur /owa* also wird man mit root geblocked.
Ich würde die root auf owa wandel regel daher auf den Hauptservice legen, das die wandlung bereits stattgefunden hat, bevor man im Sub Service in das ESP Modul fällt.
Hi Frank,
ich kann mich Erik nur anschließen. Sehr schön geschrieben. Ich bin mittlerweie im dritten Jahr KEMP Zertifiziert und habe das Thema noch nie so auf den Punkt gebracht gesehen.
Weiter so.
LG
Timbo
Hi Frank,
warum nutzt du nicht gleich das PowerShell Modul vom Kemp und setzt die Directory direkt via „Set-AdcVirtualService – AllowedHosts „HOSTNAME“ -AllowedDirectories „/test““
Grüße Michael Kunesch
Sehr schön geschrieben!
Danke