NGINX Reverse Proxy mit Exchange 2016 und Outlook 2016
Hallo Forum,
ich befasse mich gerade mit dem Thema Reverse-Proxy für Exchange 2016 unter Ubuntu mit NQINX.
Wenn ich meine Konfiguration aktiviere, dann kommt bei Outlook 2016 (Outlook Anywhere) immer die Kennwortabfrage. Eine Verbindung zum Exchange-Server kommt nicht zustande.
Outlook Web Access läuft dagegen ohne Probleme.
Im Zertifikat (StartSSL) stehen die folgenden Eintragungen:
mail.domain.de
autodiscover.domain.de
Im Exchange sind alle Zugriffe (intern und extern) auf die folgenden Domains eingerichtet
https://mail.domain.de
https://autodiscover.domain.de
Die Anpassung des DNS-Server ist so eingerichtet, dass intern der lokale Mail-Server gezeigt wird und von extern auf meine öffentliche IP-Adresse verweisen wird.
Im Linux-Server (Ubuntu Server 16.04 LTS) habe ich NGINX und NGINX-Extras installiert.
Im wesentlichen habe ich mich an die Anleitungen von blog.freidlandreas.net (https://blog.friedlandreas.net/2013/07/reverseproxy-fur-eas-exchange-act ...) und https://blog.friedlandreas.net/2016/05/nginx-reverseproxy-fuer-mapi-over ..) gehalten.
Für EWS und OAB habe ich am Exchange-Server im IIS die Standardauthentifizierung aktiviert.
Die Konfiguration vom Reverse-Proxy sieht wie folgt aus:
Habe ich etwas übersehen?
Danke für Ideen und Vorschläge.
VG Dieter
ich befasse mich gerade mit dem Thema Reverse-Proxy für Exchange 2016 unter Ubuntu mit NQINX.
Wenn ich meine Konfiguration aktiviere, dann kommt bei Outlook 2016 (Outlook Anywhere) immer die Kennwortabfrage. Eine Verbindung zum Exchange-Server kommt nicht zustande.
Outlook Web Access läuft dagegen ohne Probleme.
Im Zertifikat (StartSSL) stehen die folgenden Eintragungen:
mail.domain.de
autodiscover.domain.de
Im Exchange sind alle Zugriffe (intern und extern) auf die folgenden Domains eingerichtet
https://mail.domain.de
https://autodiscover.domain.de
Die Anpassung des DNS-Server ist so eingerichtet, dass intern der lokale Mail-Server gezeigt wird und von extern auf meine öffentliche IP-Adresse verweisen wird.
Im Linux-Server (Ubuntu Server 16.04 LTS) habe ich NGINX und NGINX-Extras installiert.
Im wesentlichen habe ich mich an die Anleitungen von blog.freidlandreas.net (https://blog.friedlandreas.net/2013/07/reverseproxy-fur-eas-exchange-act ...) und https://blog.friedlandreas.net/2016/05/nginx-reverseproxy-fuer-mapi-over ..) gehalten.
Für EWS und OAB habe ich am Exchange-Server im IIS die Standardauthentifizierung aktiviert.
Die Konfiguration vom Reverse-Proxy sieht wie folgt aus:
#Abschnitt 1
server {
listen 80;
server_name mail.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 mail.domain.de autodiscover.domain.de;
# Enable SSL
ssl on;
ssl_certificate /etc/nginx/certs/exchange2016-2016-10-31-startssl.pem;
ssl_certificate_key /etc/nginx/certs/exchange2016-2016-10-31-startssl.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="mail.domain.de"';
location /owa { proxy_pass https://mail.domain.de/owa; }
location /EWS { proxy_pass https://mail.domain.de/EWS; }
location /Microsoft-Server-ActiveSync { proxy_pass https://mail.domain.de/Microsoft-Server-ActiveSync; }
location /mapi { proxy_pass https://mail.domain.de/mapi; }
location /rpc { proxy_pass https://mail.domain.de/Rpc; }
location /OAB { proxy_pass https://mail.domain.de/OAB; }
location /autodiscover { proxy_pass https://mail.domain.de/autodiscover; }
location /Autodiscover { proxy_pass https://mail.domain.de/Autodiscover; }
error_log /var/log/nginx/exchange-ssl-error.log;
access_log /var/log/nginx/exchange-ssl-access.log;
}
Habe ich etwas übersehen?
Danke für Ideen und Vorschläge.
VG Dieter
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 319620
Url: https://administrator.de/contentid/319620
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
16 Kommentare
Neuester Kommentar
Hallo Dieter,
halte dich erstmal an diesen Thread. Dort hat am Ende alles wie gewünscht funktioniert.
Gruß,
Dani
halte dich erstmal an diesen Thread. Dort hat am Ende alles wie gewünscht funktioniert.
Gruß,
Dani
Moin Dieter,
Gruß,
Dani
Im verlinkten Thread ist ebenfalls eine geänderte Konfig enthalten. Auch diese läuft nicht.
du hast die Konfiguration aus dem letzten Kommentar entnommen? Denn dort ist der Fehler nicht mehr aufgetreten. Gibt es eine universell laufende Möglichkeit für einen Reverse-Proxy?
Bestimmt. Mit Nginx ist meiner Meinung oft Try & Error angesagt. Wir nutzen inzwischen Microsoft Web Application Proxy, weil dieser nicht nur für Exchange sondern auch andere Services veröffentlicht und authentifiziert.Gruß,
Dani
Moin,
Gruß,
Dani
Für EWS und OAB habe ich am Exchange-Server im IIS die Standardauthentifizierung aktiviert.
würde ich wieder auf den Ursprungskonfiguration abändern. Diese hatte ich auch mal eingetragen. Ich hatte auch die gesamte Konfig übernommen. Leider ohne den gewünschten Erfolg.
Hast du danach mal einen Microsoft Remote Connectivity Analyzer durchgeführt, um zu sehen wo es hängt? Autodiscover funktioniert vollumfänglich von extern? Ich werde mal den WAP von Windows testen. Danke für den Hinweis.
bevor du dich ins Unglück stürzt, für WAP ist ADFS erforderlich. Das ist kein Selbstläufer, sondern kann dich je nach Anforderungen und Umsetzung in den Wahnsinn treiben.Gruß,
Dani
Moin,
Gruß,
Dani
Für EWS und OAB habe ich am Exchange-Server im IIS die Standardauthentifizierung aktiviert.
würde ich wieder auf den Ursprungskonfiguration abändern. Diese hatte ich auch mal eingetragen. Ich hatte auch die gesamte Konfig übernommen. Leider ohne den gewünschten Erfolg.
Hast du danach mal einen Microsoft Remote Connectivity Analyzer durchgeführt, um zu sehen wo es hängt? Autodiscover funktioniert vollumfänglich von extern?Gruß,
Dani
Es gab ledig eine Warnung bzgl. meines StartSSL-Zertifikates und der Prüfung der CA.
Das Problem holt dich später noch ein. Hat mit diesem aber nichts zu tun. Der Zugriff auf Autodiscover, OWA und Outlook Anywhere funktioniert ohne Probleme, wenn ich am Router HTTPS direkt zum Exchange-Server leite.
Das sind schon mal 50%. Wie sieht das Ergebnis mit Nginx aus?Gruß,
Dani
Moin,
Hast du den Exchange Server mal neugestartet? Hat bei uns während der Migration seltsame Phänomen gelöst.
Gruß,
Dani
Ich gehe daher davon aus, dass beim Zugriff auf das Zertifikat bei Outlook Anywhere irgend welche Fehler auftreten.
wenn das so wäre, würde eigentlich eine Sicherheitswarnung am Client angezeigt.Bei den verschiedenen Tests hatte ich zum Teil keine Verbindung zum Netzwerk mittels MRCA.
Kannst du mal das Ergebnis von MRCA posten?Hast du den Exchange Server mal neugestartet? Hat bei uns während der Migration seltsame Phänomen gelöst.
Gruß,
Dani