Aktualisiert: Azure AD Password Protection ist seit dem2. April 2019 allgemein verfügbar. Der Dienst ist weitgehend derselbe, den ich in diesem Beitrag vorgestellt habe, mit den folgenden Aktualisierungen:
- Das Limit von zwei Proxys wurde aufgehoben.
- Bei der Registrierung des Proxys und der Active Directory-Gesamtstruktur sind jetzt 3 Authentifizierungsmodi verfügbar. Zwei davon unterstützen MFA, so dass ein Global Admin-Konto ohne MFA nicht erforderlich ist.
- Der Algorithmus zur Bewertung von verbotenen Kennwörtern wurde aktualisiert. Siehe "Wie werden Kennwörter ausgewertet" in der Microsoft-Dokumentation. Hinweis: Dieser Algorithmus kann sich jederzeit ändern, ohne dass eine Ankündigung oder Aktualisierung der Dokumentation erfolgt.
- Die Lizenzierung wurde vereinfacht: Alle mit Azure AD synchronisierten Benutzer müssen über Azure AD Premium P1 oder P2 verfügen. Wenn diese Voraussetzung erfüllt ist, sind alle Active Directory-Benutzer für diesen Service lizenziert.
- Preview-Kunden müssen die Agenten aktualisieren; die Agenten der Public Preview funktionieren nach dem 1. Juli 2019 nicht mehr.
- Meine Quellen bei Microsoft sagen mir, dass die Benutzer die neue Ablehnung gängiger Kennwörter mit der Standardmeldung "Ihr Kennwort entspricht nicht den Komplexitätsanforderungen" nicht so verwirrend finden, wie sie dachten.
- Beginnen Sie mit dem Einsatz!
Microsoft hat endlich einen Dienst zur Verfügung gestellt, der das größte Sicherheitsrisiko im Zusammenhang mit Kennwörtern in Unternehmen entschärft: allgemeine Kennwörter. Sie sollten diese neue Active Directory-Funktion noch heute ausprobieren, damit Sie sie einsetzen können, sobald sie allgemein verfügbar ist.
Dies ist ein langer Beitrag; wenn Sie nicht an der TL;DR-Version interessiert sind (und das sollten Sie sein), können Sie direkt zu
- Das gewöhnliche Passwort als Angriffsvektor
- Architektur
- Ablauf der Laufzeit-Authentifizierung
- Passwort-Bewertungsprozess
- Vorteile des Designs
- Schritte für die Bereitstellung
- Überwachung
- Lizenzierung
- Verschiedene Leckerbissen
Das gewöhnliche Passwort als Angriffsvektor
Ich habe in diesem Blog gepostet und auf dem Cloud Identity Summit (jetzt Identiverse) über die Empfehlungen von Microsoft und NIST zur Konfiguration von Kennwortlänge, Ablaufdatum und anderen Kennwortrichtlinien im Lichte ihrer Forschung und Praxiserfahrung gesprochen. Eine der wichtigsten Empfehlungen beider Organisationen ist die Verwendung einer Liste verbotener Kennwörter, in der die einfachsten und gebräuchlichsten Kennwörter nicht erlaubt sind. (Und ja, ich bin hier, um Ihnen mitzuteilen, dass einige der gebräuchlichsten Passwörter 'password' und '12345678' sind. Ich fürchte um die menschliche Rasse.)
Laut Microsoft haben die Angriffe auf gängige Passwörter mittels "Passwort-Spray"-Attacken in den letzten Monaten dramatisch zugenommen. Diese Angriffe sind mit herkömmlichen Sicherheitstools extrem schwer abzuwehren, da der Angreifer nicht ein einzelnes Konto mit mehreren Passwörtern angreift. Vielmehr verwenden sie einige gängige Passwörter, um mehrere Konten anzugreifen. Jedes Konto wird nur ein paar Mal versucht, und vielleicht mit einem langen Intervall zwischen den Versuchen, um das Auslösen von Alarmen zu vermeiden. Der beste Schutz gegen diese Angriffe ist, einfach keine gemeinsamen Kennwörter zu verwenden.
Die meisten großen Unternehmen verwenden eine hybride Identitätsarchitektur, bei der die Passwörter in einer lokalen Active Directory-Umgebung verwaltet werden. Und Active Directory verfügt leider nicht über eine sofort einsatzbereite Lösung für das Verbot gängiger Passwörter. Infolgedessen hatten die meisten Unternehmen keinen Schutz gegen häufige Passwörter.
Azure AD Password Protection ist ein hybrider Dienst in der öffentlichen Vorschau, der Schutz vor gängigen Passwörtern sowohl für Azure AD Organisationskonten als auch für lokale Windows Server Active Directory-Konten bietet. Er hindert Benutzer und Administratoren daran, ihre Passwörter zu ändern oder auf einfache, leicht zu knackende Passwörter wie "987654321" oder "quertyjkl;" (für Sie Tipper) zurückzusetzen.
Architektur
Azure AD Password Protection besteht aus einer Azure-Komponente, einem lokalen Proxy-Dienst, einem DC-Dienst und schließlich einem benutzerdefinierten Passwortfilter (Abbildung 1):
Ziel dieser Architektur ist es, 1) die globale Passwortverbotsliste (GBPL) von Azure zu verwenden, um Azure AD-Konten vor der Verwendung gängiger Passwörter zu schützen, 2) Azure-Administratoren die Möglichkeit zu geben, eine benutzerdefinierte Passwortverbotsliste zu erstellen, die die GBPL ergänzt, und 3) Active Directory-Konten vor gängigen Passwörtern zu schützen, indem ein lokaler Dienst bereitgestellt wird, der die konsolidierte Passwortverbotsliste verwendet.
Azure
Azure AD verwendet seit einiger Zeit eine intern erstellte Liste verbotener Passwörter und erzwingt auch die Einhaltung längerer Mindestpasswortlängen. Wenn Sie ein gängiges Passwort eingeben, werden Sie freundlich darauf hingewiesen, es noch einmal zu versuchen:
Der Kennwortschutzdienst (Abbildung 3) verwendet Azure Threat Intelligence für eine globale Übersicht der verbotenen Kennwörter. Die Liste wird aus den Passwörtern in den Listen der durchgesickerten Zugangsdaten und der Analyse der 20 Millionen (!) Kontoübernahmeversuche, die das Azure Threat Intelligence System täglich abfängt, zusammengestellti . Diese Liste enthält nicht alle gängigen Passwörter, die jemals gefunden wurden, sondern nur die 1000 häufigsten, die aktiv für Angriffe verwendet werdeni.
Warum prüft der Dienst nicht auf mehr als 1000 gängige Kennwörter? Das mag für Azure praktisch sein, aber nicht für Server vor Ort. Bei der Kennwortprüfung wird das Kennwort des Benutzers nicht nur mit den mehr als 1000 verbotenen Kennwörtern verglichen, sondern möglicherweise mit Tausenden von Variationen jedes Kennworts. Das ist eine Menge an Passwörtern, die verglichen werden müssen. Wenn die Kennwortliste 1 Million Kennwörter enthielte, wären das Milliarden von Kennwortvariationenii, die Ihre DCs überprüfen müssten - und sie würden unter der Last zum Stillstand kommen.
Die Steuerung und Konfiguration der Kennwortschutzfunktion erfolgt im Azure Active Directory-Blade des Verwaltungsportals unter dem neuen Abschnitt Authentifizierungsmethoden. Der einzige Punkt in diesem neuen Bereich - der allerdings sicher noch wachsen wird - ist Passwortschutz (Abbildung 4).
Zusätzlich zu der von Azure generierten globalen Liste verbotener Passwörter (GBPL) bietet Azure AD Password Protection eine mandantenweite Ansicht der verbotenen Passwörter (TBPL). Ein Finanzdienstleistungsunternehmen könnte zum Beispiel Passwörter wie "Hypothek" oder "Versicherung" zusätzlich zu den von Azure global festgelegten allgemeinen Passwörtern verbieten wollen. (In der Abbildung habe ich Autofirmen zu der benutzerdefinierten Liste hinzugefügt.) Diese konsolidierte Liste wird vor Ort verwendet.
Beachten Sie, dass der Dienst so konfiguriert ist, dass der Kennwortschutzdienst, wenn Sie Komponenten vor Ort installiert haben, ohne die Azure-Kontrollen zu berühren, sofort im Audit-Modus arbeitet und die globale Azure-Liste der verbotenen Kennwörter verwendet.
Proxy-Dienst
Der Zweck des Azure AD Password Protection Proxy-Dienstes besteht darin, die BPL zu erwerben und an die DCs weiterzuleiten. Als zustandsloser Relay-Dienst ermöglicht es der Proxy den DCs, die BPL von Azure AD zu erhalten, ohne selbst einen Internetzugang zu benötigen (ein heikler Punkt in der Unternehmenssicherheit). Der Proxy fragt Azure AD nicht selbst ab; er leitet die BPL-Anfragen der DCs einfach an den Azure-Dienst weiter und leitet die daraus resultierende BPL an den anfragenden DC weiter. Dadurch müssen die DCs selbst nicht mehr über eine Internetverbindung verfügen.
Der Proxy-Dienst kann auf jedem Server installiert werden, der mit einer Domäne verbunden ist. In dieser Vorschau kann er auf einem oder zwei Servern installiert werden, um Fehlertoleranz zu gewährleisten; diese Einschränkung wird voraussichtlich noch vor der GA aufgehoben werden. Sowohl der Proxy-Dienst als auch die Active Directory-Gesamtstruktur müssen mit dem neuen AzureADPasswordProtection-Modul bei Azure AD registriert werden. (Befolgen Sie die Anweisungen sorgfältig.) Nach der Registrierung meldet sich der Proxy beim DC mit einem AzureAdPasswordProtectionProxy-Dienstverbindungspunkt unter dem Computerobjekt (Abbildung 5):
DC-Agent
Das DC-Agent-Paket enthält zwei Komponenten (Abbildung 6). Die erste Komponente ist der DC-Agent selbst, der als AzureADPasswordProtectionDCAgent ausgeführt wird. Die zweite ist ein benutzerdefinierter Passwortfilter. Schauen wir uns diese in umgekehrter Reihenfolge an.
Ein AD-Passwortfilter ist eine benutzerdefinierte DLL, mit der Sie die grundlegende Funktionalität einer Passwort-Gültigkeitsprüfung erweitern können. Der Azure AD Password Protection-Kundenpasswortfilter ist so einfach wie möglich. Er leitet lediglich die Passwortanfrage an den DC-Agenten weiter und sammelt die Antwort des Agenten, ob er sie akzeptiert oder ablehnt.
Da der Kennwortfilter ein integraler Bestandteil des DC-Sicherheitssystems ist, hat dies den Nebeneffekt, dass der DC neu gestartet werden muss, wenn der DC-Agent installiert oder entfernt wird.
Der DC-Agent ist das Herzstück des Dienstes vor Ort. Während des DC-Laufzeitbetriebs überprüft der Agent die Gültigkeit von Benutzerpasswortänderungen anhand der Passwortrichtlinie. Im Hintergrund stellt er sicher, dass der DC über eine aktuelle Kopie der von Azure AD erhaltenen BPL verfügt. Ist dies nicht der Fall, beschafft er eine solche, verarbeitet sie, um eine Kennwortrichtlinie zu erstellen, und speichert sie dann auf SYSVOL unter
C:WindowsSYSVOLsysvolPolicies{4A9AB66B-4365-4C2A-996C-58ED9927332D}AzureADPasswordProtection.
Die Art und Weise, wie die DC-Agenten (in einem produktiven Einsatz sollte es auf jedem DC einen geben) die Kennwortrichtlinie erhalten und verteilen, ist recht elegant:
- Ein DC-Agent in jeder Active Directory-Site wacht etwa einmal pro Stunde auf, um zu entscheiden, ob seine lokale Kopie der Kennwortrichtlinie auf SYSVOL aktualisiert werden muss.
- Wenn die Richtlinie aktualisiert werden muss oder noch keine Richtlinie vorhanden ist, fordert es über den Proxy eine neue verschlüsselte BPL von Azure AD an, erstellt daraus eine Kennwortrichtlinie und speichert sie in SYSVOL.
- SYSVOL repliziert diese Richtlinie über DFS-R auf alle DCs in der Domäne (Abbildung 7).
Höchstens ein DC pro Standort kann die BPL anfordern, aber es werden wahrscheinlich viel weniger sein - höchstens einmal pro Stunde und Domäne. Und warum? Wegen der effizienten Replikation der Richtlinie über SYSVOL durch DFS-R. In einem anständig vernetzten Netzwerk wird eine aktualisierte Richtlinie an alle DCs repliziert, bevor andere Agenten aufwachen, so dass sie über eine aktuelle Richtlinie verfügen und keine neue BPL von Azure anfordern müssen. Diese Architektur stellt auch sicher, dass DCs in gesperrten Umgebungen weiterhin die Kennwortrichtlinie erhalten, da die SYSVOL-Replikation ein wesentlicher Bestandteil der DC-Funktionalität ist.
Ablauf der Laufzeit-Authentifizierung
Die Bewertung der Richtlinie für verbotene Passwörter ist in den Standardprozess der AD-Passwortbewertung integriert (Abbildung 8):
- Der Benutzer versucht, ein neues Passwort zu setzen, und sein lokaler DC bearbeitet die Anfrage.
- Auf dem DC wird die Anfrage durch den benutzerdefinierten Kennwortfilter verarbeitet, der das Kennwort an den DC-Agenten weiterleitet.
- Der DC-Agent vergleicht das vorgeschlagene Passwort mit dem Passwort auf SYSVOL und genehmigt es oder lehnt es ab.
- Der Erfolg oder Misserfolg wird an den Benutzer zurückgegeben.
Passwort-Bewertungsprozess
Das vom Benutzer vorgeschlagene Passwort wird mit einer Liste von etwa 1000 Wörtern und Mustern ("asdf" usw.) verglichen. Außerdem wird das Kennwort durch andere Zeichen ersetzt ($ für s, Groß-/Kleinschreibung, usw.). Derzeit wird für jedes Kennwort eine Punktzahl in der folgenden Form berechnet:
Jedes Zeichen ist einen Punkt wert, aber jede Teilzeichenkette, die mit einem verbotenen Wort/Phrase/Muster übereinstimmt, ist insgesamt nur einen Punkt wert. Die zulässige Mindestpunktzahl beträgt 5 Punkte. Zum Beispiel sind "Frühling" und "2018" verbotene Wörter, daher ist "Frühling2018" nur 2 Punkte wert und wäre nicht erlaubt.
"Spring2018asdfj236" lässt sich wie folgt aufschlüsseln:
- Feder = 1 Punkt
- 2018 = 1 Punkt
- asdf = 1 Punkt
- f, j, 2, 3, 6 = je 1 Punkt
Gesamt = 8 Punkte = PASS
Dieses Verfahren erlaubt einige verbotene Wörter oder Phrasen, wenn das Kennwort genügend andere zufällige Zeichen enthält. Bitte beachten Sie, dass sich dies noch ändern kann, da Microsoft seine Cloud-Bedrohungsdaten zu Passwortangriffen weiterentwickeltvi.
Die Richtlinie gilt für alle Benutzer im Forest - es gibt keine Hintertür für Administratoren - und wird auf alle Passwortänderungsprozesse angewendetvii. Die normale Überprüfung falscher Kennwörter mit dem PDC-Emulator ist von dieser neuen Funktion nicht betroffen.
Vorteile des Designs
Dieses hybride Design hat viele Vorteile:
- Der BPL-Anforderungs- und Aktualisierungsprozess ist so konzipiert, dass er den Betrieb der DCs kaum beeinträchtigt. In einem gut vernetzten Netzwerk wird nur ein DC pro Domain und Stunde die BPL anfordern.
- Der Anfrage- und Aktualisierungsprozess funktioniert mit einer Vielzahl von Netzwerktopologien. Die DCs brauchen keine Internetverbindung, nur der Proxy braucht einen Internetzugang. Und falls erforderlich, muss sich der Proxy nur mit einem einzigen DC pro Domäne über RPC verbinden (und der Port ist konfigurierbar). Die SYSVOL-Replikation über DFSR sorgt dafür, dass die Kennwortrichtlinie an alle DCs in der Domäne gelangt.
- Die Kennwortprüfung durchläuft die normalen Active Directory-Prozesse, und alle Änderungen an den AD-Kernfunktionen werden auf ein Minimum beschränkt. Kein Teil des Vorgangs geht jemals vom DC aus. So wird beispielsweise ein Versuch, ein Kennwort zu ändern, niemals blockiert, wenn der DC Azure nach einem neuen BPL fragen muss. Der eigentliche Kennwortfilter ist so einfach wie möglich.
- Die Software ist "ausfallsicher" konzipiert, d.h. wenn eine Komponente nicht installiert ist oder nicht funktioniert (z.B. der DC-Agent ist installiert, aber der Proxy ist nicht installiert), wird das Kennwort zugelassen, aber ein Fehler wird im Ereignisprotokoll des DC protokolliert.
- Diese offene Architektur ermöglicht die Vorinstallation des DC-Agenten auf einem Server, den Sie zu einem DC befördern möchten.
- Der DC-Agent führt denselben Code zur Kennwortüberprüfung aus wie der Azure-Dienst.
- Sie müssen es nicht auf all Ihren DCs einrichten, um es zu testen. Das ist sogar ein guter Weg, um es schrittweise zu implementieren.
Schritte für die Bereitstellung
Die detaillierten Einrichtungsschritte sind hier dokumentiert. Da es sich bei diesem Dienst um eine Vorschau handelt, werden sie voraussichtlich regelmäßig aktualisiert werden. Im Großen und Ganzen sind das folgende Schritte
- Bestimmen Sie, auf welchen domänenverbundenen Computern Sie den Proxy-Dienst installieren möchten und auf welchen DCs Sie ihn testen möchten. Der Proxy muss nicht auf dem Azure AD Connect Server oder einem DC installiert werden, sondern auf einem beliebigen Mitgliedsserver (z.B. einem Server, der bereits Anwendungsproxy-Konnektoren hostet). Denken Sie daran, dass Sie öffentliche Vorschauen nicht auf Produktionsservern oder zumindest gegen Produktionsbenutzer verwenden sollten. Sie könnten einen DC in seiner eigenen Site fördern und isolieren, um ihn gegen bestimmte Benutzer zu testen.
- Stellen Sie sicher, dass der Azure AD Password Protection Service für den Audit-Modus konfiguriert ist (die Standardeinstellung) und fügen Sie optional alle benutzerdefinierten Passwörter zum Tenant BPL hinzu.
- Holen Sie sich die Vorschau-Bits für den Kennwortrichtlinien-Proxy-Dienst und den DC-Agent aus dem Download-Center.
- Installieren Sie den Proxy-Dienst für die Kennwortrichtlinie.
- Auf dem Proxy-Server,
a. Registrieren Sie den Proxy-Dienst bei Azure AD.
b. Registrieren Sie die lokale Active Directory-Gesamtstruktur bei Azure AD. - Installieren Sie den/die DC-Agenten.
- Starten Sie die DCs neu.
Überwachung
Zum jetzigen Zeitpunkt müssen Informationen über die Aktivität des Azure AD Password Protection-Dienstes vom Proxy-Server und den DC-Ereignisprotokollen gesammelt werden. Zum jetzigen Zeitpunkt gibt es in der öffentlichen Vorschau keine Integration mit Azure AD Connect Health und auch keine Überwachung des Proxy-Agenten über das Azure AD Blade im Proxy-Portal.
Ereignis-IDs im Bereich von 10000 werden vom Kennwortfilter erzeugt, während IDs im Bereich von 30000 vom DC-Agenten stammen. In den Meldungen des DC-Agenten finden Sie (etwas) mehr Informationen (Abbildung 9):
Der DC-Agent hat seine eigenen Leistungszähler in Perfmon unter Azure AD Password Protection (Abbildung 10):
Sie können auch das PowerShell-Cmdlet Get-AzureADPasswordProtectionSummaryReport verwenden, um eine Übersicht über die Aktivitäten zur Passwortänderung zu erhalten.
Lizenzierung
Welche Art von Azure AD-Lizenz ist für diese Fähigkeit erforderlich? Sie setzt sich folgendermaßen zusammenerviii:
- Nur Cloud-Konten: Azure AD Passwortschutz mit globaler Verbotsliste: Kostenlos
- Azure AD Passwortschutz mit benutzerdefinierter Liste: Azure AD basic
- Windows Server AD-Integration Azure AD-Passwortschutz mit globaler Passwortverbotsliste: Alle synchronisierten Benutzer müssen über Azure AD Premium P1 Lizenzen verfügen
- Azure AD Passwortschutz mit benutzerdefinierter Liste (was ich in diesem Beitrag beschreibe): Alle synchronisierten Benutzer müssen über Azure AD Premium P1 verfügen
Auch hier gilt: Da es sich um eine öffentliche Vorschau handelt, können sich Änderungen ergeben.
Verschiedene Leckerbissen
- Es gibt keine Beziehung zwischen den lokalen Teilen von Azure AD Password Protection und Azure AD Connect. Daher ist es nicht erforderlich, den Proxy auf einem oder mehreren Azure AD Connect-Servern zu installieren (auch wenn er auf diesen Servern problemlos funktionieren wird).
- Da auf der Client-Seite keine Änderungen vorgenommen werden, wird bei einem abgelehnten gemeinsamen Kennwort auf dem Client der Standardfehler "Kennwort entspricht nicht den Komplexitätsanforderungen" angezeigt.
- Die öffentliche Vorschau erfordert Global Admin im Mandanten, um sowohl die Azure-Komponente zu konfigurieren als auch den lokalen Proxy zu installieren, und (natürlich) Domain Admin, um die Software zu installieren. Allerdings wird MFA für die Registrierung zunächst nicht unterstützt, so dass Sie MFA für das Global Admin-Konto, das Sie für die Installation des Proxys verwenden, deaktivieren müssen. Dies wird vor GAix behoben werden.
- Wenn Sie einige Ihrer eigenen Passwörter mit denen vergleichen möchten, die das NIST für gängige Passwörter hält, sollten Sie sich das NIST Bad Passwords Projekt auf Github ansehen. Dort finden Sie nicht nur Beispielcode, mit dem Sie Ihren eigenen client-seitigen Banned Password Checker erstellen können, sondern Sie können auch Ihre Passwörter auf Schwachstellen testen.
Microsoft setzt die Empfehlungen von NIST und Microsoft für Passwortrichtlinien aggressiv um. Durch das Verbot gängiger Passwortänderungen in Active Directory schließt Azure AD Password Protection einen wichtigen Bereich des Unternehmensrisikos durch Passwortangriffe. Ich empfehle Ihnen dringend, diesen Dienst zu testen, um ihn einzusetzen, sobald er allgemein verfügbar ist.
Das Verbot gängiger Passwörter ist natürlich nur ein Teil Ihrer Identitätssicherheitslösung. Der bedingte Zugriff mit MFA-Kontrolle auf Ihre Unternehmensanwendungen - sowohl Cloud-basiert als auch vor Ort - ist ein weiterer. Da sich die Unternehmensarchitekturen von einem Perimeter-basierten Sicherheitsmodell zu einem identitätsbasierten Modell bewegen, erfordert die Sicherheit von Unternehmensressourcen einen umfassenden Ansatz, der Identitäts-, Geräte- und Datensicherheit umfasst.
Ressourcen
ihttps://twitter.com/Alex_A_Simons/status/1009490805369655296
iihttps://twitter.com/Alex_A_Simons/status/1009500870872973312
iiihttps://twitter.com/Alex_A_Simons/status/1009923402998562816
viihttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/bd-p/AzureActiveDirectoryAMA
ixhttps://twitter.com/Alex_A_Simons/status/1009490805369655296
