Kategorie-Archiv: Microsoft

Windows speichert Benutzerkontokennwörter („Anmeldeinformationen“) grundsätzlich als Hash. Das ist auch eine gute Idee, denn wenn Angreifer die SAM-Datenbank erbeuten hilft diese nicht beim Einbruch weiter. In der Theorie.

Normalerweise, also „by default“ werden dabei sowohl einen LAN Manager-Hash („LM-Hash“) als auch einen Windows NT-Hashwert („NT-Hash“) abgelegt. Windows speichert beide Hashes dann entwerder in der lokalen Security Accounts Manager Datenbank (SAM)-Datenbank oder im Active Directory.

Der LM-Hash ist bekanntlich eher schwach und SEHR anfällig für Angriffe, die das Plaintext-Kennwort extrahieren. Am besten verhindert man also, dass Windows den LM-Hash überhaupt speichert. Das ist seit ein paar Jahren (~2012) auch praktisch nicht mehr nötig und nur noch zur Abwärtskompatiblität da. Windows 10 hat das Flag beispielsweise schon ab der Installation gesetzt.

Da eine lebendige Domäne aber selten aus den aktuellensten PCs und Betriebssystemen besteht, lautet unsere aktuelle Empfehlung „auf Nummer sicehr“ zu gehen.

Lösung

Man kann Windows die Speicherung der LM-Hashes per GPO verbieten. Achtung, selbige muss auch auf DCs angewendet werden. Die „Default Domain Policy“ ist zum Beispiel ein guter Ort für eine solche Änderung.

Computerkonfiguration > Windows-Einstellungen > Sicherheitsrichtlinien > Lokale Richtlinien > Sicherheitsoptionen > „Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern“

⚠️ Achtung: Bereits bestehende Hashes werden dadurch nicht sofort entfernt. Das passiert erst bei der nächsten Kennwortänderung.

Den Haken „Dynamische Udpates“ in den Eigentschaften einer Zone haben vermutlich viele Admins gesetzt. Wenn man die Einstellungen zu DNS-Updates ändern will, kann man das in den Eigenschaften auch komfortabel tun.

Wenn es aber um sehr viel Zonen und dere Einstellunge geht, ist die Kommandozeile hilfreich …

Lösung

Das geht mit dem tool dnscmd mit diesen Parametern:

dnscmd /config <ZONE> /AllowUpdate 1

Genauso funktioniert das natürlich auch bei Reversen Lookupzonen. Wenn man, wie ich, zu faul ist diese abzutippen, bietet sich die Auflistung aller Zonen an:

dnscmd /enumzones

In der Textausgaben (ist auch noch filterbar, zum Beispiel mit /primay) kann man dann beliebig mit einer for Schleife herumaktualisieren, eine bearbeitbare Liste erstellen oder nach bestimmten Namen suchen (find/grep).

Wenn man eine Windows CA erfolgreich migriert hat (Backup+Restore), kommt beim Versuch den CertSvc-Webdienst via ServerManger zu installieren die folgende Fehlermeldung:

Webregistrierung der Zertifizierungsstelle: Konfiguration fehlgeschlagen.
Die Einrichtung der Active Directory-Zertifikatdienste ist mit folgendem Fehler fehlgeschlagen: Der Parameter ist falsch. 0x80070057 (WIN32: 87)

Das passiert nach einer Migration und auch nur mit dem Webdienst – den man korrekterweise erst nach der CA „dazuinstalliert“. Natürlich ist das ein bekannter und bisher (Windows Server 2003-2022) ungepatchter Bug.

Lösung

Das Problem besteht darin, dass der Wert von SetupStatus in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration noch den Wert „hat“Web ist installiert“ hat. Wenn das der Fall ist, scheitert der Windows ServerManager.

Der Hexadezimalwert 6003 sagt „ist schon installiert“
Der Hexadezimalwert 6001 sgat „ist frei“

Man ändere also mal eben den Wert von SetupStatus der Registrierung auf 6001 und dann läuft die Installation des „Zertifikatsregistrierungs-Webdienstes“ durch.

Update

Ich habe soeben herausgefunden, das das sogar an der Kommandozeile vie certutil möglich ist:

certutil -setreg config\setupstatus 0x6001

Es wird noch besser, es gibt sogar eine named procedure in certutil dazu, die ebenfalls genau das selbe tut:

certutil -setreg config\setupstatus - SETUP_CLIENT_FLAG