NGINX Reverseproxy für Weiterleitung auf anderes HTTPS-Ziel

Ich hatte konkret die Aufgabe, verschiedene Webserver unter einer externen IP-Adresse erreichbar zu machen. Die Webserver verfügen bereits über ein eigenes HTTPS-Zertifikat – ich muss mich als nicht noch um Zertifikate wie Let’sEncrypt etc. kümmern.
Im konkreten Beispiel habe ich für diesen Zweck ein einfaches Ubuntu Server 18.04 LTS aufgesetzt und in meiner DMZ aufgestellt mit dem Ziel, dort nichts weiter als diesen konkreten NGINX darauf laufen zu lassen.

Nach der Installation von Linux erfolgen wie immer die üblichen Befehle zum Aktualisieren des Betriebssystems

sudo apt update
sudo apt full-upgrade

NGINX wird mit einer weiteren einfachen APT-Zeile angestoßen:

sudo apt-get install nginx

Um zu konfigurieren, dass NGINX automatisch zum Systemstart mitgestartet wird, geben wir folgenden Befehl ein:

sudo /etc/init.d/nginx start

Jetzt könnt ihr den NGINX-Webserver einfach testen durch Aufrufen der entsprechenden IP-Adresse im Browser. In meinem konkreten Fall war das die nachfolgende IP-Adresse

http://192.168.140.16

Ziel ist es in diesem konkreten Fall, eine Weiterleitung von HTTPS auf HTTPS zu konfigurieren.
Dafür muss das SSL-Zertifikat vorhanden sein und in die folgenden Dateien kopiert werden:
public Key:
sudo vim /etc/nginx/cert.crt
Private Key
sudo vim /etc/nginx/cert.key

Anschließend ist es schon soweit – ihr könnt die Konfiguration des NGINX öffnen und die Proxy-PASS-Konfig einfügen. In meinem konkreten Beispiel sah das so aus

sudo vim /etc/nginx/sites-enabled/default
server {

    listen 443 ssl;
    server_name subdomain.domain.de;

    ssl_certificate           /etc/nginx/cert.crt;
    ssl_certificate_key       /etc/nginx/cert.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/jenkins.access.log;

    location / {

      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;

      # Fix the “It appears that your reverse proxy set up is broken" error.
      proxy_pass          https://192.168.140.10:443;
      proxy_read_timeout  90;

      proxy_redirect      https://192.168.140.10:443 https://git.gustini.de;
    }
  }

Abschließend noch ein Neustart von NGINX

 sudo service nginx restart

Anschließend hat die Lösung bei mir schon funktioniert!

Postfächer in Exchange 2013 lassen sich nicht löschen

Nach der Migration von Exchange 2010 auf 2013 viel mir das Phänomen auf, dass ich Postfächer von ehemaligen Mitarbeitern nicht mehr löschen kann.
Ein Griff zu Google brachte mich glücklicherweise zur Lösung:

https://wiki.dawico.de/display/WIKI/Fehler+beim+Loeschen+eines+Exchange+Postfaches

Die Vererbung des AD-Users hat sich abgeschaltet, weil die User erhöhte Rechte bekommen haben. Im konkreten Fall waren sie „Druck-Operatoren“, wodurch die Vererbung des AD-Objektes automatisch abgeschaltet wurde.

Die Vorgehensweise für die Lösung findet ihr in oben genannten Link!

Vcenter Server Phase 2 Installation stürzt ab mit Meldung „Failed to connect to SSO“

Vmware VCenter Server 6.5 / Failed to connect to SSO

Für einen Kunden habe ich einen neuen Vcenter Server (VCSA) aufgesetzt und kämpfte mit dem Problem, dass die Phase 2 der Installation der Installation fehlschlug mit der Meldung:

„Failed to connect to SSO“

Ursache waren zwei Probleme:

  1. Der Domain Name des VCenter Servers ließ sich nicht per DNS auflösen –> Im verantwortlichen Domain Controller habe ich im DNS einen A-Record angelegt, so dass sich das FQDN ohne Probleme mit nslookup auflösen ließ
  2. Der VMware Identity Management-Dienst ließ sich laut Fehlerprotokoll nicht starten

vmware-stsd[1762]: has address 127.0.0.1. Request for http://localhost:7080/afd failed after 10 seconds. Status: /usr/bin/curl status. Response: 000. Host: localhost has address 127.0.0.1. Request for http://localhost:7080/afd failed after 10 seconds. Status: /usr/bin/curl status. Response: 000.

Lösen ließ sich das Problem dank des Blog-Beitrags von Christian Stankowic mit dem folgenden Workarround

Nach der Ersten Phase der Installation empfiehlt es sich, einen Snapshot an der VCSA und dem installierenden Client zu machen, um nicht nach jedem Fehlversuch wieder von vorne anzufangen. Anschließend wird der zweite Schritt durch Ausfüllen der Formularfelder vorbereitet. Bevor Phase zwei der Installation gestartet wird, muss jedoch noch ein Schritt unternommen werden:

In der Konsole der VCSA habe ich mit Alt+F3 in die Konsole gewechselt und mich nach erfolgreichen Login mit der Shell verbunden:

> shell
# echo "::1 localhost.localdom localhost" >> /etc/hosts

Anschließend hat sich der VCSA-Server sich selbst mit „localhost“ wieder erfolgreich aufgelöst und die Installation ist  erfolgreich durchgelaufen.

Exchange-Postfächer in PST exportieren – Powershell

Im Administrationsalltag stellt sich ab und an die Frage, wie man Postfächer ohne Verwendung von Outlook direkt in PST-Dateien exportieren kann.

  1.  Die Berechtigung für den Export muss vergeben werden:
    New-ManagementRoleAssignment –Role „Mailbox Import Export“ –User „administrator“
  2. Der Exportbefehl muss eingegeben werden
    New-MailboxExportRequest -Mailbox "Postfach Name" -FilePath "\\UNC_PFAD\ZUM\SPEICHERZIEL\pf.pst"

