Ich setze den NGINX ja gerne sowohl als Web Server als auch als Reverse Proxy ein – fast genauso gerne setzte ich mittlerweile die Let´s Encrypt Zertifikate ein.

Hier eine kleine Anleitung wie ich das immer konfiguriere (Webroot unter Ubuntu):

1) Erstellen eines NGINX-Config-Snippet

wir erstellen einen Config-Datei

vim /etc/nginx/snippets/letsencrypt.conf

und dort einfügen (gegebenfalls das Verzeichnis unter root ändern):

location ^~ /.well-known/acme-challenge/ {
default_type „text/plain“;
root /var/www/letsencrypt;
allow all;
}

und mit :wq abspeichern

2) Anpassen der bestehenden NGINX-Konfig

Ich konfiguriere eigentlich meine Webseiten immer als HTTPS-only – das heißt jede Anfrage auf Port 80 (HTTP) auf 443 (HTTPS) umgeleitet.

Da die Domänen-Verifizierung von Let´s Encrypt über einen HTTP Aufruf gemacht wird, müssen wir allerdings hier eine Ausnahme erstellen.

Dazu passen wir unsere Webseiten Konfig an:

vim /etc/nginx/sites-available/meineseite

und fügen unser Snippet mittels include in dem Serverteil für HTTP hinzu:

server {
        listen 80;
        listen [::]:80;

        server_name www.meineseite.de;

	include /etc/nginx/snippets/letsencrypt.conf;

        # Redirect any HTTP request to HTTPS
        location / {
        return 301 https://www.meineseite.de;}

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

Im Serverteil für HTTPS braucht hier nichts angepasst werden 🙂

3) Installieren des Let´s Encrypt Clients

Installation unter Ubuntu ist super einfach:

sudo apt-get install letsencrypt

4) erstellen des root-Verzeichnises für Let´s Encrypt

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

Ich vergebe auch noch entsprechende Rechte (meistens läuft der NGINX ja als www-data User bzw. der User ist in der www-data-Gruppe)

sudo chown -R www-data:www-data /var/www/letsencrypt

5) NGINX reload

sudo systemctl reload nginx

6) Let´s Encrypt Client auführen

letsencrypt certonly –webroot -w /var/www/letsencrypt -d www.meineseite.de -d meinerseite.de –email email@meineseite.de –agree-tos

mittels -d domain.tld können noch weitere Domains – falls benötigt – hinzugefügt werden und unbedingt die Email nicht vergessen anzupassen!

Falls alles geklappt hat werden jetzt die Zertifikate ausgestellt – zu finden sind die Zertifikate unter /etc/letsencrypt/live/www.meineseite.de

7) HTTPS-Konfig anpassen

Jetzt müssen wir noch die neuen Zertifikate in die HTTPS-Konfig hinzufügen

vim /etc/nginx/sites-available/meineseite

und die Zertifikate angeben

ssl_certificate /etc/letsencrypt/live/www.meineseite.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.meineseite.de/privkey.pem;

mit :wq speichern – und wir sind fast fertig 🙂

8) Renew automatisieren

Die Let´s Encrypt Zertifikate haben die Einschränkung, dass sie nur 90 Tage gültig sind. Man kann hier aber über einen cron-job Abhilfe leisten:

sudo crontab -e

und die folgenden Zeilen hinzufügen

30 2 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log
35 2 * * 1 /bin/systemctl reload nginx

so wird automatisch das Zertifikat verlängert und die Konfig des NGINX aktualisiert

9) fertig 🙂

Quellen:
letsencrypt.org
GitHub

Will man einen ESXi-Host updaten oder z.B. von 6.0 auf 6.5 upgraden, kann man das ganz einfach wie folgt über die CLI erledigen:

1) SSH-Dienst auf dem Host starten

Entweder im Web Client unter Aktionen – Dienste – Secure Shell (SSH) aktivieren

ssh-aktivieren-webclient

oder im vSphere Client wie hier beschrieben

2) Anmeldung über SSH

3) Firewall für HTTP freischalten

esxcli network firewall ruleset set -e true -r httpClient

4) Upgrade-Paket suchen – hier als Beispiel die Version 6.5

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep -i ESXi-6.5

(Für andere Versionen einfach bei dem grep die entsprechende Version abändern)

Dann bekommt man folgende Anzeige

ssh-upgrade-paket-finden

5) Upgrade ausführen

esxcli software profile update -p ESXi-6.5.0-4564106-standard -d http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

(Für andere Versionen einfach die entsprechende Version abändern)

Nach dem erfolgreichen update sieht man folgendes

ssh-upgrade-beendet

6) Nestarten

reboot

fertig 🙂

Ich hatte das Problem dass ein neuer Rechner mit Windows 10 nicht auf Cifs-Freigaben auf einem NetApp-Filer zugreifen konnte. Der alte Trick mit dem Ausschalten des „Sicheren Aushandeln“ – der Secure Negotiaten – funktionierte nicht mehr…

Lösung:

Auf der NetApp (per SSH) folgenden Befehl ausführen:

options cifs.smb2.signing.required on

Danach funktionierte der Zugriff reibungslos 🙂

Ich habe meine WordPress-Installation auf einen neuen Server umgezogen – inklusive upgrade der Software -> neueste Ubuntu-Version, MariaDB statt MySQL, PHP7 statt PHP5, neueste nginx-Version inkl. benutztung von neuen Features, etc…

Es sollte alles funktionieren – falls nicht bitte hier einen kurzen Kommentar rein – Danke 🙂

Wenn ich auf einem Ubuntu 16.04 Server apt-get update oder auch apt-get upgrade ausführe, bleibt es beim abrufen der Paketquellen über IPv6 einfach hängen:

