Nginx Reverse Proxy Exchange () Outlook Verbindung bricht immer ab

Hallo Leute,

ich habe hier in einer privaten Umgebung folgende Konstellation:

Client Windows 10 1511 (Über Hostsdatei den Weg von extern simuliert) > Reverse Proxy (Nginx 1.6.2 / Debian 8) > IIS 8.5 > Exchange 2016

Auf dem Client simuliere ich den externen Zugriff durch einen veränderten A-Record über den Reverse Proxy, da interen Geräte normalerweise den Exchange direkt ansprechen.
Ich habe am Nginx mit mehreren Konfigurationen rumprobiert.
Hier ein paar Anleitungen, die meine Aufmerksamkeit fanden:

Aktuell sieht meine Exchange-Teil in der Confi des Nginx wie folgt aus:

server {
        listen 80;
        #listen [::]:80;
        server_name  meine.domain.de autodiscover.domain.de;
        return 301 https://$host$request_uri;
}

server {
        listen 443;
        ssl                     on;
        ssl_certificate         Pfad zum Zertifikat;
        ssl_certificate_key     Pfad zum Private-Key;
        ssl_session_timeout     30m;
		ssl_protocols  TLSv1.2 TLSv1.1 TLSv1;

        location / {
		return 301 https://meine.domain.de/owa;
		}
		
        server_name mail.uwe-jank.de;

        proxy_http_version       1.1;
        proxy_read_timeout      360;
        proxy_pass_header       Date;
        proxy_pass_header       Server;
        proxy_pass_header       Authorization;

        proxy_set_header        Accept-Encoding "";  
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
		
		more_set_input_headers 'Authorization: $http_authorization';  
        more_set_headers -s 401 'WWW-Authenticate: Basic realm="meine.domain.de"';  

        location ~* ^/owa { proxy_pass https://meine.domain.de; }
        location ~* ^/Microsoft-Server-ActiveSync { proxy_pass https://meine.domain.de; }
        location ~* ^/ecp { proxy_pass https://meine.domain.de; }
        location ~* ^/rpc { proxy_pass https://meine.domain.de; }
	location ~* ^/mapi { proxy_pass https://meine.domain.de; }
        
        error_log Pfad zum Error-Log;
        access_log Pfad zum Access-Log;

Es gibt auch Configs mit viel mehr Parametern, das Ergebnis war aber: Das Problem besteht auch mit viel mehr Parametern und ich denke das das Problem auf IIS / Exchange Seite besteht.

Das Problem ist nämlich folgendes:

Wenn ich mich mit dem Client verbinde. Plopt erstmal das Anmeldefenster auf.

Ich authentifiziere mich (Domain\User) und die Verbindung steht.
Nach maximal 2 Minuten fragt mich Outlook aber erneut nach dem Passwort (Zeit variiert).
Passwort speichern frist Outlook gar nicht (Authentifizierung erfolgt nicht und Abfrage wird erneut geöffnet).

Im IIS habe ich schon unter Server > Default Web Site > ECP | EWS | MAPI | EAS | OAB | OWA | RPC die Standardauthentifizierung aktiviert.
Das gleiche wurde auch im ECP erledigt.

Folgende IPtables-Regeln wurden im Nginx importiert:

*filter

# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0 
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

# Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow connections from anywhere
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow SSH connections
-A INPUT -p tcp -m state --state NEW --dport SSH-Port -j ACCEPT

# Allow MX connections
#-A INPUT -p tcp --dport 25 -j ACCEPT
#-A INPUT -p udp --dport 25 -j ACCEPT

# Allow ping
-A INPUT -p icmp -j ACCEPT

# Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7  

# Allow all outbound traffic
# Alternative: "-P OUTPUT ACCEPT" which sets default policy 
-A OUTPUT -j ACCEPT

# Drop all other inbound traffic
# Alternative: "-P INPUT DROP" and "-P FORWARD DROP" which sets default policy 
-A INPUT -j DROP 
-A FORWARD -j DROP

#Weitere Portfreigaben lassen sich mit folgender Syntax hinzufügen:
#-A INPUT -p PROTOKOLL (udp oder tcp) --dport PORTNUMMER -j ACCEPT

COMMIT

Aus den Nginx Log-Dateien werde ich auch nicht schlau.

Mein Problem ist also:
Outlook fragt immer wieder nach meinem Passwort. Also ob da irgendein Timeout o.ä. die Verbindung kappt.
Ich möchte über den Nginx eine stabile Verbindung zum Exchange, der nicht immer nach einer Authentifizierung fragt.

Vielen Dank an alle, die sich diesen Text durchlesen und helfen, oder sich Gedanken darüber machen.

MFG
Leonard

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 313223

Url: https://administrator.de/forum/nginx-reverse-proxy-exchange-outlook-verbindung-bricht-immer-ab-313223.html

Ausgedruckt am: 22.12.2024 um 13:12 Uhr

6 Kommentare

Neuester Kommentar

Hallo Leonard,
grundsätzlich würde ich iptables für's Troubleshooting abschalten...

Welche Outlookversion setzt du ein?
Das Problem tritt nur über den ReverseProxy auf?
Wie hast du die Authentifizierung von Outlook Anywhere konfiguriert (NTLM, Einfach oder Aushandeln)?

Gruß,
Dani

Hallo Dani,

die "iptables" wurden nun deaktiviert. Problem besteht dennoch weiterhin.
Outlook 2016
Ja, direkt verbundene Clients laufen problemlos.
Ich nehme an, mit Anywhere ist nun MAPI gemeint. NTLM, Aushandlung und Standard. Eine Version nur mit Standard wurde schon probiert.

Moin,
der freierhältliche Nginx kann nicht mit NTLM umgehen. Daher die Authentifizierung auf Einfach konfigurieren.
Bitte gleiche deine Konfiguration an diese hier an.

Gruß,
Dani

Hallo,

nach vielem Rumprobieren habe ich es nun scheinbar hinbekommen.
Mit dieser nginx vHost Config.

Die von @Dani verlinkte hat leider so wie sie da stand auch keine Lösung erzeugt.

  server {

    listen 443 ssl spdy;
    server_name meine.domain.de;
	
	#Redirect from "/" to "/owa" by default 
    #location / {return 301 https://meine.domain.de/owa;}

	ssl_certificate           Pfad zum Zertifikat;
    ssl_certificate_key       Pfad zum Private-Key;
	ssl_session_timeout		  5m;
    ssl_session_cache shared:SSL:10m;
    
	ssl_dhparam Pfad zur .pem Datei;
    ssl_ecdh_curve secp384r1;
	
	ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
    ssl_prefer_server_ciphers on;
	
	add_header X-Frame-Options SAMEORIGIN;
	add_header X-Content-Type-Options nosniff;
	add_header X-XSS-Protection "1; mode=block";  
	add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload";  
	
	location /ecp {
	deny all;
	}
	
    access_log            /var/log/nginx/apache.access.log;

    location / {
	
	  
      proxy_read_timeout  90;
	  proxy_http_version 1.1;
      proxy_pass_request_headers on;
	  
	  proxy_pass_header       Date;
      proxy_pass_header       Server;
	  proxy_pass_header       Authorization;
	  proxy_buffering off;
	  proxy_set_header Connection "Keep-Alive";  
	  
	  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        X-Forwarded-Proto $scheme;
      proxy_set_header        Accept-Encoding "";  
	  
	  more_set_input_headers 'Authorization: $http_authorization';  
      more_set_headers -s 401 'WWW-Authenticate: Basic realm="meine.domain.de"';  
	  
	  location /owa           { proxy_pass https://Interne IP/owa; }
      location /EWS          { proxy_pass https://Interne IP/EWS; }
      location /Microsoft-Server-ActiveSync { proxy_pass https://Interne IP/Microsoft-Server-ActiveSync; }
      location /mapi           { proxy_pass https://Interne IP/mapi; }
      location /rpc           { proxy_pass https://Interne IP/Rpc; }
      location /OAB            { proxy_pass https://Interne IP/OAB; }
      location /autodiscover           { proxy_pass https://Interne IP/autodiscover; }

      # Fix the “It appears that your reverse proxy set up is broken" error. 
      proxy_pass          https://Interne IP;
	
	  proxy_redirect      https://Interne IP https://meine.domain.de;
	}
  }

Restliche Einstellungen sind auch gleich geblieben.
NTLM ist in der ECP aktiviert worden und auch in den IIS-Sites blieb alles wie gehabt (Standardauthentifizierung und Windows-Authentifizierung).

Entscheiden scheint die Zeile 64 zu sein.
Diese reicht die Verbindung irgendwie direkt an den IIS durch.
Dies ist auch an der Signatur zu erkennen.
Überprüft wurde dies mit dem Qualys SSLLabs Test.

Mit freundlichen Grüßen und vielen Dank
Leonard

Schöne Grüße,

ich habe momentan das Problem ebenfalls unter einem Reverse-Proxy welcher mit einem Apache2 Webserver auf einer Ubuntu 20 VM eingerichtet wurde.
Eingesetzt wird bei mir ein Exchange 2019 und Outlook 2016.

Wenn ich den Exchange direkt anspreche, funktioniert alles einwandfrei, läuft der Traffic über den Reverse-Proxy, bekomme ich einmal für das Postfach eine Passwort-Abfrage und für jedes weitere Postfach, auf welches ich Vollzugriff habe ebenfalls.
Und das wiederholt sich dann alle 5-10 Minuten.

Hier mal kurz ein Auszug für Config des Reverse-Proxy:

<VirtualHost *:80>
ServerName <FQDN>
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://<IP-Exchange>/
ProxyPassReverse / http://<IP-Exchange>/
RewriteEngine on
RewriteCond %{SERVER_NAME} =<FQDN>
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

GNU nano 4.8 /etc/apache2/sites-enabled/Exchange-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName <FQDN>
ProxyPreserveHost On
DocumentRoot /var/www/html
SSLProxyEngine On
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyPass /.well-known !
ProxyPass / https://<IP-Exchange>/
ProxyPassReverse / https://<IP-Exchange>/

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/<FQDN>/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<FQDN>/privkey.pem
</VirtualHost>
</IfModule>

und das gleiche gibt es auch noch für Autodiscover:

<VirtualHost *:80>
ServerName autodiscover.<domain>
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://<IP-Exchange>/
ProxyPassReverse / http://<IP-Exchange>/
RewriteEngine on
RewriteCond %{SERVER_NAME} =autodiscover.<domain>
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName autodiscover.<domain>
ProxyPreserveHost On
DocumentRoot /var/www/html
SSLProxyEngine ON
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyPass /.well-known !
ProxyPass / https://<IP-Exchange>/
ProxyPassReverse / https://<IP-Exchange>/

SSLCertificateFile /etc/letsencrypt/live/autodiscover.<domain>/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/autodiscover.<domain>/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Meines Erachtens sollte die ProxyPass Zeile, welche beim Vorredner geholfen hat, bei mir ja auch drin sein, jedoch haben wir natürlich nicht ganz die gleiche Basis, wäre Schön wenn mir jemand hierbei helfen könnte, bin schon am Verzweifeln.

Leider hat bei es bei mir auch nicht funktioniert, wenn ich das Aushandeln bei Outlook Anywhere auf Einfach setze.
Hier ist lediglich der Unterschied, dass es gefühlt etwas weniger abgefragt wird.

Wenn jemand eine Idee hat, wäre ich Dankbar wenn ihr mir hierbei helfen könnte.

Moin,
warum holst du die Frage wieder aus dem Archiv?
a) Der letzte Kommentar ist über 4 Jahre her
b) In der Frage geht es um NGINX.

Daher bitte eine neue, eigene Frage eröffnen.

Gruß,
Dani

geschlossen gelöst Frage Microsoft Exchange Server

Heiß diskutiert