Azure Password Protection

Kennwortrichtlinien im lokalen AD sollten zu einfache Benutzerkennworte ablehnen. Auch in Azure gibt es eine Kennwort-Schutzfunktion, von der sogar das lokale Active Directory profitieren kann.

Schutz für Cloud Konten

Wer Konten in der Cloud anlegt, sollte diese sogar besser schützen, als lokale AD-Konten . Cloud-Konten sind nämlich per Definition von überall auf der Welt nutzbar und damit auch für Angreifer interessant. Daher hat Microsoft für die Cloud Konten schon einige Mindestvorrausetzungen geschaffen, erfüllt sein müssen:


Quelle: AzureAD Password Policies
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy#password-policies-that-only-apply-to-cloud-user-accounts

Allerdings sind damit die Kennworte noch nicht sicher, denn auch die Microsoft Schulungskennworte wie "Password1+" oder Pa$$w0rd" erfüllen die Voraussetzungen hinsichtlich der Länge und Komplexität erfüllt und da sich auch Mitarbeiter immer mal wieder dazu verleiten lassen, ihre Zugangsdaten in einem Dialog einzugeben, der nun gar nichts mit der Firma zu tun hat. Der Schutz gegen solchen Missbrauch ist die Einführung eines zweiten Faktors, z.B. eine SMS oder über eine Authenticator App. Das geht schon viele Jahre und funktionierte sogar ohne eine "AzureAD P1"-Lizenz und seid Sep 2022 werden alle Tenants mit den "Azure Security Defaults" versehen.

Dennoch bleibt das Restrisiko, dass ein Benutzer ein eigenes sicheres Kennwort auch bei anderen Diensten verwendet und deren Sicherheit nicht so hoch eingeschätzt wird, vor allem wenn MFA solche Versuche nicht auch sichtbar macht. Es könnte also sein, dass durch einen Breach bei einer anderen Firma die Angreifer schon gütige Kennworte haben und dann nur noch MFA überlisten müssen. Auch hier gibt es Wege eine MFA-Bestätigung abzufordern und auch zu erhalten.

Daher bedient sich Microsoft ebenfalls den Listen aus dem Internet und Darknet mit Kennworten, um die vom Cloud-Anwender genutzten Kennworte dagegen zu prüfen. Mittlerweile werden nämlich nicht mehr nur viele Kennworte bei einem Konto durchprobiert sondern auch vielen Konten im dem gleichen bekannten Kennwort versucht. Also kein "Cracking" eines Kontenkennworts sondern ein Password Spray Attacke.

Wenn man den Aussagen von Microsoft glauben darf, dann werden die vom Anwender eingegeben Kennworte natürlich nicht im Klartext gespeichert sondern nur als Hash-Werte. Dann muss man auch am Ende nur die Hashwerte vergleichen. Das gleiche Verfahren nutzen auch bekannte Seiten wie Have i been pwned und das HPI.

Bei Microsoft habe ich noch keine Seite gefunden, auf der ich mein Kennwort oder mein Anmeldename aktiv prüfen lassen kann aber bei einer Kennwort-Änderung durch den Anwender prüft Microsoft im Hintergrund das vom Anwender eingegebene Kennwort gegen seine eigene Datenbanken aber wohl nicht gegen "Quellen aus dem Internet".

Cloud Password Protection

The global banned password list isn't based on any third-party data sources, including compromised password lists.
Quelle: https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#password-spray-attacks-and-third-party-compromised-password-lists

Allerdings müssen Sie diesen dritten Schutz gegen "schwache Kennwort" erst aktivieren. Im Azure Portal finden Sie dazu die Einstellung unter der Adresse https://portal.azure.com/#view/Microsoft_AAD_IAM/PasswordProtectionBlade.

Allerdings ist dazu zumindest AzureAD P1 erforderlich.

Ansonsten sehen Sie nur den folgenden Dialog und können nichts ändern:


https://portal.azure.com/#view/Microsoft_AAD_IAM/PasswordProtectionBlade

Mit der passenden Lizenz können Sie hier den Schieber bei "Mode" dann auch von "Audit" auf "Enforce" setzen. Änderungen an dieser Einstellung werden natürlich auch im Audit-Log des Tenants protokolliert. Sie können also immer nachweisen, wenn jemand diese Richtlinie angepasst hat:

Die Details verraten dann auch die Änderung:

ADSync und Kennwort

