Forefront TMG ist ja nun abgekündigt und es muss auf Kurz oder Lang Ersatz her. Es gibt mittlerweile einige Hersteller die in die Lücke springen die Forefront TMG hinterlässt. Einige vielversprechende Lösungen werde ich also testen und zu jedem auch gleich ein Howto veröffentlichen. Zum Schluss kommt dann noch ein Artikel der die Lösungen miteinander vergleicht und aus meiner Sicht die Vor- und Nachteile auflistet. Soweit der Plan.
Ich habe also eine Standard Testumgebung erstellt, die ich für alle Lösungen verwenden werde. Die Testumgebung ist relativ einfach aufgebaut:
Es gibt einen Windows Server 2012 R2 mit dem Namen DC1 auf dem die Domain Controller Rolle und Outlook 2013 installiert ist. Exchange 2013 ist ebenfalls auf Server 2012 R2 installiert. Die Exchange Server tragen die Namen EX1 und EX2. Dies bildet immer die Ausgangssituation für alle Lösungen.
Ich habe mir vorab ein paar Bewertungskriterien festgelegt um später ein Fazit ziehen zu können, wohlgemerkt sind das meine eigenen Kriterien, die wahrscheinlich wenig über die Qualität der einzelnen Produkte aussagen. Dazu aber später mehr.
In diesem Artikel geht es also um die neue Rolle “Webanwendungsproxy” die in Server 2012 R2 enthalten ist. Der Webanwendungsproxy ist ebenfalls ein Reverse Proxy für Webseiten und kann auch für Exchange verwendet werden. Die Rolle Webanwendungsproxy setzt die Active Directory Verbunddienste voraus um Benutzer zu authentifizieren. Daher beschreibe ich die Installation und Konfiguration von den Active Directory Verbunddiensten und die Konfiguration des Webanwendungsproxys. Ich habe dazu wieder meine Testumgebung angepasst:
Die Active Directory Verbunddienste (AD FS) werden auf DC1 installiert, der Webanwendungsproxy auf einem Windows Server 2012 R2 mit dem Namen Proxy1. Proxy1 ist Active Directory Mitglied. Für ADFS werden gültige Zertifikate benötigt, daher verwende ich ein Wildcard Zertifikat von einer internen Zertifizierungsstelle für meinen Test
Da sich der Webanwendungsproxy nicht ohne ADFS einrichten lässt, installiere ich zunächst die Rolle auf dem Server DC1
Sobald die Installation Abgeschlossen ist, kann die Rolle konfiguriert werden
Im ersten Dialog wird “Erstellt den ersten Verbundserver in einer Verbundserverfarm.” ausgewählt
Der Benutzer kann so bleiben
Im nächsten Dialog muss ein gültiges SSL Zertifikat ausgewählt werden, ich habe hier der Einfachheit halber ein Wildcard Zertifikat von einer internen CA verwendet. Des weiteren muss ein DNS-Name für den Verbunddienst und ein Anzeigename eingetragen werden
Für den Dienst muss jetzt noch ein AD-Konto hinterlegt werden
Die Konfiguration wird in einer Datenbank gespeichert, für meinen Test verwende ich die Windows Internal Database
Jetzt kann installiert werden
Paralell zur Installation kann schon mal der DNS-Name für den Verbunddienst am DNS-Server eingetragen werden
Sobald die Installation abgeschlossen ist, kann die Konfiguration der Vertrauensstellung mit dem Webanwendungsproxy fertiggestellt werden, dazu die AD FS Konsole öffnen und eine “Ansprüche nicht unterstütze Vertrauensstellung….” anlegen
Anzeige Namen eintragen
und dann folgende URL eintragen:
Die restlichen Einstellungen können gemäß der Vorgabe übernommen werden
Im nächsten Dialog wird eine neue Regel erstellt, ich beginne mit einer “alles erlauben” Regel
Unter dem Punkt Vertrauensstellungen sollten wir jetzt unsere neue Vertrauensstellung wiederfinden
Jetzt kann der Webanwendungsproxy auf dem Server Proxy1 installiert werden
In diesem Fall wird nur der Webanwendungsproxy benötigt
Nach der Installation kann direkt die Konfiguration gestartet werden
DNS-Name und Administrator Konto des AD FS Servers angeben
Dann noch das Zertifikat auswählen, ich verwende hier wieder mein Wildcard Zertifikat
Fast fertig….
Jetzt wird noch ein SPN benötigt, dazu den ADSI Editor öffnen und im Namenskontext das Computer Konto des Proxy Servers suchen. Für das Attribut “servicePrincipalName” 2 Werte hinzufügen: “HTTP\PROXY” und “HTTP\Proxy.frankysweb.local”, also einmal den Shortname und einmal den FQDN des Servers mit vorangestellten HTTP\
Jetzt muss noch die Delegierung aktiviert werden, dazu die Konsole “Active Directory Benutzer und Computer” öffnen und auf dem Computer Konto des Proxy Servers den oder die Exchange Server mit dem Protokoll HTTP hinzufügen
Zum Schluss müssen die Exchange URLs am Proxy Server veröffentlicht werden. In der Konsole Remotezugriff wird dazu der “Assistent zum Veröffentlichen neuer Anwendungen” ausgeführt.
OWA und ECP werden mit der ADFS Methode authentifiziert, die restlichen URLs mit PassThrough, hier das Beispiel für OWA
Hier die Vertrauensstellung auswählen die weiter oben erzeugt wurde
URLs eingeben
Und den Vorgang für ECP nach dem selben Schema wiederholen. EWS, AutoDiscover, ActiveSync, OAB und Outlook Anywhere werden mit PassThrough Authentifizierung veröffentlicht.
Nachdem alle Regeln eingetragen sind, erscheint das Login Fenster des Verbunddienstes
Puh, geschafft… Tabelle pflegen… 
Hallo Frank,
ich beziehe mich auf diesen ja schon etwas älteren Artikel, da ich keinen aktuelleren finden konnte. Gibt es hier evtl. eine aktuellere Veröffentlichung?
Aktuell besteht eine Aufgabenstellung Exchange 2016 OWA und EAS (später auch 2019) via ADFS/WAP auf 2016er Servern zu publizieren.
Normalerweise stellt man bei einer solchen Konfiguration den WAP in die DMZ und nimmt ihn nicht in die Domäne auf. Wie verhält es sich bei dieser Konfiguration mit den SPNs und den Delegierungen? Oder ist es zwingend erforderlich, dass der WAP Domänen Mitglied sein muss, wenn man Exchange OWA und/oder EAS publizieren will?
Gruß
Jörg