CheckMK : local check für Mailstore

Ich hab hier einen kleinen Check in Powershell für Mailstore gebaut. Hier wird ein Job überprüft ob das Ergebnis "succeeded" ist wenn ja ist der Job ok. Sollte etwas anderes als Rückgabewert kommen wird ein Fehler ausgegeben.

In der CheckMK Oberfläche sieht das ganze dann so aus:


Hier gehts zum github Repo : https://github.com/Mokkujin/Checks-for-Check_MK

Quelle:
https://help.mailstore.com/de/server/PowerShell_API-Wrapper_Tutorial
https://help.mailstore.com/en/server/MailStore_Server_Service_Configuration
https://help.mailstore.com/de/server/Administration_API_-_Function_Reference

Windows: Server hängt mit "System wird vorbereitet. Schalten Sie den Computer nicht aus"

Problem:
Nach der Installation von mehreren Microsoft Patches auf einem Server musste ich diesen neu starten. Diese blieb jedoch bei der Meldung hängen und ich habe fast 20 Minuten gewartet, ohne das sich etwas tut:

Ich wollte den Server nicht einfach "hart" ausschalten...

Lösung:
Von einem anderen Server aus konnte ich mir die Dienste anzeigen lassen. Hier war der Dienst "Windows Modules Installer" im Status "wird beendet" und wurde aber nie beendet. Also müssen wir diesen remote beenden. Dazu habe ich das Windows-eigene Tool "Taskkill" genommen und den Installer-Dienst remote mit folgendem Befehl beendet:
taskkill /S hostname /IM trustedinstaller.exe
Nach wenigen Sekunden war der Dienst beendet und der Neustart wurde problemlos durchgeführt.
Man kann das auch mit PSEXEC von dne Sysinternals Tools machen.

Windows Server: Fehlermeldung ERROR_INVALID_PRINTER_NAME, wenn man einen Windows-Druckserver über einen DNS Alias (CNAME) anspricht

Problem:
Damit ich nicht immer die Drucker mit einem anderen Servernamen verbinden muss, habe ich mir gedacht, dass ich einen DNS-Alias (CNAME) für meinen Microsoft Windows Druckserver erstelle und den eigentlichen Druckserver dahinter "verstecke". Leider habe ich dann ständig Fehlermeldungen erhalten, wenn ich die Drucker verbinden wollte: ERROR_INVALID_PRINTER_NAME

Lösung:
Es gibt tatsächlich eine Lösung dafür. Man muss folgenden Registry-Key auf dem Druckserver erstellen und nach einem Neustart lässt dich der Druckserver über den DNS-Alias (CNAME) problemlos ansprechen.
Folgenden Key bitte setzen:

[HKLM\SYSTEM\CurrentControlSet\Control\Print]
"DnsOnWire"=dword:00000001


Danach bitte den Spooler-Dienst auf dem Server neu starten, damit die Einstellung wirksam wird.

Quelle:
Microsoft DOCS: Error message when you try to connect to a printer by using an alias (CNAME) resource record: Windows couldn't connect to the printer

Server 2003 R2: Aufgaben auf ehemaligen DC laufen nicht mehr - 0x8007000d: Die Daten sind ungültig

Problem:
Auch wenn der Server 2003R2 schon extrem angestaubt ist, hat man manchmal doch noch damit zu tun. Ich hatte einen 2003R2 Domain Controller, den ich gegen ein aktuelles System getauscht habe aber vorerst als Memberserver weitergetrieben musste. Auf dem 2003R2 Server liefen einige geplante Aufgaben. Nachdem ich den Server die Domain Controller Rolle entfernt hatte, liefen alle Aufgaben auf den Fehler "0x8007000d: Die Daten sind ungültig". Beim manuellen Starten der Aufgabe habe ich folgenden Fehler erhalten:

Fehler beim Initialisieren der Seite "Allgemein".
Der genaue Fehler ist: 0x8007000d: die Daten sind ungültig.
Abrufen der Taskkontoinformationen ist ein Fehler aufgetreten. Sie können weiterhin das Task-Objekt bearbeiten, aber nicht ändern.


Lösung:
Das Problem scheint wirklich durch das Herunterstufen des DCs zukommen. Es gibt einige Lösungsansätze im Internet, aber folgender Workaround hat bei mir geholfen:

