NGINX: ReverseProxy für MAPI over HTTP, EAS und OWA

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:

EWS-Standardauth-aktivieren

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

Nginx Reverse Proxy: IP-Ausnahmen bei Authentisierung mit Clientzertifikaten

Ich verwende den Nginx ja wirklich gerne – auch als Reverse Proxy (z.B. für andere Webserver, CMS, und natürlich auch für Exchange).
Dort setzte ich auch gerne Clientzertifikate zur Absicherung ein.
Doch manchmal muss/soll von einer IP der Seitenaufruf aber ohne Clientzertifikat möglich sein…

Ich habe das mit einer if-Abfrage gelöst:

if ($remote_addr = 1.2.3.4 ) 
   {
    proxy_pass http://10.10.10.1; 
    break; 
   }

if ($ssl_client_verify != "SUCCESS") 
   { return 403; }

Hier wird der Aufruf von der IP 1.2.3.4 direkt auf den Webserver mit der IP 10.10.10.1 weitergeleitet und mit dem break wird die weitere Verarbeitung abgebrochen.
Falls die Anfrage nicht von der IP 1.2.3.4 kommt wird überprüft ob eine Authentifizierung mit einem Clientzertifikat stattgefunden hat – und falls das nicht der Fall ist wird eine 403-Seite gezeigt.
Vorraussetztung ist, dass in der Clientzertifikateskonfiguration der Wert ssl_verify_client auf optional steht;

Hier ist eine komplette Beispielkonfiguration für einen Reverse Proxy mit Clientzertifikaten inkl. IP-Ausnahme:

server {
    listen                  443 ssl; 
    server_name             www.domain.com;
    ssl_certificate         /etc/nginx/ssl/domain/server.crt; 
    ssl_certificate_key     /etc/nginx/ssl/domain/server.key; 
    ssl_client_certificate  /etc/nginx/ssl/clients/client_ca.pem
    ssl_verify_client       optional;

    # Set global proxy settings
    proxy_read_timeout      360;
    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 "";


    location /
    {

    if ($remote_addr = 1.2.3.4 ) 
       {
        proxy_pass http://10.10.10.1; 
        break; 
       }

    if ($ssl_client_verify != "SUCCESS") 
       { return 403; }

    proxy_pass http://10.10.10.1;}

    error_log /var/log/nginx/domain-error.log;
    access_log /var/log/nginx/domain-access.log;
}

Funktioniert einwandfrei 🙂

Quelle: Serverfault

Zertifikatskette für Nginx

Bei einigen Zertifikaten die im Nginx verwendet werden, ist es notwendig die gesamte Zertifikatskette in dem Zertifikat mit anzugeben.

Das geht super einfach mit cat auf der Konsole:

cat domain.tld.crt sub-ca.cer > domain-bundle.crt

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca). Die Stammzertifizierungsstelle (Root-CA) wird meistens nicht benötigt.

Manchmal muss man aber doch auch das Root-CA mit in Kette mit aufnehmen (z.B. bei Zertifikate einer eigenen CA) – dann wäre es:

cat domain.tld.crt sub-ca.cer root-ca.cer > domain-bundle.crt

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca) und am Schluss die Stammzertifizierungsstelle (root-ca).

Wenn man die Zertifikate von Windows-Systemen bekommt, sollte man alle vorher mit

openssl x509 -inform der -in certificate.cer -out certificate.pem

umwandeln und dann eben mit

cat domain.tld.pem sub-ca.pem root-ca.pem > domain-bundle.crt

weiterverarbeiten.

In der Nginx-Config jetzt enfach das bundle.crt in der Zeile

ssl_certificate /etc/nginx/ssl/domain-bundle.crt;

angeben und nginx dann neustarten.

PFX mit OpenSSL in .key und .crt umwandeln

Ich muss öfters mal Zerifikate im PFX-Format umwandeln in .key und .crt-Datein für z.B. den WebServer NGINX umwandeln. Das geht mit OpenSSL ganz einfach:

Das eigentliche Zertifikat:

openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.crt

Den Privat Key bekommt man mit:

openssl pkcs12 -in cert.pfx -nocerts -out cert-encrypted.key

openssl rsa -in cert-encrypted.key -out cert.key

Der zweite Befehl beim Privat Key konvertieren ist dafür da, dass z.B. beim beim starten des WebServers nicht nach der PEM pass phrase gefragt wird (beim NGINX kommt beim starten sonst der Fehler: Starting nginx: Enter PEM pass phrase:)

SSHFS Passwort übergeben

SSHFS benutze ich ganz gerne – vor allem um für Backups von Linux-Servern über SSH ein Verzeichnis zu mounten. Normalerweise macht man damit man kein Password eingeben muss die Authentifizierung über Private/Public-Keys (siehe z.B. diese Anleitung).

Manchmal ist das aber aus verschiedenen Gründen nicht möglich – man möchte aber trotzdem das Passwort z. B. in einem Script übergeben. Dazu muss folgender Befehl ausgeführt werden:

