Zeichenfolgen in Passwörtern vermeiden

In diesem Beitrag erfahren Sie, wie man Zeichenfolgen in Passwörtern mit Azure AD Passwortschutz vermeidet. Standardmäßig bietet das Windows Betriebssystem über die Passwortrichtlinien an, die minimale Zeichenanzahl sowie eine vordefinierte Komplexität des Passwortes vorzugeben.

Diese definierte Komplexität (sofern aktiviert) erfordert:

• dass ein neues Passwort mindestens ein Zeichen aus drei definierten Mengen (Großbuchstaben, Kleinbuchstaben, Zahlen und Sonderzeichen) beinhalten muss,
• sowie dass der Inhalt des Active Directory Attributes sAMAccountName und Teilzeichenfolgen des Attributes displayName (getrennt durch Komma, Punkt, Bindestrich, Unterstrich, Leerzeichen, Raute oder Tabulator) zur Ablehnung führen.

Für darüber hinausgehende Anforderungen an den Ausschluss von Zeichenfolgen muss ein eigener Passwortfilter entwickelt und eingebunden werden.

In der Microsoft Cloud bietet die Azure Active Directory (Azure AD) Passwortrichtlinie keine nennenswerten Unterschiede für Zeichenfolgen gegenüber dem Pendant im lokalen Active Directory.

Aber es existiert eine zusätzliche Funktionalität Namens Azure AD Passwortschutz (Azure AD Password Protection), deren Ziel es ist, „schwache“ Passwörter zu vermeiden. Der Azure AD Passwortschutz basiert auf zwei Listen:

• Globale Sperrliste: Diese Liste wird von Microsoft verwaltet und über Azure AD Telemetriedaten, mit globalen Password Leaks oder weiteren schwachen Zeichenfolgen aktualisiert. Dies ist ein fortlaufender Prozess, um aktuellen Rahmenbedingungen gerecht zu werden.
• Benutzerdefinierte Sperrliste: Diese Liste wird in Eigenverantwortung verwaltet. Man kann ausschließen, dass z.B. der Firmenname oder Produktname in Passwörtern verwendet werden darf.

Mit den bereitgestellten Zeichenfolgen wird bei einem Passwortwechsel die eingegebene Zeichenfolge mit einem Punktesystem bewertet. Bei einem Wert von mindestens 5 wird die Zeichenfolge als gültig angesehen. Der Prozess der Bewertung ist wie folgt:

1. Normalisierung: In diesem Schritt werden Großbuchstaben durch das kleingeschriebene Pendant ersetzt und gängiger Zeichenaustausch (z.B. „0“ nach „o“, „$“ nach „s“ oder „1“ nach „l“) wird zurückgenommen (Beispiel: „P@$$w0rd“ wird zu „password“).
2. Fuzzy Übereinstimmung: Die Einträge aus den Sperrlisten werden vollständig oder als Teilübereinstimmung in der normalisierten Zeichenfolge gesucht. Dabei wird auch eine Editierdistanz von 1 angewendet, d.h. der Eintrag aus der Sperrliste unterscheidet sich mit der (Teil)-Zeichenfolge durch eine Einfüge-, Lösch- oder Ersetz-Operation. (Beispiel: „passwort“ = „password“ oder „passwort“ = „passort“)
3. Vordefinierte Zeichenfolgen: Die jeweiligen Zeichenfolgen größer als drei Zeichen bestehend aus Vor- und Nachname sowie dem Namen des Azure Mandanten führen bei einer Übereinstimmung zur direkten Ablehnung des Passwortes
4. Bewertung: Jede gefundene Fuzzy Übereinstimmung wird mit einem Punkt bewertet. Alle übrig gebliebenen Zeichen werden zusätzlich mit einem Punkt berechnet.

Die globale Sperrliste steht standardmäßig für jedes cloudbasierte Benutzerkonto zur Verfügung. Für die Verwendung einer benutzerdefinierten Sperrliste ist mindestens eine Azure AD Premium P1 Lizenz notwendig.

Cloud Passwortschutz für lokalen Benutzerkonten

Microsoft hat die Funktionalität um eine Komponente für das Windows Server Active Directory erweitert, d.h. die globale und, sofern genutzt, die benutzerdefinierte Sperrliste wird bei einer Passwortänderung eines Active Directory Benutzerkontos mit dem oben beschriebenen Bewertungssystem angewendet. Die Funktionalität kann in einem von zwei Modi betrieben werden:

1. Überwachungs-Modus: In diesem Modus wird eine Passwortänderung gemäß der lokal geltenden Passwortrichtlinien erlaubt, aber eine Konformität oder Ablehnung gegenüber der Sperrlisten wird im Ereignisprotokoll des jeweiligen Domänencontrollers vermerkt.
2. Erzwingungs-Modus: In diesem Modus gelten sowohl die lokalen Passwortrichtlinien als auch der Azure AD Passwortschutz bei einer Passwortänderung. Zusätzlich wird, wie im Überwachungs-Modus, eine entsprechende Information im Ereignisprotokoll vermerkt.

Unabhängig davon werden die Sperrlisten in der SYSVOL Freigabe zwischengespeichert. Stündlich verifiziert jeder Domänencontroller das Alter der Sperrlisten. Sind diese älter als eine Stunde, dann wird eine Aktualisierung angefordert.

Azure AD Passwortschutz mit Windows Server Active Directory

Für diese Funktionalität hat Microsoft ein Architekturschaubild vorbereitet, so dass eine einfache Bereitstellung ohne Planung ausgeschlossen werden kann. Doch erst einmal zu den Voraussetzungen:

• Einen Azure Mandanten
• Alle Azure Benutzerkonten, die aus dem Windows Server Active Directory in das Azure AD synchronisiert werden, müssen mindestens eine Azure AD Premium P1 Lizenz zugeordnet haben (Alle nicht-synchronisierten Benutzer dürfen den Azure AD Passwortschutz auch nutzen)
• Mindestens einen Mitgliedsserver, der eine Proxy Funktionalität zwischen den Agenten auf den Domänencontrollern und dem Azure AD wahrnimmt (darf nicht den Azure AD-Anwendungsproxy enthalten)
• Die Replikation der SYSVOL Ordnerstruktur im Windows Server Active Directory wird mit dem Dienst DFS-R durchgeführt (der Dateireplikationsdienst wird nicht unterstützt)

Sind diese Voraussetzungen erfüllt, dann können die benötigten Dienste eingerichtet und die Funktionalität für das Windows Server Active Directory aktiviert werden. Dazu nun das bereits erwähnte Architekturschaubild:

Die Einrichtung beginnt mit dem Azure AD Passwortschutz Proxydienst, der auf einem Mitgliedsserver in der bereitzustellenden Active Directory Gesamtstruktur installiert wird (z.B. auf dem Azure AD Connect System). Für einen besseren Ausfallschutz des Dienstes sollte dieser noch auf einem weiteren System geplant werden. Per PowerShell cmdlet wird für jede Instanz des Proxydienstes ein Service Connection Point (SCP) im Windows Server Active Directory angelegt und gleichzeitig die Registrierung im Azure AD durchgeführt (Azure AD Global Admin und Organisations-Admin werden dazu benötigt).

Sollen mehrere Windows Server Active Directory Gesamtstrukturen im Unternehmensnetzwerk den Azure AD Passwortschutz verwenden, dann wird pro Gesamtstruktur mindestens eine Instanz des Azure AD Passwortschutz Proxydienstes vorausgesetzt. Zusätzlich muss jede Windows Server Active Directory Gesamtstruktur einmalig für Azure AD Passwortschutz im Azure AD bekannt gemacht werden.

Nachdem der Proxy Dienst in der lokalen Infrastruktur bereitgestellt ist, können die Azure AD Passwortschutz DC Agenten auf Domänencontrollern installiert werden. Bei der Installation wird auf dem Domänencontroller eine zusätzliche Passwortfilter-DLL registriert, die mit dem Azure AD Passwortschutz DC Agenten kommuniziert, um ein Kennwort gegen die lokalen Kopien der beiden Sperrlisten zu verifizieren.

Die Passwortfilter-DLL ist eine Ergänzung zu den schon bestehenden Filtern. Für das Active Directory ist eine Zeichenfolge valide, wenn alle Passwortfilter dieser zustimmen. Um eine Aktualisierung der Sperrlisten zu erhalten, kommuniziert der Azure AD Passwortschutz DC Agent mit dem Proxydienst, der über den registrierten SCP im Active Directory gefunden wird. Eine neu erhaltene Liste wird in der SYSVOL-Dateistruktur abgelegt (siehe Bild) und somit auf alle Domänencontroller der Domäne repliziert, so dass auch nicht jeder Domänencontroller die Sperrlisten anfragen muss.

Die Bereitstellung der Agenten auf alle Domänencontroller einer Domäne kann stufenweise erfolgen, so dass in diesem Fall der Azure AD Passwortschutz nur auf den Domänencontrollern aktiv ist, auf denen auch der Azure AD Passwortschutz DC Agent in Betrieb ist. D.h. ändert ein Benutzer sein Passwort auf einem Domänencontroller, auf dem der Agent noch nicht bereitgestellt ist, dann finden die beiden vordefinierten Sperrlisten keine Anwendung. Diese Vorgehensweise kann z.B. für erste Tests der Funktionalität in der produktiven Infrastruktur genutzt werden.

Der Azure AD Passwortschutz sollte zuerst im Überwachungs-Modus verwendet werden, um sich als Administrator mit dem Betrieb des Dienstes vertraut zu machen. Gegebenenfalls können die Auswirkungen der beiden Sperrlisten abgeschätzt oder Benutzer auf eine unvorteilhafte Zusammensetzung der gewählten Zeichenfolge für das eigene Kennwort hingewiesen werden. In einem zweiten Schritt kann der Modus dann gewechselt und der Azure AD Passwortschutz vollständig aktiviert werden.

Fazit

Sind die vorausgesetzten Azure Lizenzen vorhanden, dann kann mit relativ einfachen Mitteln die Qualität der Benutzerpasswörter im Azure AD und im Windows Server Active Directory eines Unternehmens erhöht werden. Die Weboberfläche im Azure Portal bietet die Möglichkeit, die benutzerdefinierte Sperrliste für Azure AD und Windows Server Active Directory einheitlich zu pflegen. Im Unternehmensnetzwerk verhindert die Architektur des Dienstes, dass die Domänencontroller einen direkten Kommunikationsweg mit einem Clouddienst unterhalten. Durch einen lokalen Cache wird eine vorübergehende Einschränkung in der Erreichbarkeit des Clouddienstes kompensiert.

Für einen Benutzer ist die Einrichtung transparent. Dieser erhält, egal ob über eine Passwortrichtlinie oder den Azure AD Passwortschutz, den identischen kryptischen Hinweis, dass seine gewählte Zeichenfolge gegen eine Kennwortvorgabe verstößt. Ein Administrator muss, sofern er keinen zentralen Sammeldienst für Ereignisse hat, den entsprechenden Domänencontroller finden, auf dem die Kennwortänderung durchgeführt wurde. Anschließend muss er nach dem Protokolleintrag suchen, der Aufschluss gibt, weshalb eine Zeichenfolge basierend auf dem Azure AD Passwortschutz abgelehnt worden ist.