- Öffnen Sie den Pfad "C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Microsoft\Crypto\RSA"
- Dort finden Sie einen Ordner "S-1-5-18"
- Ich habe mal eine Sicherheitskopie des Ordners angelegt
- Dann löschen Sie die Dateien in diesem Ordner, aber nicht den Ordner selbst
- Starten Sie den Taskplaner-Dienst neu
- Danach öffnen Sie die Eigenschaften der Aufgaben und geben die Anmeldedaten im Task erneut ein
- Danach laufen die Aufgaben wieder ohne Probleme

.NET Anwendung baut keine Verbindung zum Webserver auf - TLS Konfiguration anpassen

Problem:
Ich hatte das Problem, dass unsere .NET Anwendung für das Artikel-Update des Webshops plötzlich nicht mehr funktioniert hat - keine Verbindung zum Server mehr. Nach etwas Recherche hat sich gezeigt, dass es daran lag, dass die Webseite nur noch TLS 1.2 und 1.3 spricht aber unsere Anwendung mit TLS 1.0 die Verbindung herstellen und die Daten hochladen wollte.

Lösung:
Nach etwas Suche habe ich habe TLS 1.1 und TLS 1.2 am Windows-Client per Default aktiviert (TLS 1.3 ist noch nicht Standard). Das funktioniert über Registry-Keys am einfachsten (optional GPO bauen):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Client]
„DisabledByDefault“ = dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client]
„DisabledByDefault“ = dword:00000000


Sollten die Schlüssel „TLS 1.1“ und „TLS 1.2“ und „Client“ noch nicht existieren, dann bitte anlegen.

Damit aber noch nicht genug, da .NET Framework sich NICHT an den Systemstandard hält, sondern seine eigene TLS-Konfiguration macht.
Man kann das aber ändern, indem man ein paar Registry-Tweaks setzt, damit .NET das Systemdefault-TLS-Protokoll verwendet. Wichtig hier ist zuprüfen, ob die .NET Anwendung 32- oder 64-Bit ist und entsprechend die Keys setzen.

Hier für x64 bzw. Eine 64-Bit .NET-Anwendung

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001


Und für x86 bzw. eine 32-Bit .NET-Anwendung

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001


Windows-Client neu starten und damit sollte die Verbindung wieder laufen und die Verbindung zur Webapplikation wieder funktionieren.

Quellen:
Microsoft: So aktivieren Sie TLS 1.1 oder TLS 1.2 als Standard sichere Protokolle WinHTTP in Windows Update
Aktualisieren und Konfigurieren von .NET Framework zur Unterstützung von TLS 1.2.

Zertifikate: Erstellen eines Self Signed Certificate mittels Powershell (z.B. RDS Published Apps)

Problem:
Ich habe eine Published App auf einem Server 2016 mit RDS. Für das Starten der App ohne Fehlermeldung benötige ich ein Zertifikat. Wenn ich das über die GUI erstelle, dann ist dieses immer nur 1 Jahr gültig. Das ist zwar sicherheitstechnisch korrekt, aber für eine Applikation für 10 Mitarbeiter jedes mal ein größerer Aufwand.

Lösung:
Ich erstelle auf dem RDS Server der Published App einfach ein Self Signed Certificate mittels Powershell mit entsprechenden Namen und angepasster Gültigkeitsdauer.

Hier der Befehl:
New-SelfSignedCertificate -Subject “server.domain.local” -DNSName “server.domain.local”, “rds.domain.local”, "Netbiosname Server" -CertStoreLocation “cert:\LocalMachine\My” -KeyAlgorithm RSA -KeyLength 2048 -KeyExportPolicy Exportable -NotAfter (Get-Date).AddYears(5)


Erklärungen:
DNSName: Hier geneben Sie alle FQDNs kommegetrennt an, über die der Server erriechbar sein soll. Nettes Feature...ich kann hier auch IP-Adressen und NetBIOS-Namen angeben, da ich nicht den Restriktionen einer öffentlichen Zertifikatsstelle unterliege.

-KeyExportPolicy: Das Zertifikat bzw. der private Schlüssel sollte exportierbar sein, falls man diesen sichern möchte.

-NotAfter: Hier kann man ein Gültigkeitsdatum des Zertifikats angeben. Ich selbst nehme immer den heutigen Tag (Get-Date) und Addiere x Jahre dazu (hier z.B. 5 Jahre).

Das Zertifikat verteile ich dann per GPO an alle Clients und setze noch den SHA1-Thumbprint als vertrauenswürdig um die unschöne Fehlermeldung zu unterdrücken.
Das habe ich hier erklärt: RDS Terminalserver: Published App meldet beim Starten "Unbekannten Hersteller"
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)