root@ubuntu:~# apt-get update -y
OK:1 http://de.archive.ubuntu.com/ubuntu xenial InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu xenial-backports InRelease
0% [Verbindung mit security.ubuntu.com (2001:67c:1560:8001::14)]

aptgetipv6

Lösen kann man das Problem wenn man IPv4 enforced:

apt-get -o Acquire::ForceIPv4=true update
apt-get -o Acquire::ForceIPv4=true upgrade

Alternativ kann man das auch persistent einstellen:

echo 'Acquire::ForceIPv4 "true";' | tee /etc/apt/apt.conf.d/99force-ipv4

Danach kann ich einfach wieder ganz normal apt-get update ausführen 🙂

root@ubuntu:~# apt-get update
OK:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu xenial InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu xenial-backports InRelease
Paketlisten werden gelesen... Fertig

aptgetipv4

Das KB3159398, dass über Windows Update zur Zeit verteilt wird, ändert ein wenig die Art und Weise wie die Sicherheitsfilterung bei der Gruppenrichtlinienverarbeitung funktioniert.

Das kann zu Problemen führen, wie z.B.:

– Laufwerke werden nicht mehr gemappt
– Desktop-Symbole für Verknüpfungen werden nicht mehr sauber angezeigt
– Diverse Gruppenrichtlinien (z.B. Druckerzuweisungen, etc) funktionieren nicht mehr

Das Problem liegt an einem fehlendem Lese-Recht des Authentifizierte Benutzer (Authenticated Users) unter Delegierung, dass durch den Patch jetzt allerdings benötigt wird.

In dem KB dazu hat Microsoft das Problem auch beschrieben:

Known issues

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context. This issue is applicable for the following KB articles:

3159398 MS16-072: Description of the security update for Group Policy: June 14, 2016
3163017 Cumulative update for Windows 10: June 14, 2016
3163018 Cumulative update for Windows 10 Version 1511 and Windows Server 2016 Technical Preview 4: June 14, 2016
3163016 Cumulative Update for Windows Server 2016 Technical Preview 5: June 14 2016

Symptoms

All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.

Cause

This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.

Resolution

To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
– Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
– If you are using security filtering, add the Domain Computers group with read permission.

Lösung: Die Authentifizierten Benutzer manuell mit dem Lese-Recht bei den Delegierungen hinzufügen

AuthUsersGPO

Es gibt auch hier ein Script dass das automatisch macht.

Empfehlenswerter Artikel zu lesen: http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

Ich hatte bei einem Kunden das Problem, dass in schöner Regelmäßigkeit die Exchange-Datenbanken, SQL-Datenbanken und auch die Datenbanken des ActiveDirectorys auf den Domain-Controllern, die in VMs unter VMWare liefen, nach der Sicherungen (in meinem Fall mit Veeam) Fehler aufwiesen – oder teilweise sogar ganz defekt waren.

Nach ewiger Sucherei stellt sich heraus: Die eingesetzte VMWare-Version (vSphere 6.0) hatte ein schwerwiegendes Problems mit dem CBT Treibern – betroffen waren Oracle, SQL, AD und Exchange Datenbanken. Hier auch ein Thread zu dem Thema.

Die Lösung ist hier ganz simpel: Update der VMWare-Umgebung (mindestens) auf das Update 1b – den dort ist der Bug behoben.

Seitdem keine Problem mehr 🙂

Ich hatte in einem AD das Problem, dass nach einem Restore aus einem Snapshot die Domain Controllern die Anmeldung der User verweigerten und auch untereinander nicht mehr replizierten. Im Eventlog wurde folgender Fehler protokolliert:

Ereignistyp: Fehler
Ereignis Quelle: NTDS Allgemein
Ereigniskategorie: Steuerung
Ereignis-ID: 2103
Beschreibung: Die Active Directory-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt. Active Directory können Benutzer anmelden, während das Problem weiterhin besteht. Als Ergebnis wurde der Netlogon-Dienst angehalten. Benutzer Aktion Siehe vorherige Ereignisprotokolle Einzelheiten. Weitere Informationen finden Sie im Hilfe- und Supportcenter unter http://support.microsoft.com.

Und bei der Replikation wurde die Fehlermeldung (z.B. bei repadmin /showrepl)

Der Quellserver nimmt keine Replikationsanforderung entgegen

ausgegeben.

Das ganze Problem wurde verursacht, dass durch die nicht unterstützte Wiederherstellung – in meinem Fall ein Snapshot – die Datenbank der Active Directorys auf Not Writeable gesetzt wurde.

Das ganze wieder ans laufen bekommt man wenn man in der Registry auf dem DC unter

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

den Wert „Dsa Not Writable“ von 4 auf 0 setzt.

Dazu legt man noch einen REG_DWORD “Ignore USN Rollback” an und setzt den Wert auf 0

Danach muss man den Server neustarten.

Damit die Replikation wieder sauber funktioniert muss man auf allen DC-Servern die Befehle

repadmin /options “ServerName” -DISABLE_OUTBOUND_REPL
repadmin /options “ServerName” -DISABLE_INBOUND_REPL

ausführen – wobei „ServerName“ mit dem jeweiligen lokalen Servernamen des DCs ersetzten.

Jetzt sollte eigentlich alles laufen.

Falls allerdings die Replikation noch nicht funktioniert – oder andere Fehler im Eventlog protokolliert werden – kann noch ein Reset des Passwortes des Computerkontos der Domaincontroller nötig sein.

Das macht man auf den DCs folgendermaßen (am besten davor einen Reboot machen):

netdom resetpwd /server:anderer_dc /userd:domain\administrator /passwordd:*

Danach den Server rebooten.

Jetzt sollte es wirklich wieder laufen 🙂

Quelle: hyper-v-server.de

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