SpecOps Password Policy: Sichere Passwörter für das Active Directory


    Tags: , ,

    Authentifizierung über Username und PasswortMicrosoft sieht für das Active Directory nur be­schränkte Mittel vor, um sichere Pass­wörter zu erzwingen. Der schwe­dische Her­steller Specops Software schließt diese Lücke mit Pass­word Policy, das ein Manage­ment der Benutzer­kenn­wörter über ein ausge­klügeltes Regel­werk und eine zentrale Blacklist erlaubt.

    Microsoft möchte zwar Passwörter als alleinige Methode zur Authenti­fizierung möglichst bald abschaffen, aber viele Unter­nehmen werden intern wohl noch längere Zeit daran festhalten. Umso wichtiger ist es daher, dass Admins bekannte Schwächen der Kennwörter weitgehend eliminieren.

    Das Passwort-Dilemma

    Zu den wunden Punkten gehören triviale Passwörter, die sich leicht erraten lassen, vor allem wenn man das soziale Umfeld eines Benutzers kennt. Umgekehrt bringt es nichts, wenn man Anwender zu übermäßig komplexen Kennwörtern zwingt, weil sie sich diese dann nicht merken können. Die Folge sind vermehrte Helpdesk-Anfragen oder die Unsitte, das Passwort als Notiz an den Monitor zu kleben.

    Die Bordmittel des Active Directory sehen grundsätzlich zwei Mittel vor, um Regeln für neue Passwörter vorzugeben. Dabei handelt es zum einen um die Default Domain Policy mit einigen vorgegebenen Kriterien, denen Passwörter genügen müssen.

    Limitierungen der Bordmittel

    Zum anderen kamen mit Server 2008 die Fine-grained Password Policies hinzu, die man einzelnen Benutzern oder Gruppen zuweisen und damit für diese Objekte die Domain-Passwort­regeln übersteuern kann. Diese Policies lassen sich aber nicht an OUs zuweisen.

    Windows-eigene Mittel zur Erzwingung sicherer Passwörter, hier für eine Fine-grained Password Policy.

    Beide Mechanismen bieten die gleichen Einstellungen, um Passwörter abzusichern. Dazu zählen deren minimales und maximales Alter sowie Ein­schränkungen bei ihrer Wieder­verwendung. Die Vorgaben für den eigentlichen Aufbau der Kennwörter beschränken sich auf die Mindestlänge und die Komplexitäts­anfor­derungen, welche sich nicht konfigurieren lassen.

    Zusätzliche Optionen durch SpecOps Password Policy

    SpecOps Password Policy (SPP) bietet eine ganze Reihe zusätzlicher Möglichkeiten, starke Passwörter zu erzwingen. Dies beginnt damit, dass sich die Komplexitäts­vorgaben fein differenziert anpassen lassen. Neben der minimalen und maximalen Passwort­länge zählt dazu, dass Admins bestimmen können, wie viele Buchstaben und nicht-alphabetische Zeichen ein Kennwort enthalten muss.

    Regeln, die bestimmen, aus welchen und wie viele Zeichen sich Passwörter zusammensetzen müssen.

    Außerdem kann man ausschließen, dass der Name des Users ganz oder teilweise im Passwort enthalten ist, dass Zeichen direkt hinter­einander wiederholt werden oder Ziffern am Anfang oder Ende vorkommen. Noch genauere Kontrolle erhalten Admins durch die Definition eines regulären Ausdrucks, der den zulässigen Aufbau von Kenn­wörtern bestimmt.

    Prüfung anhand von Wörterbüchern

    Eine gängige Angriffs­methode auf Passwörter besteht im Einsatz von Wörterbüchern, die nach und nach durchprobiert werden. Solchen Aktivitäten kann man zwar durch Richtlinien für die Konto­sperrung vorbeugen, aber diese haben wieder den Nachteil, dass sie sich für Denial-of-Service-Attacken missbrauchen lassen.

    SpecOps begegnet dieser Gefahr stattdessen durch die Integration mehrerer Dictionaries, die im Admin-Client herunter­geladen und in die Policy eingebunden werden können. Zu solchen, die der Hersteller selbst bereitstellt, kommen Listen von Kennwörtern, die Hacker von Websites wie LinkedIn oder Gawker entwendet und im Internet zugänglich gemacht haben.

    SPP kann diverse Wörterbücher integrieren, gegen die neue Passwörter geprüft werden.

    SPP kann so verhindern, dass Benutzer ein Passwort verwenden, das in einem der hinterlegten Wörterbücher enthalten ist.

    Managed Password Blacklist

    Der Hersteller sieht in den Dictionaries aber primär ein Überbleibsel aus früheren Generationen des Produkts. Stattdessen setzt SpecOps nun vor allem auf eine regelmäßig aktualisierte Blacklist in der Cloud, in die das Unternehmen kom­promittierte Kennwörter aus unter­schiedlichen Quellen einpflegt.

    Allerdings prüfen Domain-Controller beim Wechsel des Kennworts dieses nicht direkt anhand der Cloud-Datenbank, sondern auf Basis eines lokal zwischen­gespeicherten Subsets. SPP hält für diesen Zweck die häufigsten Passwörter in Form von Hashes in einem lokalen Cache vor.

    Auf Wunsch kann das Tool aber danach die vollständige Datenbank in der Cloud abfragen, allerdings erfolgt dies asynchron. Die Hashes werden dabei mehrfach verschlüsselt übertragen, um sie gegen Angriffe zu schützen.

    Erweist sich ein neues Kennwort daraufhin als ungeeignet, dann verständigt Password Policy den Admin oder den User per Mail. In diesem Fall ließe sich ein erneuter Wechsel des Passworts beim nächsten Logon erzwingen.

    Passphrasen als Alternative

    Erhöhte Anforderungen an den Aufbau und die Wieder­verwendung von Kennwörtern erhöhen zwar die Sicherheit, machen es Benutzern zunehmend schwer, entsprechende Passwörter zu finden und im Gedächtnis zu behalten.

    Als Alternative unterstützt SpecOps daher so genannte Passphrases, die aus einem ganzen Satz oder zumindest aus mehreren Wörtern bestehen. Beliebt sind in diesem Zusammen­hang etwa Sprich­wörter oder gängige Rede­wendungen, die sich Anwender viel leichter merken können als kryptische Kennwörter.

    Kriterien, denen Passphrasen entsprechen müssen, können weniger streng sein als bei Passwörtern.

    Für Passphrasen lassen sich in SPP eigenen Regeln festlegen. Nachdem sich sehr lange Zeichen­folgen nur mit viel höherem Aufwand knacken lassen, kann man hier die Vorgaben für die Verwendung von Ziffern und Sonder­zeichen lockern.

    Konfiguriert man in SPP Regeln für Kennwörter und Passphrasen, dann unterscheidet die Software die beiden anhand ihrer Länge. Die Vorgabe für Passphrasen liegt bei 20 Zeichen, mindestens erforderlich sind 15. Alles was diesen konfigurierten Wert erreicht oder überschreitet, wird mit der Regel für Passphrasen geprüft.

    Passwörter und Passphrasen können parallel genutzt werden.

    Diese kann ebenfalls den Einsatz von Klein- und Großbuchstaben, Ziffern und Sonder­zeichen erzwingen. Zudem lassen sich Muster durch einen regulären Ausdruck vorgeben.

    Wiederverwendung von Kennwörtern

    Wie bei den Bordmitteln können Admins in den allgemeinen Einstellungen festlegen, ob und wann User bisherige Kennwörter erneut verwenden dürfen. Dabei lassen sich inkrementelle Passwörter, etwa durch Hochzählen über angehängte Zahlen, oder das Recycling von Wort­bestand­teilen unterbinden.

    In den allgemeinen Einstellungen kann der Admin die Wiederverwendung von Passwörtern beschränken.

    Flexibles Ablaufdatum

    Wie beim integrierten Passwort­system von Windows sieht auch SpecOps die Definition eines Ablaufdatums vor, nach dem Benutzer ihr Kennwort erneuern müssen. SPP geht aber auch hier über die integrierten Möglich­keiten hinaus, indem man die Gültigkeits­dauer von der Länge des Passworts abhängig machen kann.

    Das Ablaufdatum von Kennwörtern lässt sich an ihre Länge knüpfen.

    Microsoft ist jedoch mit der Security Baseline für Windows 10 1903 davon abgekommen, Benutzer zum regel­mäßigen Wechsel der Kennwörter zu zwingen und spricht sich auch bei Office 365 dagegen aus. Eine Ausnahme bildet natürlich der Fall, dass ein Kennwort kompromittiert wurde. Dann sollte man es schleunigst ersetzen.

    Funktionsweise von Password Policy

    SPP erfordert eine Komponente namens Sentinel auf jedem Domänen-Controller, die dort als Passwortfilter läuft und neue Kennwörter auf ihre Über­einstimmung mit den definierten Regeln prüft. Die Policies selbst werden den Benutzern über GPOs zugewiesen, so dass theoretisch jede OU eigene Passwort­regeln erhalten kann.

    Aufbau und Funktion von SpecOps Password Policy

    Die Konfiguration der Regeln erfolgt über ein Plugin für den Gruppen­richtlinien-Editor. Legt man dort eine neue Policy an, dann startet ein Assistent, der die Auswahl einer Schablone anbietet, auf deren Basis er die Passwort­regeln erstellt.

    Diese beruhen auf den Empfehlungen diverser Organisationen, darunter findet sich auch eine von Microsoft. Alternativ kann man die neuen Regeln von der Default Domain Policy ableiten oder von Grund auf selbst definieren.

    Erstellen einer Passwortregel im GPO-Editor auf Basis einer Vorlage

    Die Vorgabewerte aus einem Template lassen sich dann in den folgenden Dialogen für die allgemeinen Einstellungen, das Ablaufdatum sowie für die Passwort- und Passphrasenregeln anpassen.

    Aufschlussreiche Meldungen am Client

    Wenn man neue Passwörter anhand relativ strenger Regeln prüft, dann wird SPP immer wieder welche abweisen, weil sie nicht sicher genug sind. In diesem Fall sollte der Benutzer erfahren, welche Kriterien das Kennwort nicht erfüllt hat, damit er eine erneute Fehleingabe vermeiden kann.

    Der Windows-eigene Mechanismus für Passwortregeln begnügt sich aber mit der lapidaren Meldung, wonach das Kennwort gegen die Vorgaben der Domain Policy verstoße. SpecOps erweitert das System zu diesem Zweck durch einen optionalen Authentication Client auf den Endpunkten. Er gibt detaillierte Informationen zu den Komplexitäts­anforderungen aus, wenn ein neues Kennwort abgelehnt wird.

    Detaillierte Angaben durch den Authentication Client, warum ein Kennwort abgelehnt wurde

    Allerdings zeigt sich hier, dass die Passwort­regeln von SPP immer dem Filter in der Default Domain Policy nachgeschaltet sind. Ist ein Kennwort zu schwach für die Windows-eigenen Kriterien, dann wird es bereits vom System selbst abgelehnt und Benutzer erhalten die gewohnte Meldung. Daher besteht eine Lösung darin, die Anforderungen in der Domain Policy so weit zu abzusenken, dass sie von fast allen Kennwörtern erfüllt werden.

    Installation

    SpecOps Password Policy kommt mit einem Setup-Programm, das die genannten Komponenten der Reihe nach einrichtet. Im ersten Schritt kommen die Administration Tools zum Zug. Es handelt sich dabei zum einen um eine grafische Konsole, mit der man einige globale Einstellungen für die Domäne konfiguriert, einen Überblick über alle vorhandenen Policies und Sprachdateien erhält oder neue Templates erstellt.

    Mehrstufiges Setup zur Installation aller Komponenten

    Zu den Werkzeugen gehört zum anderen das erwähnte Add-in für den GPO-Editor, den man im gleichen Durchgang installiert wie die Domain Administration. Der System­verwalter konfiguriert damit die Policies für die einzelnen Passwort-GPOs.

    Für die Installation der Server-Komponente muss man eine Netzfreigabe einrichten oder eine bestehende auswählen, wenn man den Wizard nutzt. Von dort aus wird sie auf alle beschreibbaren Domänen-Controller verteilt, die man danach neu starten muss.

    Für den Authentication Client sieht SpecOps eine Installation über Gruppen­richtlinien vor. Dazu wählt man ein vorhandenes GPO aus oder legt ein neues an. Dieses wird dann automatisch für die Verteilung des Clients konfiguriert.

    Deployment des Authentication Clients über Gruppenrichtlinien

    Die Komponente lädt man separat als 32- und 64-Bit-MSI auf eine Netzfreigabe. Der Client lässt sich bei Bedarf ebenfalls über ein GPO konfigurieren, das erforderliche ADMX-File erhält man auf der Website des Herstellers.

    Fazit

    Wenn sich Unternehmen auf die Authentifizierung am Active Directory nur durch Username und Passwort verlassen, dann kann SpecOps Password Policy die Sicherheit dieses Verfahrens deutlich erhöhen.

    Durch die Integration des Tools mit den Gruppen­richtlinien dürften die meisten Admins schnell damit zurecht­kommen. Die Installation umfasst zwar mehrere Komponenten, fällt aber dank eines gut strukturierten Setup-Programms relativ einfach. Etwas kniffliger ist das Zusammen­spiel mit der Default Domain Policy, um den Authentication Client ins Spiel zu bringen.

    Verfügbarkeit

    SpecOps bietet eine Trial-Version der Software auf seiner Website an. Allerdings erhält man nach der Registrierung keinen Download-Link, sondern der Interessent muss darauf warten, dass sich das Sales-Team bei ihm meldet und eine kurze Einführung in das Produkt gibt.

    Ein untypisches Verhalten zeigt der Hersteller auch bei der Preisauskunft. Informationen zu den Kosten der Software, die pro User und Domäne abgerechnet wird, bekommt man nur auf Anfrage. Hintergrund dafür sei, dass man sich die nötige Flexibilität in der Preisgestaltung für die jeweilige Umgebung des Kunden erhalten wolle.

    Schwer nachvoll­ziehbar ist zudem, warum eine Kernfunktion von Password Policy, nämlich die vom Hersteller gepflegte Blacklist, nur als Zusatzoption verfügbar ist und separat lizenziert werden muss.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Wolfgang Sommergut
    Wolfgang Sommergut hat lang­jährige Erfahrung als Fach­autor, Berater und Kon­ferenz­sprecher zu ver­schie­denen Themen der IT. Da­ne­ben war er als System­ad­mi­ni­stra­tor und Con­sultant tätig.
    // Kontakt: E-Mail, XING, LinkedIn //

    Ähnliche Beiträge

    Weitere Links