Wow, ich habe es geschafft, veröffentlichen von Exchange Websites mit dem Webanwendungsproxy (Web Application Proxy, WAP) in Windows Server 2012 R2.
WAP ist ein neuer Rollendienst der Remotezugriffsrolle unter Windows Server 2012 R2, näheres dazu hier: TechNet Artikel
Da Microsoft den TMG, wie ja bekannt abgekündigt hat, muss eine neue Lösung her um Exchange oder Lync für Benutzer unsere Unternehmensumgebung zu veröffentlichen. Microsoft bietet mit WAP nun eine Möglichkeit dies, in Zusammenarbeit mit AD FS, zu tun.
Folgende Systeme habe ich dazu installiert:
| Server | Funktion | IP-Adresse |
| DC | AD DS, DNS, AD CS | 10.0.0.1/16 |
| EX1 | Exchange Server 2013 | 10.0.0.2/16 |
| ADFS | Active Directory Federation Services | 10.0.0.3/16 |
| Proxy | Webanwendungsproxy | 10.0.0.4/16 |
Zusätzlich ist noch ein Router vorhanden der vom Öffentlichem Netz (WAN) die HTTPS anfragen beantwortet und auf den Proxy weiterleitet.
Der interne Domänenname ist sichel.loc, der externe öffentliche Name ist sichel.com. Die Öffentlichen Namen sind: mail.sichel.com & adfs.sichel.com.
Hier eine visuelle Hilfestellung:
So ist die Testumgebung für WAP mit ADFS und Exchange aufgabut.
Bevor es losgeht sind folgende Gegebenheiten bereits vorhanden:
- AD Domäne ist installiert
- DNS funktioniert
- AD CS ist funktionstüchtig
- AD CS Webdienste installiert
- Exchange funktioniert
- Zertifikat für Exchange ist vorhanden (interne & externe Namen)
- Optional: FFL & DFL Server 2012 oder 2012 R2
Schritt 1 – Interne Anpassungen vornehmen
- Am Domaincontroller anmelden
- DNS Verwaltung öffnen
- Neue Zone erstellen: sichel.com –> Externe Name damit der Proxy darüber die AD FS findet
- In der neue Zone sowohl Mail als auch ADFS hinzufügen mit den Internen IPs (Bild 2)
Schritt 2 – Wildcard Zertifikate anfordern
- Auf die Website der CA wechseln, bei mir: https://ca.sichel.loc/certsrv
- Ein Zertifikat anfordern
- Erweiterte Zertifikatsanforderung einreichen
- Anforderung an Zertifizierungsstelle erstellen oder einreichen –> Evtl. Benachrichtigung mit „Ja“ bestätigen
- Wie im Bild entsprechen hinterlegen und ganz unten noch einen Anzeigenamen eintragen (Bild 3)
- Anschließend kann das Zertifikat installiert werden –> Achtung: Das Zertifikat wird unter Lokaler Benutzer gespeichert: hier Exportieren und unter Lokaler Computer importieren.
- Sicherstellen dass das Zertifikat sowohl auf Proxy als auch auf ADFS installiert wurde
- Fertig
Schritt 3 – AD FS Group Managed Service Account (gMSA)
Für die gMSA muss die Gesamtstrukturfunktionsebene (FFL) auf Windows Server 2012 festgelegt sein. Daher habe ich weiter oben im Text „Optional“ geschrieben. Sollten gMSA nicht möglich sein kann auch ein Benutzer angelegt werden( ADFS-ServiceUser, Dom-Admin, Kennwort läuft nie ab). Sollte ein Benutzer angelegt werden entfällt Schritt 3.
- Auf ADFS das PowerShell Modul für Active Directory installieren (Server Manager –> Features –> Remoteserververwaltungstools –> Rollenverwaltungstools –> AD DS)
- Im AD eine neue Gruppe erstellen: ADFS Server und den Server ADFS hinzufügen und diesen neu Starten
- Anschließend das PS Modul AD auf ADFS öffnen
-
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
-
New-ADServiceAccount -Name ADFS-Service -DNSHostName adfs.sichel.loc -PrincipalsAllowedToRetrieveManagedPassword "ADFS Server"
-
Install-ADServiceAccount "ADFS-Service"
-
Test-ADSErviceAccount "ADFS-Service"
- –> Ergebnis muss „True“ sein
- Fertig
-
- Fertig
Schritt 4 – AD Federation Services installieren
- Server Manager öffnen auf ADFS
- Rollen und Features hinzufügen
- Rollen –> Active Directory-Verbunddienste –> 3x Weiter & Installieren
Schritt 5 – AD Federation Services konfigurieren
- Server Manager Meldung: ADFS Konfiguration abschließen, es folgt ein Assistent:
- Willkommen –> Erstellt den ersten Verbundserver –> Weiter
- Mit AD DS Verbinden (Kann so bleiben) –> Weiter
- SSL Zertifikat aus Schritt 2 angeben, Verbunddienstnamen angeben: adfs.sichel.com, Anzeigename festlegen: Sichel IT ADFS –> Weiter
- Dienstkonto angeben: ADFS-Service$ –> Weiter
- Datenbank: Interne Windows Datenbank –> Weiter
- Optionen prüfen –> Weiter
- Voraussetzungen –> Konfigurieren
- Schließen
- AD FS Management Konsole öffnen
- Zu Vertrauensstellungen der Vertrauenden Seite wechseln
- Unter Aktionen –> Ansprüche nicht unterstützter Vertrauensstellung der vertrauende Seite hinzufügen:
- Willkommen –> Start
- Anzeigenamen angeben: Sichel IT Exchange Server –> Weiter
- Bezeichner konfigurieren: https://adfs.sichel.com/adfs/services/trust –> Weiter (Bild 4)
- Mehrstufige Authentifizierung (so belassen) –> Weiter
- Bereit –> Weiter
- Autorisierungsregeln anzeigen lassen –> Schließen
- Nun öffnet sich ein Assistent zum Hinzufügen von Regeln:
- Regelassistent: Vorlage „Alle Benutzer zulassen“ –> Weiter –> Fertig stellen
- Fertig
- Fertig
Schritt 6 – Webanwendungsproxy installieren
- Anmelden auf Proxy
- Sicherstellen dass das Zertifikat vorhanden ist!!!
- Server Manager –> Rollen und Features –> Rollen –> Remotezugriff –> Webanwendungsproxy
- ServerManager –> Konfiguration abschließen: Assistent:
- Willkommen –> Weiter
- Name des Verbunddienst (Schritt 5, 1.3) adfs.sichel.com
- Benutzername ist Administrator und sein Kennwort –> Weiter
- AD FS Proxyzertifikat =*sichel.com –> Weiter
- Bestätigung –> Konfigurieren
- Web Application Proxy wurde Erfolgreich konfiguriert
- Schließen
- Fertig
Schritt 7 – Anpassungen im AD
Zunächst müssen wir dem Proxy noch einige SPNs hinzufügen:
- Am DC anmelden
- ADSI-Editor öffnen
- Verbindung zum Standardmäßigem Namenskonext herstellen
- Das Computerobjekt vom Proxy-Server suchen / wählen (CN=Proxy)
- Eigenschaften öffnen
- Das Attribut „servicePrinipalName“ suchen und öffnen
- Zwei Werte hinzufügen (Bild 5):
- HTTP/Proxy
- HTTP/Proxy.sichel.loc
- Fertig
Nun müssen wir noch die Delegierung am Proxy-Server konfigurieren:
- AD Benutzer und Computer öffnen
- Zum Computerobjekt von Proxy wechseln und die Eigenschaften öffnen
- Die Registerkarte „Delegierung“ aufrufen
- Den Punkt „Computer bei Delegierung angegebener Dienste vertrauen“ mit dem Punkt „Beliebiges Authentifizierungsprotokoll verwenden“ auswählen
- Via „Hinzufügen“ den Exchange Server über die Schaltfläche „Benutzer und Computer“ auswählen
- Den Diensttyp „http“ auswählen und mit OK bestätigen (Bild 6)
- Den Proxy-Server neu starten
- Fertig
Schritt 8 – Exchange Websites veröffentlichen
Da nun alle Konfigurationen hinterlegt sind, können wir jetzt anfangen und die Exchange Websites (OWA, ECP, OAB, ActiveSync & AutoDiscover) veröffentlichen. Dies wird selbstverständlich auf dem WAP erledigt.
- Am Proxy anmelden
- Remotezugriffsverwaltungskonsole öffnen
- Web Application Proxy auswählen
- Aktionsmenü –> Veröffentlichen auswählen, es folgt ein Assistent:
- Willkommen –> Weiter
- Vorauthentifizierung: AD FS –> Weiter (Bild 7)
- Vertrauende Seite auswählen: Sichel IT Exchange Server –> Weiter (Bild 8)
- Name: OWA; Externe URL: https://mail.sichel.com/OWA/; Externes Zertifikat: *.sichel.com; URL Backend: https://mail.sichel.com/OWA/; SPN: HTTP/ex1.sichel.loc –> Case sensitiv!!! –> Weiter (Bild 9)
- Veröffentlichen
- Identisch wiederholen für ECP!!!
- Erneut auf Veröffentlichen klicken, allerdings bei Vorauthentifizierung „PassThrough“ wählen und für OAB, ActiveSync & Autodiscover setzten.
- Anschließend sind sieben Veröffentlichungsregeln hinterlegt
- Fertig
Hier im Bild eine Übersicht meiner Regeln:
Schritt 9 – Der erste Test …
Je nachdem wie die Bereitstellungsart der Testumgebung ist, unterscheidet sich der Zugriff „von außen“. Ich habe bei mir als Router einen Windows Server 2012 R2 RRAS Server implementiert. Dieser ist nicht Mitglied der Domäne und hat auschließlich den Rollendienst RRAS Installiert. Dieser hat zwei Netzwerkkarten installiert, eine steht im Domänennetzwerk (bei mir im Privaten Netzwerk nur für Virtuelle Computer) und die zweite steht auf Bridged in mein Heimnetzwerk. Für diese Schnittstelle ist NAT aktiviert und eine Portweiterleitung auf mein Proxy eingerichtet, nur HTTPS / 443. Somit kann ich „von außen“ welches ein Notebook im Heimnetzwerk ist, auf meine virtuellen Server zugreifen, über den Router. An diesem PC habe ich in der HOST-Datei zwei IPs mit Namen hinzugefügt:
- 192.168.178.150 mail.sichel.com
- 192.168.178.150 adfs.sichel.com
Dann habe ich noch das Zertifikat meiner Root CA importiert (natürlich mit OID für EV, bekannt aus früheren Beiträgen von mir) und schon kann es wirklich starten.
- IE öffnen
- https://mail.sichel.com/OWA eingetragen
- Ich werde umgeleitet auf: https://adfs.sichel.com
- Melde mich dort an –> es klappt :) Wo bin ich? Richtig: Outlook Web App, erneute Authentifizierung, warum? Dazu gleich mehr…
- Also Authentifiziere ich mich am Outlook Web App (Adressleiste beachten, ich bin nun auf https://mail.sichel.com/OWA
- Erfolgreich, ich kann arbeiten :)
Test 1 abgeschlossen. Kommen wir zum letzten Schritt.
Schritt 10 – Authentifizierung übergeben
Wie beim TMG auch authentifiziere ich mich nun am AD FS, und dieser sollte meine Kennung an den Exchange weitergeben. Das klappt aber nur solange wie der Exchange auf Standardauthentifizierung konfiguriert ist. Nach einer Standardinstallation von Exchange 2010 / 2013 ist dies allerdings nicht der Fall, da steht die OWA & ECP auf Formularbasierender Authentifizierung.
- An Exchange ECP anmelden
- Server –> Virtuelle Verzeichnisse
- OWA auswählen und bearbeiten
- Authentifizierung –> Auf Standard stellen (Bild 10)
Dem zufolge muss ich, wenn ich ein SSO implementieren will, die Authentifizierung am Exchange auf Standardauthentifizierung ändern.
Anschließend nach der Änderung, die Internetinformationsdienste neu starten und erneut versuchen anzumelden.
Jetzt klappt’s auch mit dem Nachbarn oder wie man so schön sagt:
- https://mail.sichel.com/OWA –> (Bild 11)
- Umleitung auf https://adfs.sichel.com/ –>
- Authentifizieren –> Umleitung zu https://mail.sichel.com/OWA –>
- Angemeldet :) (Bild 12)
Das waren 10 Schritte zum Konfigurieren des neuen Rollendienst „Webanwendungsproxy“ in zusammenarbeit mit Exchange Server 2013. Ich hoffe ich habe damit geholfen Web Application Proxy einzusetzen.
Wie üblich folgen alle Bilder nochmal in der Übersicht:
-
- DNS Einstellungen
-
- Anforderung des Zertifikats auf der Website der Internen CA
-
- AD FS Informationen
-
- ADSI-Editor von Proxy
-
- Delegierungsoptionen
-
- Veröffentlichen, Schritt 1
-
- Veröffentlichen, Schritt 2
-
- Veröffentlichen, Schritt 3
-
- Virtuelles Verzeichnis in Exchange Konfigurieren
-
- Anmeldung an AD FS
-
- Angemeldet am Postfach
Viel Erfolg :)
Hallo,
ich hab gerade in unserer Testsumgebung (Server 2012R2 und Exchange 2013) versucht diese Anleitung hier durchzumachen, scheitere jedoch an Punkt 6.
Ich hab das *.pfx-Wildcard-Zertifikat am ADFS und am WAP importiert unter lokaler Benutzer – Eigene Zertifikate.
Im Asistenten hab ich den Namen des verbunddienstes richtig angeben und den Domänen-Admin als User.
Als AD FS-Proxy Zertifikat kann ich dann auch das Wildcard-Zertifikat auswählen.
Gehe ich nun auf konfigurieren schlägt die Verbindung mit folgendem Fehler:
Fehler beim Herstellen einer Vertrauensstellung mit dem Verbunddienst. Fehler:Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine vertrauensstellung hergestellt werden.
Woran kann das liegen? Der WAP ist bei mir nicht in der Domäne, evtl daran?
Hallo
Nur mal eine kurze Rückfrage zu den veröffentlichen Seiten vom Proxy
Das sind 7 Regeln, zu 2 eine kurze Frage:
Autodiscover.sichel.com/autodiscover und mail.sicher.com/autodiscover
Wofür die sind…..begriffen. Aber als was hast du im externen DNS eingetragen? Als „normale“ Einträge oder als srv Einträge? Ich frage nur, weil ich autodiscover extern eigentlich eher als srv Eintrag setzen.
Ich soweit den Nachbau jetzt fertig und auch eine Möglichkeit das „echt“ zu testen. Also mit Firewall und entsprechenden externen DNS Einträgen.
Gruß aus HH
Lutz
Danke für die schnelle Antwort – klingt gut. Da werde ich nach dem Fehler suchen. Da ich TMG nicht kenne, (wir haben Exchange bisher nicht veröffentlicht) weißt Du noch, an welcher Stelle ungefähr das konfiguriert wurde?
Hey Kai,
Nein tut mir leid, aber Google von nebenan weiß das bestimmt ?
Hast du denn Exchange für ADFS Ansprüche eingerichtet?
Mit der nächsten ADFS Version kommen auch nochmal einige Neuigkeiten ?
Hallo!
Mich würde bei Euren Konfigurationen sehr interessieren, wie es mit der Abmeldung vom OWA bei Pre-auth am Proxy aussieht. Funktioniert sie sauber (ohne den Browser komplett zu schließen) oder bekommt man das Aufforderungsfenster „…Browser schließen…“, weil man sonst durch Betätigen des „zurück“-Buttons oder Aufruf von https://server/owa in einem neuen Tab sofort wieder ohne Authentifizierung in der alten Sitzung landet? Ich arbeite hier mit der Sophos UTM als Reverse-Proxy. Dort tritt das Problem bei eingeschaltetem Pre-Auth so auf. Intern hat der Kollege die (obige) Konfiguration mit WAP und ADFS getestet – gleiches Verhalten. Exchange haben wir 2013 mit akt. CU.
Gruß!
Kai
Hallo Kai,
in meiner Konfiguration werde ich ordnungsgemäß abgemeldet. Wenn Du einmal hier schaust: https://asichel.de/2014/04/19/exchange-2013-sp1-und-adfs-claims/ im Schritt 5.
Ist der Exchange auch für ADFS-Authentifizierung konfiguriert klappt auch die Abmeldung sauber.
Im TMG musste man früher mitgeben „/owa?logoff=true“ (Wenn ich mich richtig erinnere). Check das doch mal in deiner UTM!
Andi
Hallo,
vielen Dank für den tollen Artikel. Wir haben auch einen WAP-Server im Einsatz, den wir für Exchange Active Sync (EAS) einsetzen wollen. Wenn ich das bisher richtig verstanden habe, dann muss ActiveSync auch mit Pass-Through konfiguriert werden, da keine PreAuthentication unterstützt wird.
Die Exchange Active Sync Anmeldung soll mittels Certificate-Base-Authentication (EAS-CBA) realisiert werden. Im internen LAN funktioniert das auch einwandfrei. Die externen Anfragen, welche über den WAP und dann an den Loadbalancer laufen und letztendlich an den Exchange Server 2013 zugestellt werden, erhalten eine 403.7 Fehlermeldung. Die veröffentlichte Web Applikation auf dem WAP ist wie folgt konfiguriert:
Name: Exchange-EAS
External URL: https://owa.externedomäne.de/microsoft-server-activesync
Backend Server URL: https://owa.externedomäne.de/microsoft-server-activesync
Preauthentication: PASS-THROUGH
Der WAP-Server leitet die Anfrage dann an den Exchange-CAS über den Loadbalancer. Die Anfrage ist auch sichtbar auf dem Exchange-CAS, aber mit 403.7 abgewiesen.
Ich wäre über jeden Hinweis und Tipp dankbar.
Hallo Thorsten,
danke :)
Ich vermute mal da passt was mit dem Zertifikat nicht:
https://support.microsoft.com/de-de/kb/186812 & http://blogs.msdn.com/b/friis/archive/2011/11/15/troubleshooting-403-7-client-certificate-required-errors-amp-step-by-step-to-make-sure-your-client-certificate-is-displayed-and-selected.aspx
Da der WAP nur „durchleitet“ und die Authentifizierung direkt am Exchange geprüft wird, würde ich den WAP mal außen vor lassen!
Internal & external Authentication müssen nicht identisch sein, Intern erhält du vermutlich auch eine IP / DNS usw. vom DC?
Was ist mit den Sperrlisten? CRL / CDP korrekt eingerichtet?
Andi
Hallo Andi,
bei den Zertifikaten bin ich mir sicher, dass es korrekt konfiguriert ist und die Zertifiaktskette auf den beteiligten Servern stimmt. Prüfe ich aber auch noch einmal nach, insbesondere das Clientzertifikat.
Das ist korrekt, intern habe ich einen DC mit installiertem DNS, der sich um die IP und Namensauflösung kümmert. Die Sperrlisten sind erreichbar und korrekt definiert.
Habe jetzt eben noch eine andere Aussage bekommen: „Activesync mit Zertifikaten geht mit WAP derzeit leider nicht. Problem an der Sache ist, dass der WAP das Zertifikat nicht an den Exchange weiterleiten kann.“ Soll sich wohl mit 2016 ändern.
Wenn das so ist erklärt das meine Situation. Oder kannst Du die Aussage widerlegen bzw. kennst Du eine Installation mit zertifikatbasierter ActiveSync Authentifizierung mittels WAP?
Hi,
okay! Ich selber werde mir mal eine entsprechende Umgebung aufbauen und hier Bloggen ;) Was ist wenn du EAS bei „ExternalPreAuthentication“ auf „ClientCertificate“ im WAP umstellst?
Hey,
vielen Dank, das wäre Interessant was bei Deiner Umgebung herauskommt. Werde das mit der vorgeschlagenen WAP-Konfiguration einmal testen und ebenfalls hier das Ergebnis mitteilen.
Die Konfiguration habe ich mal für EAS auf ClientCertificate umgestellt (-ExternalPreAuthentication ClientCertificate). Funktioniert leider auch nicht. Denke wir werden auf den Windows Server 2016 warten müssen, oder einen Exchange Edge implementieren.
Hallo Thorsten,
das musste ich in meinen Tests leider auch feststellen. Wie hast Du es mit ActiveSync und Zertifikaten ohne WAP implementiert? Das Problem ist das die Authentifizierung nicht weitergereicht werden kann, der Server Antwort immer mit „HTTP/1.1 GET / 404 – NotFound -„. Sprich die Anforderung an den Exchange (bei mir 2016) funktioniert nicht.
Lasse ich den WAP Außen vor, erhalte ich eine Funktionstüchtige EAS Verbindung. Das Zuvor auf das iPhone aufgespielte Profil funktioniert also tadellos :)
Meine Idee wäre nun, eine ADFS-Authentifizierung mit Hilfe eines Clientzertifikates zu erstellen, was natürlich nicht Funktioniert, da der EAS keine Windows-Authentifizierung akzeptiert, sondre nur Standard.
Abhilfe könnte in der Tat Server 2016 mit dem neuem Veröffentlichungsprofil sein.
Derzeit habe ich leider noch keine Lösung, den bisher angefertigten Artikel lasse ich mal in der „Pipe“ bis 2016 auf dem Markt ist ;)
Solltest Du inzwischen eine Möglichkeit gefunden haben, melde Dich doch bitte !
LG
Hallo Andi,
also ohne WAP habe ich es nur zum Laufen bekommen als ich vom internen LAN direkt auf den Exchange Server 2013 drauf bin. Von extern hatte ich bisher nur die Möglichkeit über den WAP mit Pass-Through zum Exchange-Server zu gelangen und hier war immer auf dem Exchange mit der 403.7 Fehlermeldung Ende im Gelände.
Wir haben jetzt für ActiveSync einen Kemp Loadmaster anstelle des WAP-Server in der DMZ implementiert und hier die Reverse-Proxy Funktion benutzt … und siehe da es funktioniert =). Der Kemp Loadmaster reicht die EAS-Anfrage samt Clientzertifikat an den Exchange-Server weiter und gibt grünes Licht. Also kann der aktuelle WAP-Server auf Basis von Windows Server 2012 R2 keine EAS Clientzertifikat Authentifizierung verarbeiten. Ist in der Tat spannend, ob der WAP-Server auf Basis von Windows Server 2016 diese Funktionalität für die Zukunft mitbringt.
Abend,
gute Wahl ;) Ja das ADFS & Pass Through! Entschuldige ich bin auch erst später darauf gekommen!
Wie hast du es Exchange-Seitig gelöst? Verwendest Du eine MDM-Lösung (Intunes, AirWatch, BB o.ä.) für die Zertifikats- / Profilverteilung? Welche Endgeräte sind im Einsatz?
Ich habe eine lauffähige Konfiguration mit Hilfe des iPhone Configuration Utility und Profilverteilung über IIS getestet. Kein MDM-Server im Einsatz, ist ja auch nur eine Testumgebung ;) !
Andi
Guten!
Kein Problem. Hinterher ist man immer schlauer und man lernt vor allem dazu. Der WAP ist ja eigentlich auch dafür gedacht gewisse Funktionen wegen der Abkündigung von ISA/TMG wie Reverse-Proxy zu übernehmen. Würde ja auch funktionieren, wenn die zertifikatsbasierte Anmeldung nicht ins Spiel kommt. Der WAP wird in Zukunft sicherlich mit diesem und um weitere Features wachsen.
Auf Exchange Seite habe ich für den Server und auf dem virtuellen Directory „Microsoft-Server-ActiveSync“ die zertifikatsbasierte Authentifizierung aktiviert, wie hier beschrieben: http://blogs.technet.com/b/exchange/archive/2012/11/28/configure-certificate-based-authentication-for-exchange-activesync.aspx
Für die Zertifikats- / Profilverteilung kommt die MDM-Lösung „Silverback by Matrix24“ zum Einsatz. Die Endgeräte sind Windows Phones, iPhones/iPads, Android, Surface 3 (ActiveSync über die Windows 10 Mail-App).
Vielen Dank für Deine Hilfe und den Austausch
Guten Tag und vielen Dank für die Tutorials.
Dieses hat bei mir soweit geklappt. ADFS und Web App Proxy ist eingerichtet und Test 9 läuft erfolgreich.
Führe ich allerdings die unter 10 aufgeführten Schritte aus, so klappt zwar die Anmeldung an domain.tld/OWA automatisch nach der Authentifizeirung durch den AD FS, allerdings funktioniert die Anmeldung an der ECP Seite nun überhaupt nicht mehr. (auch nicht vom host aus)
Nach Eingabe der Daten am AD FS Service werde ich umgeleitet und der Fehlercode 400 erscheint.
Erst eine Umstellung via ExchangeShell mittels Set-EcpVirtualDirectory auf FormsAuthentifizierung machte eine erneute Anmeldung an der ECP Seite möglich.
Woran könnte dies liegen?
In einem anderen Toturial habe gesehen, dass die Seite „mail.domain.tld/OWA“ && „/ecp“ im AD FS unter „Vertrauensstellung der vertrauenden Seite“ aufgeführt werden. Hat dies einen Zusammenhang mit o.g. Problematik?
Bild: https://asichel.de/wp-content/uploads/2014/06/12-Vertrauensstellung-in-ADFS-150×150.jpg
Vielen Dank für Ihre Mühen
Markus
Hi,
die Änderung der Authentifizierung muss für OWA & ECP geschehen.
Andi
Hi,
die Änderung habe ich für beide durchgeführt.
Ok, ich musste die Umstellung für ECP via Shell vornehmen.
Über das Webinterface wurden die Änderung nicht übernommen, jedoch als geändert angezeigt.
Vielen Dank nochmal für deine Arbeit.
Beste Grüße Markus
Hallo Markus,
funktioniert es also?
Andi
Ja funktioniert alles einwandfrei.
Jetzt geht’s an die Einrichtung der Workfolders.
Super Blog, nochmals großes Lob.
Beste Grüße Markus
Viel Erfolg :)
und Danke nochmal!
Andi
Hi,
muss das Verzeichnis ECP denn unbedingt veröffentlicht werden?Persönlich würde ich das gerne vermeiden oder ist dann mit Fehlern zu rechnen?
Hallo Andi,
erstmal ein großes Dankeschön für die Arbeit die du hier leistest.
Hab ein kleines Problem mit dem ADFS und WAP.
Es funktioniert soweit alles, aber wenn ich auf meinen Exchange von Extern zugreifen will ich direkt auf die OWA komme. Ich bekomme nicht die Anmeldeseite vom ADFS.
Laut MS-Seiten (TechNet und Co) passt aber alles.
Hast du eine Idee was der Fehler sein könnte.
Danke im Vorhinein
LG
Martin
Hallo Martin,
danke für das Lob :)
Ich verstehe dich richtig, Du erhältst beim Zugriff von extern direkt die OWA Anmeldeseite und nicht die ADFS-Anmeldeseite?
Ist die Veröffentlichung im WAP auf ADFS oder auf PassThrouhg? Ist das Virtuelle Verzeichnis von OWA korrekt eingestellt? Verweist eventuell eine FW-Richtlinie noch direkt auf den Exchange?
Eventuell helfen Dir die Fragen zur Lösung ;)
Andi
Hallo,
Danke für die schnelle Antwort.
Ja du verstehst mich richtig,
Am WAP ist für den Exchange Server /owa und /ECP auf AD FS.
von Extern ist auf der FW nur 80 und 443 auf den WAP weitergeleitet sonst nichts.
Owa ist auch so konfiguriert wie in deiner Anleitung.
LG
Martin
Hi,
klingt komisch ?!? Eine Externen-DNS Eintrag für die ADFS-Adresse ist vorhanden? Meisten sind zwei Fehlerquellen vorhanden: DNS & Zertifikate, ist in einem eine Unstimmigkeit vorhanden kippt die ganze Maschinerie…
Andi
Hallo,
Externer DNS-Eintrag ist vorhanden.
Zertifikate hab ich wie in deiner Anleitung für den WAP und ADFS gemacht.
Am Exchange hab ich ein SAN von einer öffentlichen Zertifizierungsstelle.
Danke für den Support, ich werde einmal den ADFS und WAP neu konfigurieren.
Ich hoffe das nicht mein 2012r2 mit Essentials Experience als Serverrolle da reinpfuscht.
LG
Martin
Guten Morgen Martin,
hast Du unterschiedliche Server verwendet, oder die Rolle WAP auf dem Exchange zu installiert?
Andi
Hallo Andi,
als erstes Ich kann auf deinen Letzten Post nicht antworten, darum hier.
Entschuldige meine späte Antwort.
Nein ich habe alles auf seperaten Server installiert.
Mittlerweile habe es jetzt ins laufen gebracht.
Habe ADFS und WAP neuinstalliert was dann auch nicht funktionierte :-(
Mit deiner Anleitung (Exchange 2013 SP1 und ADFS Authentifizierung) die ich jetzt auch umgesetzt habe, funktioniert es jetzt. und das auch mit Exchange 2016 :-)
Danke für deine Hilfe.
LG
Martin
Hallo
Nacgebaut…..
Folgndes Problm: Ichmele mich m ADF an (er merkt auch, falls ich ein falsches PW engebe) dann aber erhalte ich einen Fehler:
•Activity ID: 6aae8325-986c-0001-f086-ae6a6c98d001
•Relying party: Skynet IT Exchange Server
•Error time: Wed, 27 May 2015 17:43:29 GMT
•Cookie: enabled
•User agent string: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C)
Lokal am Exchange kann ich OWA starten, d.h. die Funktion selbst geht
Eine Idee?
Im Log habe ich als Fehler 342 und 364
Sowie als Warnung 1000 (Fehler beim Verarbeiten einer Tokenanforderung. Die Daten in diesem Ereignis weisen möglicherweise die Identität des Aufrufers (der Anwendung) auf, der diese Anforderung gestellt hat. Die Daten enthalten eine Activity ID, die als Referenz für Fehler- oder Warnereignisse verwendet werden kann, um die Problemdiagnose für diesen Fehler zu erleichtern.
Hi Lutz,
ich tippe mal auf DNS. Es scheint das irgendwo ein fehlerhaftes Ziel aufgelöst wird.
Andi
Hi Andi
Folgende Fragen:
In einem Blog habe ich gefunden, dass in der „externen“ DNS Zone (interner DNS Server) für mail und adfs die interne IP Adresse vom Proxy genommen wird. Bei dir ist es der Exchange und ADFS Server.???
Kann man die Konfiguration eigentlich auch von „innen“ testen? Oder geht nur ein (simulierter oder echter) Zugriff von außen?
Was bedeutet bzgl Import des Root Zertifikats: „natürlich mit OID für EV“
Die OID hab ich gespeichert….und dann? :-)
Für „echt“, welcher Server kommt in die DMZ? Der Proxy? und/oder auch der ADFS?
Welche Ports müssen dann in´s interne Netz geöffnet werden?
(viele Fragen, ich weiß)
Viele Grüße
Lutz
HI,
ich habe eine Primäre DNS Zone für meine externe Domäne erstellt, diese enthält die Internen IPs vom Mail & ADFS Server (Siehe Schritt 1.4, Bild 2) – Klärt auch die zweite Frage (von innen) … :)
Das ist die Eindeutige Kennung für die erweiterte Überprüfung. Siehe Beitrag AD CS EV: https://asichel.de/2013/06/14/active-directory-zertifikatsdienste-ad-cs-extended-validation/
In die DMZ, der Proxy! Dieser ist AD-Mitglied, also Kerberos, DNS, HTTPS, ICMP in das Interne Netz veröffentlichen / freigeben!
Andi
Hallo Andi,
erst eimal, toller Blogbeitrag, danke dafür.
ich habe die Situation, dass ich von extern nur über eine Subdomain auf das Firmennetzwerk zugreifen kann, wäre die Konfiguration dennoch denkbar?
Bspw. portal.sichel.com.
Wenn ich intern in der Zone sichel.com den A-Record auf den ADFS zeigen lasse und extern eine 443-Weiterleitung auf den WAP einrichte, wäre das so machbar? Wenn ich Deinen Post richtig verstanden habe hast Du auch keinen direkten Zugriff auf ADFS von außen sondern alles wird über den WAP geleitet, oder?
Extern zeigt dann portal.sichel.com auf den WAP, intern auf ADFS… Könnte ich dann auf WAP und ADFS mit demselben Zertifikat (nicht Wildcard sondern portal.sichel.com) arbeiten. Für Feedback wäre ich dankbar!
Gruß,
Thomas
Hallo Tom,
Danke :)
Du brauchst aber einen öffentlichen Hostnamen für ADFS, dieser verweist dann aber auf den WAP (öffentlich erreichbar) und nicht auf den ADFS, darum kümmert sich der WAP-Server.
Möchtest Du kein Wildcard Zertifikat verwenden empfehle ich die Verwendung eines SAN-Zertifikats.
Hoffe das hilft,
Andi
Hallo. Geniale Anleitung,
ich Kämpfe leider auch mit ActiveSync.
OWA Funjtioniert.
iPhone Funktioniert.
Outlook über https (RPC) leider nicht!
hast du eine Idee woran das liegen könnte?
Hallo Kai,
das kann verschiedene Ursachen haben. EAS geht nur mit dem iPhone / Windows Phone? Welchen Outlook Client versuchst du auf welchem Windows System?
Andi
Hallo,
ich versuche es mit Outlook 2013 unter Windows 8.
Mit dem iPhone funktioniert es.
Hi Kai,
hast du die RPC- auf PassThrough Verbindung eingerichtet?
hast du bereits SP1 von Ex 2013 und Office 2013 installiert? Dann kannst du auch MAPI verwenden:
https://asichel.de/2014/03/07/exchange-2013-sp1-mapi-over-http-mit-wap/
Andi
Hallo. Super Anleitung..danke viel mals. Ich kämpfe jedoch noch mit dem Exchange Active Sync. Kriege den irgendwie nicht durch. Ich habe die Weburl published und auf Passtrough gestellt. Bei deinen Printscreens konnte ich die Regel nicht finden. Muss ich da was spezielles beachten?
Gruss Mathias
Hallo Mathias,
mit welchem Endgerät versuchst Du dich zu verbinden? Android, Windows Phone oder iOS?
Andi
[…] Post setzt auf folgenden Post auf: Server 2012 R2: Webanwendungsproxy mit Exchange 2013. Exchange muss nicht dafür konfiguriert werden, es geht ausschließlich um ADFS und […]
[…] Server 2012 R2: Webanwendungsproxy mit Exchange 2013 […]
Ich habe jetzt doch noch eine Frage (Problem)
Im DNS Server (202R2) habe ich eine Forward Lookupzone mit dem „externen“ Namen angelegt. da habe ich 2x A Record mit dem Exchange (Webmail) und dem ADFS mit den 2 internen IPs eingetragen.
Mache ich ein Ping auf adfs. tcp-express.de komme ich ein „Host nicht gefunden“ zurück. Daher geht jetzt wohl auch Schritt 6.4.4 nicht (er findet den Server nicht) Eine Idee, warum der DNS nicht will? (In der IPv4 Konfig ist er eingetragen, weiterletingen existieren nicht)
Viele Grüße
Lutz Rahe
Hi,
ist es von „außen“ der Host nicht erreichbar? Wie genau ist Deine DNS-Konfiguration aufgebaut? Kannst Du mir auch per Mail schicken.
Andi
[…] die Native Unterstützung für ADFS mitgekommen. Im vergangenem Beitrag habe ich bereits über die Veröffentlichung von Exchange 2013 mit WAP berichtet und versprochen diesen Artikel Zeitnah zu […]
Hallo
Ich scheitere leider schon an Schritt 5
Das Zertifikat aus Schritt 2 wird mir nicht angeboten. Auch kann ich nur eine neu importieren (pfx Datei)
Die habe ich aber nicht, da ich unter Schritt 2 (neues Webzertifikat) den haken bei „privaten Schlüssel exportierbar“ nicht setzen kann (ausgegraut)
Für einen Hinweis wäre ich sehr dankbar
(liegt es an der Zertifikatsvorlage? Ich habe (im Gegensatz zum Screenshot) ja keine eigene Vorlage, sondern nur die Webserver Vorlage)
Gruß
Lutz
Hallo,
wie schon richtig vermutet liegt es an der Zertifikatsvorlage. Es muss eine Vorlage sein in der „Privater Schlüssel Exportierbar“ aktiviert ist.
Andi
Hrgn :-)
Wie lege ich denn eine eigene Vorlage an?
Schau mal hier:
https://asichel.de/active-directory-zertifikatsdienste-ad-cs-extended-validation/
Andi
Werde ich versuchen :-)
als 2003 Ent. oder 2008 Ent.?
(das ist gleich die erste frage nach „Doppelte Vorlage“
Das sind die Zertifikatsvorlagentypen, schau mal hier:
http://technet.microsoft.com/de-de/library/cc725838.aspx
ok
und welcher Typ ist es dann?
Ich hab jetzt 2003 Enterprise versucht
aber unter Neues Zertifikat anfordern, erweitert…., wird mir die eigene Vorlage nicht angeboten
Die Vorlage muss vorher veröffentlicht werden: 15.In der Zertifizierungsstelle –> Rechtsklick auf Zertifikatsvorlagen –> Alle Aufgaben –> Neu –> Auszustellende Zertifikatsvorlage.
Herzlichen Dank
Jetzt ist sie da
(damit ist mein freier Tag ruiniert :- )
Schöne Ostern
eine Frage hab ich noch (erstmal)
die Möglichkeit Zertifikatsvorlagen zu doppeln….war ja „früher“ nur in der Enterprise Serveredition verfügbar. Die gibt es ja bei > 2012 nicht mehr. Geht das dort dann nur in der Datacenter? Denn bei Standard (Testserver) taucht dieser Menüpunkt nicht auf.
Gruß aus HH
Lutz
gefunden
war mein Fehler
(unter der MMC – Zertifikatsvorlagen – Webserver – da kann ich die Vorlage duplizieren)
[…] beschäftigen. Meine Testumgebung für den Exchange Server 2013 habe ich bereits im Artikel “Server 2012 R2: Webanwendungsproxy mit Exchange 2013” aufgebaut. Diese möchte ich nun um das neue Feature MAPI over HTTP […]
Hi!
thx for this great tutorial. Fantastic description of every single step. My problem is that I always get error 511 and 364 when logging in. When I open owa my ADFS-Screen always shows an error page. I did not find a lot of info on the internet. All I found did not help me to solve my problems. Maybe you can give some advices.
Thx Chris