echo password | sshfs -o password_stdin user@host:/verzeichnis /mnt/verzeichnis

Das sieht dann zum Beispie wie hier aus:

echo SuperGeheimesKennwort | sshfs -o password_stdin SSHUSER@192.168.178.1:/backup /mnt/backup

Seafile mit NGINX und MySQL unter Debian installieren

Seafile ist eine Open Source Software mit der man seine eigene (selbst gehostete) Cloud zum Austausch von Dateien, Zusammenarbeit mit Anderen und noch mehr betreiben kann – eine Alternative zu Diensten wie Dropbox, OneDrive oder Google Drive.

Ich werde hier die Einrichtung von Seafile auf einem Debian-System (aktuell 7.5) mit NGINX als Webserver und MySQL als Datenbank beschreiben. Dazu werde ich noch beschreiben wie man die Zugriffe mit SSL (HTTPS) verschlüsselt und so einen sicheren Zugriff auf die Daten gewährt. Ich mache das hier ein bischen ausführlicher und immer Schritt für Schritt – sollte so für jeden nachzubauen sein Weiter

Speedtest über das Terminal

Auf einem Linux-Server möchte man ab und an mal einen Speedtest machen. Am schönsten wäre natürlich über Speedtest.net. Nur haben Server seltenst ja eine GUI oder noch dazu einen Browser. Dafür gibt es jetzt die speedtest-cli

Zuerst holen wir uns von Github das Scipt

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py

Danach muss man das Script ausführbar machen

chmod +x speedtest-cli

Danach kann man es starten

./speedtest-cli

und sogar mit mit Result-Bildchen

./speedtest-cli –share

Dann sieht das so aus:


root@vps:/# ./speedtest-cli --share
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Nobis Technology Group, LLC (23.105.138.107)...
Selecting best server based on ping...
Hosted by Interserver, inc (Secaucus, NJ) [7.01 km]: 17.007 ms
Testing download speed........................................
Download: 77.93 Mbit/s
Testing upload speed..................................................
Upload: 48.40 Mbit/s
Share results: http://www.speedtest.net/result/3225015203.png

null

Quelle: vpstip.com

IPsec / L2TP VPN mit OpenSwan / xl2tpd unter Debian

Ich benutzte einen meiner Server um dort ein VPN zu betreiben. Dabei verwende ich die Kombination aus L2TP und IPSec. So ein IPSec/L2TP-VPN hat gegenüber z.B. OpenVPN den Vorteil, dass man keine Clientsoftware benötigt und es eigentlich auf allen meinen Betriebssystemen out of the Box läuft. Mac OS, iOS, Android und Windows können ohne Zusatzsoftware eine Verbindung mit dem VPN aufbauen. Implementiert habe ich das auf einem Debian-Linux mit Hilfe von Openswan (IPSec-Implementierung) und xl2tpd (L2TP-Implementierung).

Weiter

VMWare-Tools unter Ubuntu

Ich muss öfters unter Ubuntu (meist Server – ab und an auch mal Desktops) die VMWare-Tools installieren.

An sich wäre das kein Problem – nur sind im seltensten Fall die Voraussetzungen (GCC C++, Kernel-Headers,etc) installiert und das Script läuft nicht durch, sondern bleibt spätesten bei der Frage nach dem GCC-Pfad hängen.

Am einfachsten installiert man die ganzen Abhängigkeiten über das Terminal mit

sudo apt-get update && sudo apt-get install build-essential linux-headers-$(uname -r)

danach mounte ich das zuvor verbunden ISO der VMWare Tools und kopiere das VMWareTools-Paket in Downloads

sudo mount /dev/cdrom /mnt
sudo cp /mnt/VMwareTools-*.tar.gz /home/BENUTZERNAME/Downloads/

Danach entpacke ich es

cd /home/BENUTZERNAME/Downloads/
sudo tar -xzvf VMwareTools-*.tar.gz

und starte auf dem Terminal

sudo /home/BENUTZERNAME/Downloads/vmware-tools-distrib/vmware-install.pl

Danach kann eigentlich immer mit Enter die Vorauswahl übernommen werden.

Wenn es fertig ist – einen Reboot

sudo reboot

und fertig 🙂

ReverseProxy für EAS (Exchange ActiveSync) und OWA (OutlookWebApp) mit NGINX

Falls man ActiveSync und OWA anbieten will, sollte dies unbedingt über einen ReverseProxy gelöst werden. Diesen ReverseProxy für die Exchange-Dienste kann man auch mit dem Webserver NGINX auf Linux (in meinem fall Ubuntu Server) lösen. Da Microsoft den TMG eingestellt hat ist diese Kombination auch eine gute Alternative – wenn man auf OutlookAnywhere (RPC over HTTPS) verzichten kann. NGINX unterstützen kein RPCoverHTTPS – das neue MAPIoverHTTPS ist aber möglich – ActiveSync (DirectPush) und OWA funktionieren aber wunderbar.

Hier eine kleine Anleitung wie man dies implementiert.

Weiter