Nach Abschluss des Exports ist es noch sinnvoll, alle abgeschlossenen Requests zu entfernen:

Get-MailboxImportRequest -Status Completed | Remove-MailboxImportRequest

Microsoft Office Makros per Gruppenrichtlinie (GPO) abstellen zum Schutz vor Ransomware wie Locky und Cryptolocker

Das Stichwort „Ransomware“ ist derzeit in aller Munde und auch an mir geht die Aufgabe nicht vorbei, das Netzwerk meines Arbeitsgebers abzusichern. Aus diesem Grund heute aus aktuellem Anlass eine Anleitung, wie man mittels Gruppenrichtlinien im gesamten Unternehmen wirksam verhindert, dass Ransomware auf den Rechner mittels Makroschädling den PC infiziert.

Makros sind nur ein möglicher Infektionsweg von vielen. Täglich werden neue Wege aufgezeigt.

Aus diesem Grund noch mal der Hinweis, dass nur Backups,
 welche nicht permanent am PC angeschlossen sind, 
vor Ransomware schützen können.

Wie vereinheitlicht man die Office-Makro-Sicherheitseinstellungen seiner Anwender mittels zentraler Anpassung der via Gruppenrichtlinie?

  1. Herunterladen und Bereitstellen der Gruppenrichtlinie

    1. Herunterladen der Administrativen Vorlagen für Microsoft Office (In der Regel heutzutage die 64-Bit Version)
      1. Office 2007
      2. Office 2010
      3. Office 2013
      4. Office 2016
    2. Nach dem Download führen Sie die heruntergeladenen AdminTemplates_32/64.exe -Dateien aus. Sie werden aufgefordert, ein Verzeichnis zu nennen, wohin Sie die Vorlagendateien entpacken möchten. entpacken Sie die Dateien an einen Ort, an den Sie von Ihrem Domänencontroller aus hinkommen
    3. Verbinden Sie sich mit Ihrem Domänencontroller und kopieren Sie die Dateien im Verzeichnis admx in das Verzeichnis
      %systemroot%\PolicyDefinitions\
      Sie brauchen nur die Unterverzeichnisse für de und en, die anderen Sprachen müssen Sie nicht mit kopieren.
      08-03-_2016_09-11-17
  2. Konfigurieren der Gruppenrichtlinie

Erstellen Sie in der Gruppenrichtlinienverwaltung  eine neue Gruppenrichtlinie für die Office-Sicherheitseinstellungen. Die zugehörigen Makroeinstellungen finden Sie an der folgenden Stelle:

Benutzerkonfiguration\Administrative Vorlagen\[Office-Programm [Version]]

Hier gehen Sie je nach Version wie folgt vor:

  1. Office 2013
    Hier können Sie gegebenenfalls gleich die komplette VB-Skript-Ausführung deaktivieren:Benutzerkonfiguration \ Administrative Vorlagen \ Microsoft Office 2013 \ Sicherheitseinstellungen \  VBA für office-Anwendungen deaktivieren
    08-03-_2016_08-49-17Diese Richtlinie schalten Sie auf Aktiviert.
  2. Beispiel : Word 2013
    Benutzerkonfiguration \ Administrative Vorlagen \Microsoft Word 2013 \ Word-Optionen \ Sicherheit \ Trust-Center \ Einstellungen für VBA-Makrobenachrichtigungen
    08-03-_2016_08-56-07Hier wählen Sie „Alle Makros ohne Benachrichtigung deaktivieren“.Die Einstellungen für die anderen Office-Programme und Word-Versionen befinden sich an den folgenden Stellen:

ProgrammGPO-PfadEinstellung
Word 2013Microsoft Word 2013\Word-Optionen\Sicherheit\Trust-CenterEinstellungen für VBA Makrobenachrichtigungen:
Alle Makros ohne Benachrichtigung deaktivieren
Word 2010Microsoft Word 2010\Word-Optionen-Sicherheit\SicherheitscenterEinstellungen für VBA Makrobenachrichtigungen:
Alle Makros ohne Benachrichtigung deaktivieren
Word 2007Microsoft Office Word 2007\Word-Optionen\Sicherheit\VertrauensstellungscenterEinstellungen für VBA Makrobenachrichtigungen:
Keine Warnungen für alle Makros, aber alle Makros deaktivieren
Excel 2013Microsoft Excel 2013\Excel-Optionen\Sicherheit\Trust-CenterEinstellungen für VBA Makrobenachrichtigungen:
Alle Makros ohne Benachrichtigung deaktivieren
Excel 2010Microsoft Excel 2010\Excel-Optionen\Sicherheit\SicherheitscenterEinstellungen für VBA Makrobenachrichtigungen:
Alle Makros ohne Benachrichtigung deaktivieren
Excel 2007Microsoft Office Excel 2007\Excel-Optionen\Sicherheit\VertrauensstellungscenterEinstellungen für VBA Makrobenachrichtigungen:
Keine Warnungen für alle Makros, aber alle Makros deaktivieren

Die GPO-Pfade für die Makro-Einstellungen der in der Tabelle genannten Programme lassen sich ebenfalls ableiten auf Outlook, Access, Powerpoint und all die anderen Office-Programme. Die Pfade unterscheiden sich bei den Versionen zumeist in der unterschiedlichen Übersetzung des „Trust-Centers“.

Vergessen Sie anschließend nicht, die Gruppenrichtlinie mit der richtigen Organisationseinheit in Ihrem Netzwerk zu verknüpfen, damit diese aktiv wird.