Ich habe ja mal hier beschrieben wie man einen NGNIX-ReverseProxy für EAS (Exchange ActiveSync) und OWA (OutlookWebApp) konfiguriert.
Mit Exchange 2013 wurde MAPI over HTTP eingeführt und spätestens mit Exchange 2016 wird dieses Protokoll für die Verbindung mit Outlook verwendet. Mit wenig Aufwand kann man jetzt den NGINX auch dafür verwenden um externe Outlooks anzubinden – egal ob Outlook 2010, 2013 und auch das neue Outlook 2016.
Damit das sauber – auch über Autodiscover (wichtig für Outlook 2016) – funktioniert sind folgende Vorarbeiten zu beachten:
1) Autodiscover konfigurieren
Ich empfehle die URLs der Virtuellen Verzeichnisse und von Autodiscover auf einen DNS-Namen zu setzten der intern und extern auflösbar ist – z.B. outlook.domain.de und autodiscover.domain.de.
Die URLs am Exchange kann man folgendermaßen am Exchange über die Exchange Management Shell konfigurieren:
Set-OWAVirtualDirectory –Identity „OWA (default web site)“ -ExternalURL „https://outlook.domain.de/OWA“
Set-OWAVirtualDirectory –Identity „OWA (default web site)“ -InternalURL „https://outlook.domain.de/OWA“
Set-OABVirtualDirectory –Identity „OAB (default web site)“ -ExternalURL „https://outlook.domain.de/OAB“
Set-OABVirtualDirectory –Identity „OAB (default web site)“ -InternalURL „https://outlook.domain.de/OAB“
Set-ECPVirtualDirectory –Identity „ECP (default web site)“ -ExternalURL „https://outlook.domain.de/ECP“
Set-ECPVirtualDirectory –Identity „ECP (default web site)“ -InternalURL „https://outlook.domain.de/ECP“
Set-WebServicesVirtualDirectory –Identity „EWS (default web site)“ -ExternalUrl „https://outlook.domain.de/ews/exchange.asmx“
Set-WebServicesVirtualDirectory –Identity „EWS (default web site)“ -InternalUrl „https://outlook.domain.de/ews/exchange.asmx“
Set-ActiveSyncVirtualDirectory –Identity „Microsoft-Server-ActiveSync (default web site)“ -ExternalURL „https://outlook.domain.de/Microsoft-Server-ActiveSync“
Set-ActiveSyncVirtualDirectory –Identity „Microsoft-Server-ActiveSync (default web site)“ -InternalURL https://outlook.domain.de/Microsoft-Server-ActiveSync
Set-ClientAccessServer -AutoDiscoverServiceInternalUri „https://autodiscover.domain.de/Autodiscover/Autodiscover.xml“
Im Zertifikat des Exchanges müssen natürlich auch diese beiden DNS-Namen stehen – in diesem Beispiel also outlook.domain.de und autodiscover.domain.de.
Im internen DNS und im externen DNS müssen die beiden DNS-Namen strong>outlook.domain.de und autodiscover.domain.de eingetragen werden – im internen DNS direkt auf euren Exchange-Server und im externen auf die öffentliche IP des ReverseProxys.
2) IIS am Exchange konfigurieren
Damit über den ReverseProxy z.B. auch der Abwesenheitsassistent (Out of Office) und die E-Mail-Infos funktionieren, muss am IIS des Exchanges im EWS und im MAPI die Standardauthentifizierung aktiviert werden:
3) NGINX-Konfig
Die Grundinstallation ist ja schon hier beschreiben.
Für mein Beispiel muss das Zertifikat für den NGINX muss outlook.domain.de und autodiscover.domain.de enthalten. Der interne Exchange ist hier im Beispiel der exch2016.test.local.
Hier ist dann die Konfig für den ReverseProxy:
#Abschnitt 1
server {
listen 80;
server_name outlook.domain.de autodiscover.domain.de;
# Redirect any HTTP request to HTTPS
return 301 https://$server_name$request_uri;
error_log /var/log/nginx/exchange-error.log;
access_log /var/log/nginx/exchange-access.log;
}
#Abschnitt 2
server {
listen 443;
server_name outlook.domain.de autodiscover.domain.de;
# Enable SSL
ssl on;
ssl_certificate /etc/nginx/certs/cert.crt;
ssl_certificate_key /etc/nginx/certs/cert.key;
ssl_session_timeout 5m;
# Set global proxy settings
proxy_read_timeout 360;
proxy_http_version 1.1;
proxy_pass_request_headers on;
proxy_pass_header Date;
proxy_pass_header Server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Accept-Encoding "";
more_set_input_headers 'Authorization: $http_authorization';
proxy_set_header Accept-Encoding "";
more_set_headers -s 401 'WWW-Authenticate: Basic realm="exch2016.test.local"';
location /owa { proxy_pass https://exch2016.test.local/owa; }
location /OWA { proxy_pass https://exch2016.test.local/owa; }
location /EWS { proxy_pass https://exch2016.test.local/EWS; }
location /ews { proxy_pass https://exch2016.test.local/EWS; }
location /Microsoft-Server-ActiveSync { proxy_pass https://exch2016.test.local/Microsoft-Server-ActiveSync; }
location /mapi { proxy_pass https://exch2016.test.local/mapi; }
location /MAPI { proxy_pass https://exch2016.test.local/mapi; }
location /rpc { proxy_pass https://exch2016.test.local/Rpc; }
location /RPC { proxy_pass https://exch2016.test.local/Rpc; }
location /oab { proxy_pass https://exch2016.test.local/OAB; }
location /OAB { proxy_pass https://exch2016.test.local/OAB; }
location /autodiscover { proxy_pass https://exch2016.test.local/Autodiscover; }
location /Autodiscover { proxy_pass https://exch2016.test.local/Autodiscover; }
error_log /var/log/nginx/exchange-ssl-error.log;
access_log /var/log/nginx/exchange-ssl-access.log;
}
Damit hab ich ein Outlook 2016 an einen Exchange 2016 angebunden. Alles funktioniert – auch der Abwesenheitsassistent 🙂
Hilfreiche Quellen:
FrankysWeb
blog.kempkens.io
Super Beitrag von dir. Habe bei mir selbst einen Exchange 2016 aufgesetzt unter Server 2016 und gestern soweit alles konfiguriert, damit das schon mal intern läuft inkl. LetsEncrypt Zertifikat und POPCon Connector und CatchAllMailbox.
Da ich schon einen NGinx als Reverseproxy für meine Webseiten am laufen habe, habe ich dank dir jetzt auch meinen Exchange von außen erreichbar. Es hat soweit alles funktioniert, habe aber bisher nur kurz OWA Aufruf getestet.
Eine Sache aber ging nicht:
more_set_input_headers ‚Authorization: $http_authorization‘;
more_set_headers -s 401 ‚WWW-Authenticate: Basic realm=“exch2016.test.local“‚;
akzeptierte mein Nginx nicht? Habe Version 1.11.8 unter Debian 8 laufen.
Habs einfach auskommentiert aber weiß nicht wofür die Einträge waren oder wie man sie anders schreiben müsste?
Hi, die Einträge sind für das MAPIoverHTTP wichtig – wenn du das nicht brauchst dann kannst du auch nur https://blog.friedlandreas.net/2013/07/reverseproxy-fur-eas-exchange-activesync-und-owa-outlookwebapp-mit-nginx/ befolgen..
Funktionieren müsste es auch mit der aktuellsten Version – wenn ich die Woche mal dazu komme kann ich das mal kurz testen 🙂
Hallo schaloml,
ich habe zumindest herausgefunden was mir bei nginx gefehlt hat, es war das nginx-extras Paket, das benötigt wird damit die more_set Einträge angenommen werden.
Aber leider habe ich jetzt noch ein anderes Problem.
bei https://testconnectivity.microsoft.com habe ich alle Tests ausgeführt:
– Exchange ActiveSync (alles bestens und ok)
– Exchange ActiveSync Autodiscover (alles bestens und ok), ich musste aber dein /location autodiscover in Autodiscover ändern, großes A!
– Outlook Connectivity (leider Fehler.. 🙁
– Outlook Autodiscover (alles bestens und ok)
Fehler:
https://mm-vault.de/chevereto/image/74W
Hast du eine Idee? Oder kannst du das mal testen ob es bei dir geht?
So, ich glaube ich habe es jetzt geschafft. Zwei Probleme hatte ich noch, die jetzt scheinbar gelöst sind. Ich schreibe sie hier falls jemand nach einer gleichen Lösung sucht.
Problem 1: Outlook Connectivity Test läuft auf Fehler
Lösung 1: Oben ist beschrieben, dass für EWS im IIS die Standardauthentifizierung aktiviert werden muss. Dies habe ich auch für MAPI getan und schon läuft der Test erfolgreich durch!
Problem 2: Keine Verbindung von extern über Outlook inkl. Autodiscover möglich. Am IPhone hingegen hat es funktioniert.
Lösung 2: im NGINX sämtliche Pfade, also z.B. location /owa { proxy_pass https://exch2016.test.local/owa; } in klein owa und groß OWA angeben. Das gleiche für ews/EWS, mapi/MAPI, rpc/RPC, oab/OAB und Autodiscover/autodiscover. Danach konnte ich von extern eine Verbindung über Outlook 2013/2016 über MAPI HTTP Protokoll aufbauen, es würde schön per Autodiscover verschlüsselte Verbindung gefunden. Sehr nice!
Hoffe jemandem bringt das was falls er ebenfalls noch an einer Lösung arbeitet.
Klasse – ich passe die Anleitung an 🙂
Super, sieht bei mir aber so aus:
location /OWA { proxy_pass https://exch2016.test.local/OWA; }
also vorne und hinten immer identisch klein/groß.
Und bei dem rcp hast du hinten auch ein großes R.
bei mir:
location /rpc { proxy_pass https://exch2016.test.local/rpc; }
location /RPC { proxy_pass https://exch2016.test.local/RPC; }
Das sollte eigentlich egal sein – ich teste es aber die nächsten Tage und passe es dann an 😊
Echt super Anleitung!
Ein kleines Problem tritt dennoch bei mir auf, was ich mir einfach nicht erklären kann.
Habe den Exchange 2016 gestern mit CU4 installiert und es geht im Prinzip alles. (OWA, Outlook mit Mapi)
Nur irgendwie möchte das RPC nicht richtig, gestern Abend wurde beim Connectivity Test noch „unzulässige Methode“ beim RPC Ping angezeigt, jetzt wird folgendes gefunden.
Attempting to ping RPC proxy mail.tc-systeme.com.
RPC Proxy can’t be pinged.
Additional Details
An unexpected network-level exception was encountered. Exception details:
Message: Der Remoteserver hat einen Fehler zurückgegeben: (440) Login Timeout.
Type: Microsoft.Exchange.Tools.ExRca.Extensions.MapiTransportException
Der NGINX schreibt dazu nichts im Error-Log und das steht im Access-Log
13.67.59.89 – – [15/Feb/2017:11:35:45 +0100] „RPC_IN_DATA /rpc/rpcproxy.dll HTTP/1.1“ 401 0 „-“ „MSRPC“
13.67.59.89 – – [15/Feb/2017:11:35:46 +0100] „RPC_IN_DATA /rpc/rpcproxy.dll?517ee2d6-290d-4cf1-920e-3d72eb58fe46@MAIL.com:6002 HTTP/1.1“ 401 0 „-“ „MSRPC“
13.67.59.89 – – [15/Feb/2017:11:35:46 +0100] „RPC_IN_DATA /Rpc/RpcProxy.dll?517ee2d6-290d-4cf1-920e-3d72eb58fe46@MAIL.com:6001 HTTP/1.1“ 301 178 „-“ „MSRPC“
13.67.59.89 – – [15/Feb/2017:11:35:46 +0100] „RPC_IN_DATA /owa HTTP/1.1“ 440 43 „-“ „MSRPC“
Der Exchange begründet die 440 wie folgt:
RPC_IN_DATA /owa &CorrelationID=;&cafeReqId=cf768c03-6fac-420a-999a-feeaf8c8c5e6;&LogoffReason=NoCookiesRPC_IN_DATA&encoding=; 443 – XXX.XXX.XXX.XXX MSRPC – 440 0 0 1
Habt ihr eine Idee?
RPC kann der normale Nginx doch gar nicht?
Wir haben ja alle die Zeile
location /rpc { proxy_pass https://exch2016.test.local/Rpc; }
eingefügt, bin davon ausgegangen, dass dies für RPC over HTTP ist.
Der Client kommt ja durch den NGINX bis zum Exchange, aber irgendwas scheint zu fehlen.
Outlook geht auch nicht wenn RPC over HTTP verwendet wird, da kommt immer ein Loginfeld und auch bei richtigen Zugangsdaten kommt dies immer wieder, was bei einer 401 als Rückgabewert auch verständlich ist.
CLIENTIP – – [15/Feb/2017:12:54:18 +0100] „RPC_OUT_DATA /rpc/rpcproxy.dll?517ee2d6-290d-4cf1-920e-3d72eb58fe46@MAIL.com:6002 HTTP/1.1“ 401 0 „-“ „MSRPC“
Hi,
das RPC braucht man für das MAPIoverHTTP. Das darf man nicht mit dem alten OutlookAnywhere verwechseln!
Das alte OutlookAnywhere bekommst du nicht suaber über den nginx – aber OutlookAnywhere ist ja eh schon tot – deshalb ignoriere ich das fehlende Feature einfach. Du kannst ab Outlook 2010 ja eh MAPIoverHTTP mit deime Exchange machen – und das sollte auf jeden Fall gehen 🙂
Hi,
super!
Damit ist alles klar. Ich hatte nur Probleme, da aus irgendeinem Grund Outlook 2013 ohne SP1 immer RPC probiert.
Mit SP1 wird automatisch MAPI genommen. Dann habe ich jetzt alles am laufen. Vielen Dank! 🙂
Super! Schön das es geholfen hat 😊
Hallo,
danke für die super Anleitung.
Ich habe ein kleine Problem.
Wenn ich /mapi über den nginx aufrufe, erscheint das Authentifizierungsfenster immer wieder.
Habt ihr eine Ahnung, was ich falsch mache?
Danke und Grüße
Martin
Hallo zusammen,
vorab eines zu der Anleitung… HERVORRAGGEND gemacht!
Ich betreibe nun einen Exchange 2013 hinter dem NGINX.
Soweit funktioniert das auch sehr sehr gut!
Leider stehe ich noch vor einer letzten kleinen Hürde.
Als externe Adresse in Exchange ist überall eine dyndns-Adresse hinterlegt.
Die Adresse wird vom Exchange stets aktualisiert.
Die Verbindungstests sind laut MS auch alle erfolgreich.
Die Outlook-Clients finden via Autodiscover zum Server und die Accounts können problemlos eingerichtet werden.
Nach gewisser Zeit (unbestimmt und nicht reproduzierbar) kommt Outlook auf die Idee darauf hinzuweisen, dass die sich hinter dem DYNDNS-Account befindliche IP-Adresse nicht im Zertifikat gelistet ist (Die IP ist in EXCHANGE nirgendwo angegeben) und fragt ob dem Zertifikat vertraut werden soll.
Wird diese Meldung akzeptiert, fragt Outlook weiterhin ob das Autodiscover von dieser IP-Adresse Änderungen vornehmen darf. Wird dies bestätigt, wird der Regelbetrieb fortgesetzt.
Weiterhin erscheint gelegentlich unten rechts in Outlook der Hinweis „Kennwort erforderlich“. Klickt man einmal auf diesen Hinweis, verschwindet dieser und es muss kein Kennwort eingegeben werden. Die Verbindung steht und die Synchronisation mit dem Exchange wird fortgesetzt.
Habt Ihr eine Idee?
Vielen Dank!
Der Alex
Hi, das Problem hatte ich bisher so nicht – wie sind den deine URLs – Also OWA,ECP,EWS,MAPI, OAB und Autodiscover? Vielleicht ist hier ja ein Problem?
Servus, prima Anleitung. ich würde ungern /ECP nach Extern freigeben, da dahinter auch das Admin Center zu erreichen ist, ohne /ecp funktioniert jedoch der Abwesenheitsassistent nicht. Hat hier jemand ggf. einen Workaround?
Hallo Sebastian,
ich habe den Zugang zum ECP deaktiviert und im Outlook funktioniert die Abwesenheitsnotiz dennoch tadellos.
Das einzige, was nicht funktioniert ist:
https://outlook.mydomain.com/owa/#path=/options/distributiongroups
Habe auch noch folgendes gefunden:
https://www.msxfaq.de/e2007/casurls.htm
„Über die Webservices stellen Outlook 2007 und neuere Clients z.B. Abwesenheitsmeldungen ein oder ermitteln Frei/Belegt-Zeiten bei Terminen. Aber auch die Transporter Suite, Federation_Services und andere Programme nutzen EWS zum Zugriff auf Postfachinhalte.“
Wenn das stimmt, was ja auch zu meiner Konfiguration passt, sollte die Abwesenheit per EWS eingestellt werden. Dann macht es wirklich nichts aus, dass ECP zu blockieren.
Habe im nginx folgendes Eingestellt:
location /ecp {
deny all;
}
Ich betreibe hinter dem Nginx einen Exchange 2016.
Viele Grüße
Lucas
Hi, es geht um das Problem, das sich beim Anklicken des Abwesenheitsassistent (Automatische Antwort festlegen“ im OWA/WebApp der Pfad von owa auf /ecp ändert (zumindest bei Exchange 2013). Ich denke Die Lösung von schaloml ist da der richtige Weg 😉
Hi, ich mache für diesen Fall öfters eine zweite ECP die nur von innen erreichbar ist – eine kleine Anleitung direkt bei TechNet: https://technet.microsoft.com.
So deaktiviert man auf der Standard-ECP die Admin-Features und kann über einen zweite ECP weiter administrieren.
Wenn ich mal wieder einen mache kann ich da mal ne schöne Anleitung schreiben 🙂
Hi, ja cool, dass war genau die Richtung in die ich was gesucht haben 😉 Vielen Dank!
Pingback:NGINX Reverse Proxy für Exchange 2016 – LANbugs
Hi @all
steh vor folgendem Problem :
Nginx auf Exchange extern läuft ohne Problem dank der obigen Anleitung perfekt…
Mein Problem liegt im Zugriff innerhalb des lokalen Lan…
Da geht der Zugriff ja nicht über den Nginx sondern direkt auf den Exchange via internem DNS vom Windows Server…
Dort bekomm ich immer eine Zertifikatswarnung, von wegen ungültig..(Ist klar, ist ja auch das „selbstausgestellte“ vom Exchange…
Wie habt Ihr das gelöst ??
Danke für nen Tip..
Grüße
Sunny
Hi, die sauberste Lösung wäre für den Exchange ein eigenes Zertifikat auszustellen – z.B. mit einer eigenen CA. Du kannst aber auch das selbssignierte Zertifikat im AD als vertrauenswürdige Stammzertifizierungsstelle verteilen.
Super Anleitung, eine ggfs. Off-Topic Frage von mir: kann man irgendwie einschränken, welche User OWA nutzen dürfen? Ich möchte das Feature nicht allen zur Verfügung stellen. So weit ich weiß, lässt der Exchange Server keine Einschänkung zu, könnte der nginx da was machen?
Grüße, Ingo
Hi, du kannst am Exchange jederzeit für eizelne User OWA deaktivieren: https://technet.microsoft.com/de-de/library/bb124124(v=exchg.150).aspx 🙂