Ein Mensch ist bekanntlich ein faules Wesen.
Und das besonders, wenn es um die Auswahl eines sicheren Passworts geht.
Ich denke, jeder Administrator hat irgendwann mit dem Problem zu kämpfen, schwache und gängige Passwörter zu verwenden. Dieses Phänomen tritt häufig unter den Führungsetagen von Unternehmen auf. Ja, genau dort, wo Zugang zu geheimen oder wirtschaftlichen Informationen besteht, und es äußerst unerwünscht wäre, die Folgen eines Datenlecks oder Passwort-Hacks und weiterer Vorfälle zu beheben.
In meiner Praxis gab es einen Fall, in dem in einer Active Directory-Domäne mit aktivierter Passwortpolitik die Buchhalter auf die Idee kamen, dass ein Passwort wie „Pas$w0rd1234“ hervorragend den Anforderungen der Richtlinie entsprach. Das Ergebnis war die allgemeine Verwendung dieses Passworts überall. Es unterschied sich manchmal nur in der Ziffernfolge.
Ich wünschte mir, nicht nur die Passwortpolitik aktivieren und die Zeichenauswahl festlegen zu können, sondern auch die Möglichkeit zu haben, durch ein Wörterbuch zu filtern, um die Verwendung solcher Passwörter auszuschließen.
Microsoft informiert uns freundlich über den Link, dass jeder, der in der Lage ist, einen Compiler und eine IDE richtig zu bedienen und C++ korrekt auszusprechen, in der Lage ist, selbst eine benötigte Bibliothek zu kompilieren und nach eigenem Ermessen zu verwenden. Ihr demütiger Diener ist dazu nicht fähig, daher musste ich nach einer fertigen Lösung suchen.
Nach einer langen Stunde der Suche wurden mir zwei Lösungsmöglichkeiten präsentiert. Dabei spreche ich natürlich von einer OpenSource-Lösung. Denn die kostenpflichtigen Varianten gibt es von A bis Z.
Option Nr. 1.
Es gab seit etwa zwei Jahren keine Commits mehr. Der native Installer funktioniert nur sporadisch, man muss von Hand nachbessern. Er erstellt seinen eigenen Dienst. Beim Aktualisieren der Passwortdatei wird der DLL nicht automatisch die geänderte Datei zugeführt; man muss den Dienst stoppen, auf die Timeout warten, die Datei bearbeiten und den Dienst erneut starten.
Nicht optimal!
Option Nr. 2.
Das Projekt ist aktiv, lebt und muss nicht einmal angestoßen werden.
Die Installation des Filters besteht darin, zwei Dateien zu kopieren und mehrere Registrierungseinträge zu erstellen. Die Passwortdatei ist nicht im Lock, das heißt – sie ist bearbeitbar und gemäß der Idee des Projektentwicklers wird sie einfach einmal pro Minute ausgelesen. Zudem kann durch zusätzliche Registrierungseinträge eine erweiterte Anpassung sowohl des Filters als auch der Passwortpolitik vorgenommen werden.
Also.
Gegeben: Active Directory-Domain test.local
Test-Workstation Windows 8.1 (für die Aufgabenstellung – nicht relevant)
PassFiltEx Passwortfilter
- Laden Sie die neueste Version über den Link herunter
- Kopieren Sie PassFiltEx.dll in C:\Windows\System32 (oder %SystemRoot%System32).
Kopieren Sie PassFiltExBlacklist.txt in C:\Windows\System32 (oder %SystemRoot%System32). Bei Bedarf können Sie es mit Ihren eigenen Vorlagen ergänzen
- Bearbeiten Sie den Registrierungsschlüssel: HKLMSYSTEMCurrentControlSetControlLsa => Notification Packages
Hinzufügen PassFiltEx am Ende der Liste. (Die Erweiterung muss nicht angegeben werden.) Die vollständige Liste der verwendeten Pakete zur Überprüfung sieht so aus: „rassfm scecli PassFiltEx«.
- Starten Sie den Domänencontroller neu.
- Wiederholen Sie das oben genannte Verfahren für alle Domänencontroller.
Es können auch folgende Registrierungseinträge hinzugefügt werden, was größere Flexibilität bei der Nutzung dieses Filters bietet:
Abschnitt: HKLMSOFTWAREPassFiltEx — wird automatisch erstellt.
- HKLMSOFTWAREPassFiltExBlacklistFileName, REG_SZ, Standardwert: PassFiltExBlacklist.txt
BlacklistFileName — ermöglicht die Angabe eines benutzerdefinierten Pfades zur Datei mit Passwortmustern. Wenn dieser Registrierungseintrag keinen Wert hat oder nicht existiert, wird der Standardpfad verwendet, und zwar — %SystemRoot%System32. Es kann sogar ein Netzwerkpfad angegeben werden, ABER man muss daran denken, dass die Musterdatei klare Berechtigungen für Lesen, Schreiben, Löschen und Ändern haben muss.
- HKLMSOFTWAREPassFiltExTokenPercentageOfPassword, REG_DWORD, Standardwert: 60
TokenPercentageOfPassword — ermöglicht die Angabe des prozentualen Anteils der Maske im neuen Passwort. Standardmäßig beträgt der Wert 60 %. Wenn beispielsweise ein prozentualer Anteil von 60 angegeben wird und in der Musterdatei die Zeichenfolge starwars enthalten ist, wird das Passwort Starwars1! abgelehnt, während das Passwort starwars1!DarthVader88 akzeptiert wird, da der prozentuale Anteil der Zeichenfolge im Passwort weniger als 60 % beträgt.
- HKLMSOFTWAREPassFiltExRequireCharClasses, REG_DWORD, Standardwert: 0
RequireCharClasses — ermöglicht es, die Passwortanforderungen im Vergleich zu den Standardanforderungen für die Passwortkomplexität von ActiveDirectory zu erweitern. Die integrierten Komplexitätsanforderungen erfordern 3 von 5 möglichen verschiedenen Symbolarten: Großbuchstaben, Kleinbuchstaben, Ziffern, Sonderzeichen und Unicode. Mit diesem Registrierungseintrag können Sie Ihre eigenen Anforderungen an die Passwortkomplexität festlegen. Der anzugebende Wert ist eine Bitmaske, wobei jedes Bit einer entsprechenden Potenz von zwei entspricht.
Das bedeutet: 1 = Kleinbuchstabe, 2 = Großbuchstabe, 4 = Ziffer, 8 = Sonderzeichen, und 16 = Unicode-Zeichen.
Somit, bei einem Wert von 7 lauten die Anforderungen „Großbuchstabe AND Kleinbuchstab AND Ziffer“; und bei einem Wert von 31 sind es „Großbuchstabe AND Kleinbuchstabe AND Ziffer AND Sonderzeichen AND Unicode-Zeichen“.
Man kann sogar kombinieren – 19 = „Großbuchstabe AND Kleinbuchstabe AND Unicode-Zeichen“. 
Eine Reihe von Regeln für die Erstellung von Vorlagendateien:
- Vorlagen sind nicht case-sensitive. Daher wird der Eintrag in der Datei starwars и StarWarS als identischer Wert angesehen.
- Die Blacklist-Datei wird alle 60 Sekunden neu gelesen, sodass sie problemlos bearbeitet werden kann; nach einer Minute werden die neuen Daten bereits vom Filter verwendet.
- Derzeit wird keine Unicode-Unterstützung für die Musterprüfung angeboten. Das bedeutet, dass Unicode-Zeichen in Passwörtern verwendet werden können, der Filter jedoch nicht arbeitet. Das ist nicht kritisch, da ich keine Benutzer gesehen habe, die Passwörter in Unicode verwenden.
- Es ist ratsam, leere Zeilen in der Vorlagendatei zu vermeiden. Im Debug-Modus wird dann ein Fehler sichtbar, wenn Daten aus der Datei geladen werden. Der Filter funktioniert, aber warum zusätzliche Ausnahmen erzeugen?
Für das Debugging enthalten das Archiv Batch-Dateien, mit denen ein Protokoll erstellt werden kann, das dann zum Beispiel mit
Dieser Passwortfilter verwendet Event Tracing for Windows.
Der ETW-Anbieter für diesen Passwortfilter ist 07d83223-7594-4852-babc-784803fdf6c5. So kann beispielsweise das Ereignistracing nach dem nächsten Neustart konfiguriert werden:
logman create trace autosessionPassFiltEx -o %SystemRoot%DebugPassFiltEx.etl -p "{07d83223-7594-4852-babc-784803fdf6c5}" 0xFFFFFFFF -ets
Das Tracing wird nach dem nächsten Systemneustart gestartet. Um zu stoppen:
logman stop PassFiltEx -ets && logman delete autosessionPassFiltEx -ets
Alle diese Befehle sind in den Skripten StartTracingAtBoot.cmd и StopTracingAtBoot.cmd.
Für eine einmalige Überprüfung der Filterfunktion kann StartTracing.cmd и StopTracing.cmd.
Um die Debug-Ausgabe dieses Filters bequem zu lesen, Microsoft Message Analyzer werden die folgenden Einstellungen empfohlen:
Beim Stoppen des Logs und der Analyse in Microsoft Message Analyzer sieht alles ungefähr so aus:
Hier sieht man, dass versucht wurde, ein Passwort für den Benutzer festzulegen — das zeigt uns das magische Wort SET im Debug. Und das Passwort wurde abgelehnt, da es in der Vorlage-Datei vorhanden ist und mehr als 30% Übereinstimmung im eingegebenen Text aufweist.
Bei einem erfolgreichen Versuch, das Passwort zu ändern, sehen wir Folgendes:
Es gibt ein gewisses Unbehagen für den Endbenutzer. Wenn man versucht, ein Passwort zu ändern, das in der Vorlage-Datei steht, unterscheidet sich die Bildschirmmeldung nicht gediegener von der Standardmeldung, wenn die Passwortpolitik nicht erfüllt wird.
Seien Sie also auf Anrufe und Schreie vorbereitet: „Ich habe das Passwort korrekt eingegeben, und es funktioniert nicht.“
Fazit.
Diese Bibliothek ermöglicht es, die Verwendung einfacher oder standardmäßiger Passwörter im Active Directory zu verbieten. Sagen Sie 'Nein!' zu Passwörtern wie: 'P@ssw0rd', 'Qwerty123', 'ADm1n098'.
Ja, die Nutzer werden Ihre Sorge um ihre Sicherheit und die Notwendigkeit, sich komplizierte Passwörter auszudenken, sicherlich zu schätzen wissen. Und möglicherweise werden die Anrufe und Anfragen um Hilfe mit Passwörtern zunehmen. Aber für Sicherheit muss man bezahlen.
Links zu den verwendeten Quellen:
Artikel von Microsoft zur benutzerdefinierten Passwortfilter-Bibliothek:
PassFiltEx:
Link zur Veröffentlichung:
Passwortlisten:
DanielMiessler listen:
Wortliste von weakpass.com:
Wortliste vom berzerk0-Repo:
Microsoft Message Analyzer:
Quelle: habr.com