Nun sind "Cloud Only"-Benutzer sicher in der Minderheit, denn die meisten Firmen haben ja schon ein lokales Active Directory und nutzen ADSync / AADConnect oder AzureAD Cloud Sync zur Verwaltung der Identitäten. Für den Zugriff auf Cloud-Dienste kann sich der Anwender direkt gegen das lokale Active Directory authentifizieren, wenn die ADFS Authentifizierung oder Pass Through Authentifizierung (PTA) konfiguriert ist. Dann ist das Kennwort in der Cloud nicht relevant, da es nicht genutzt wird. Wird hingegen Password Hash Sync (PHS) eingesetzt, dann repliziert ADSync den Hashwert des lokalen AD-Kennworts in die Cloud und eine Anmeldung an Cloud-Diensten erfolgt über diese Information. Hier stellt sich dann die Frage der Kennwortrichtlinie:

Es gilt die lokale AD-Richtlinie. AzureAD-Kennwort-Richtlinien werden bei PHS nicht angewendet.

Die Anmeldung an der Cloud ist damit nicht schlechter als die Kennwortsicherheit im lokalen Active Directory aber sie können auch nicht sicher sein, dass die Kennworte wirklich gut genug sind. Allerdings gibt es in der Cloud schon mit aktiven Azure Security Defaults eine höhere Sicherheit, da allein das Wissen um Anmeldename und Kennwort nicht den Zugang erlaubt.

Ich habe einige Zeit sinniert, warum Microsoft auch "unsichere Kennworte" durch ADSync in die Cloud replizieren lässt. Ich kann mir das nur so erklären, dass es in der Standardkonfiguration im Moment der Änderung durch den Anwender keine Prüfmöglichkeit gibt und das Kennwort nicht abgewiesen wird. Das Kennwort im lokalen AD wird also geändert. Würde ADSync dann nicht das AzureAD-Konto aktualisieren, wären die Zugangsdaten nicht mehr synchron. Die wenigsten Administratoren würden hier aber dann im Eventlog von ADSync die Ursache erkennen.

Wir müssen uns also einen anderen Weg suchen.

Azure und On-Premises Schutz

Den bietet Microsoft aber in Verbindung mit einer lokalen Installation einer Komponente, die in die lokale Kennwortverwaltung eingreift. Schon früher gab es "Password filter DLLs", mit denen eine berechtigte Funktion auf den Domain Controllern (oder PCs) Eingriff in den Änderungsprozess nehmen konnte.

Solche DLLs haben nativen Zugriff auf das vom Anwender an den DC gesendete Kennwort und können es auf die Stärke prüfen oder im bösartigen Fall auch "ausleiten". In Verbindung mit Azure liefert Microsoft aber eine DLLs und andere Helfer aus, dass jede Kennwortänderung eines Benutzers direkt gegen die Azure Richtlinien geprüft werden. Damit nun natürlich eine DLL auf einem Domain Controller nicht direkt mit dem "Internet" kommuniziert, hat sich Microsoft einen Proxy einfallen lassen.


Quelle: https://learn.microsoft.com/de-de/azure/active-directory/authentication/howto-password-ban-bad-On-Premises-deploy

Wenn ein Benutzer sein Kennwort ändert, dann landet die Anforderung auf einem Domain Controller und der dort installierten Filter-DLL, die dann den Request an einen lokal auf dem DC installierten Agenten zur Überprüfung weiterreicht. Der Agent seinerseits spricht mit dem zwingend zu installierenden Azure AD Password Protection Proxy Service, der dann das AzureAD fragt. Über den Weg liest der Service auch die Kennwort-Richtlinien aus Azure, gibt sie an den lokalen Agenten weiter der diese im SYSVOL-Verzeichnis speichert. Damit können also alle DCs von diesem Wissen profitieren.

Andere Lösungen

Wenn Sie nicht auf Azure Password Protection setzen wollen oder können, dann sollten Sie dennoch sich Sicherheit der lokalen Kennworte überprüfen. Es gibt im Internet umfangreiche Datenbanken von Hashwerten unsicherer Kennworte, z.B. 

Es fehlt ihnen dann nur noch der Code, um im AD nach solchen Kennworten zu suchen oder bei Änderungen von Kennworten diese gegen solche Listen zu prüfen. Diverse Organisationen empfehlen mittlerweile ja nicht mehr die regelmäßige Änderung von Kennworten aber fordern eine Prüfung der Sicherheit genutzter Kennworte

Insofern können Sie AzureAD Password Protection als eine Lösung nutzen oder sie suchen sich speziell für On-Premises eine geeignete Lösung

Weitere Links