Tags: Authentifizierung, Active Directory, Sicherheit
Microsoft sieht für das Active Directory nur beschränkte Mittel vor, um sichere Passwörter zu erzwingen. Der schwedische Hersteller Specops Software schließt diese Lücke mit Password Policy, das ein Management der Benutzerkennwörter über ein ausgeklügeltes Regelwerk und eine zentrale Blacklist erlaubt.
Microsoft möchte zwar Passwörter als alleinige Methode zur Authentifizierung möglichst bald abschaffen, aber viele Unternehmen 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-Passwortregeln übersteuern kann. Diese Policies lassen sich aber nicht an OUs zuweisen.
Beide Mechanismen bieten die gleichen Einstellungen, um Passwörter abzusichern. Dazu zählen deren minimales und maximales Alter sowie Einschränkungen bei ihrer Wiederverwendung. Die Vorgaben für den eigentlichen Aufbau der Kennwörter beschränken sich auf die Mindestlänge und die Komplexitätsanforderungen, 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ätsvorgaben fein differenziert anpassen lassen. Neben der minimalen und maximalen Passwortlänge zählt dazu, dass Admins bestimmen können, wie viele Buchstaben und nicht-alphabetische Zeichen ein Kennwort enthalten muss.
Außerdem kann man ausschließen, dass der Name des Users ganz oder teilweise im Passwort enthalten ist, dass Zeichen direkt hintereinander 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 Kennwörtern bestimmt.
Prüfung anhand von Wörterbüchern
Eine gängige Angriffsmethode 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 Kontosperrung 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 heruntergeladen 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 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 kompromittierte Kennwörter aus unterschiedlichen Quellen einpflegt.
Allerdings prüfen Domain-Controller beim Wechsel des Kennworts dieses nicht direkt anhand der Cloud-Datenbank, sondern auf Basis eines lokal zwischengespeicherten 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 Wiederverwendung 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 Zusammenhang etwa Sprichwörter oder gängige Redewendungen, die sich Anwender viel leichter merken können als kryptische Kennwörter.
Für Passphrasen lassen sich in SPP eigenen Regeln festlegen. Nachdem sich sehr lange Zeichenfolgen nur mit viel höherem Aufwand knacken lassen, kann man hier die Vorgaben für die Verwendung von Ziffern und Sonderzeichen 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.
Diese kann ebenfalls den Einsatz von Klein- und Großbuchstaben, Ziffern und Sonderzeichen 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 Wortbestandteilen unterbinden.
Flexibles Ablaufdatum
Wie beim integrierten Passwortsystem 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öglichkeiten hinaus, indem man die Gültigkeitsdauer von der Länge des Passworts abhängig machen kann.
Microsoft ist jedoch mit der Security Baseline für Windows 10 1903 davon abgekommen, Benutzer zum regelmäß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 Übereinstimmung mit den definierten Regeln prüft. Die Policies selbst werden den Benutzern über GPOs zugewiesen, so dass theoretisch jede OU eigene Passwortregeln erhalten kann.
Die Konfiguration der Regeln erfolgt über ein Plugin für den Gruppenrichtlinien-Editor. Legt man dort eine neue Policy an, dann startet ein Assistent, der die Auswahl einer Schablone anbietet, auf deren Basis er die Passwortregeln 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.
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ätsanforderungen aus, wenn ein neues Kennwort abgelehnt wird.
Allerdings zeigt sich hier, dass die Passwortregeln 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.
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 Systemverwalter 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 Gruppenrichtlinien 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.
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 Gruppenrichtlinien dürften die meisten Admins schnell damit zurechtkommen. Die Installation umfasst zwar mehrere Komponenten, fällt aber dank eines gut strukturierten Setup-Programms relativ einfach. Etwas kniffliger ist das Zusammenspiel 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 nachvollziehbar 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
Ähnliche Beiträge
- KrbRelayUp: Domänen-Controller gegen Angriffe auf Resource-based constrained Delegation absichern
- Netlogon: Domänen-Controller verweigern Verbindung zu unsicheren Geräten
- Im Test: AD-Passwörter im Self Service zurücksetzen mit Specops uReset
- Kennwörter und Passwortrichtlinien im AD überprüfen mit Specops Password Auditor
- Nexus mit mobiler App für Zwei-Faktor-Authentifizierung
Weitere Links