Forefront TMG has now been discontinued and a replacement will have to be found sooner or later. There are now several manufacturers who are filling the gap left by Forefront TMG. I will test some promising solutions and publish a howto for each of them. Finally, there will be an article comparing the solutions and listing the pros and cons from my point of view. So much for the plan.
I have therefore created a standard test environment that I will use for all solutions. The test environment has a relatively simple structure:
There is a Windows Server 2012 R2 with the name DC1 on which the Domain Controller role and Outlook 2013 are installed. Exchange 2013 is also installed on Server 2012 R2. The Exchange servers have the names EX1 and EX2. This is always the starting point for all solutions.
I defined a few evaluation criteria in advance in order to be able to draw a conclusion later. Mind you, these are my own criteria, which probably say little about the quality of the individual products. But more on that later.
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