Azure AD Password Protection
Parole!
Veröffentlicht in Ausgabe 08/2022 - SCHWERPUNKT
Wie der Name vermuten lässt, liegt das Augenmerk bei "Azure AD Password Protection" auf Passwörtern, und zwar in Bezug auf deren Änderung und den Schutz von Identitäten bei der Anmeldung. Da viele Unternehmen ein hybrides Setup verwenden, das AD also sowohl lokal als auch in Form des Azure Active Directory einsetzen, erfolgt die Konfiguration des Kennwortschutzes zwar im Azure AD, ist aber erweiterbar in Richtung lokaler AD-Domänendienste.
Funktion gut versteckt
Der "Azure AD-Kennwortschutz", wie die Funktion bei deutscher Portalsprache heißt, ist auf den ersten Blick nicht so einfach zu finden. Sie müssen sich im Azure AD Portal über das Portalmenü und dort über "Security", dann "Authentification methods" und dann wiederum über "Password Protection" zu den Einstellungen durchhangeln. Dort angekommen, finden Sie auf einer Seite kombiniert die beiden Funktionalitäten von Password Protection, nämlich "Custom Smart Lockout" und "Banned Password Policy".
Wir verwenden in diesem Beitrag die englischen Begriffe, was sich meist als sinnvoll herausstellt. Zwar findet sich die Übersetzung fast überall in den Portalfunktionen und auch in den zugehörigen Microsoft-Docs-Artikeln – aber nicht immer ist die deutsche Übersetzung aus technischer Sicht gelungen oder vermittelt direkt, was gemeint ist. Übrigens lässt sich die Portalsprache über die Portaleinstellungen (Zahnradsymbol) im Handumdrehen wechseln.
Wie der Name vermuten lässt, liegt das Augenmerk bei "Azure AD Password Protection" auf Passwörtern, und zwar in Bezug auf deren Änderung und den Schutz von Identitäten bei der Anmeldung. Da viele Unternehmen ein hybrides Setup verwenden, das AD also sowohl lokal als auch in Form des Azure Active Directory einsetzen, erfolgt die Konfiguration des Kennwortschutzes zwar im Azure AD, ist aber erweiterbar in Richtung lokaler AD-Domänendienste.
Funktion gut versteckt
Der "Azure AD-Kennwortschutz", wie die Funktion bei deutscher Portalsprache heißt, ist auf den ersten Blick nicht so einfach zu finden. Sie müssen sich im Azure AD Portal über das Portalmenü und dort über "Security", dann "Authentification methods" und dann wiederum über "Password Protection" zu den Einstellungen durchhangeln. Dort angekommen, finden Sie auf einer Seite kombiniert die beiden Funktionalitäten von Password Protection, nämlich "Custom Smart Lockout" und "Banned Password Policy".
Wir verwenden in diesem Beitrag die englischen Begriffe, was sich meist als sinnvoll herausstellt. Zwar findet sich die Übersetzung fast überall in den Portalfunktionen und auch in den zugehörigen Microsoft-Docs-Artikeln – aber nicht immer ist die deutsche Übersetzung aus technischer Sicht gelungen oder vermittelt direkt, was gemeint ist. Übrigens lässt sich die Portalsprache über die Portaleinstellungen (Zahnradsymbol) im Handumdrehen wechseln.
Aussperren bei falschem Passwort
Betrachten wir "Custom Smart Lockout" genauer, kommen Ihnen die damit verbundenen Parameter, also die Anzahl der Falscheingaben (Lockout Threshold) und die Dauer (Lockout Duration), für die ein Konto nach Anzahl der Falscheingaben gesperrt wird, vielleicht bekannt vor. Diese ähneln der aus den AD Domain Services bekannten Account-Lockout-Policy der Domänenrichtlinie und sie erfüllen dort den gleichen Zweck. Damit ist auch schon das Ziel der Einstellungen erklärt: nämlich einen Schutz gegen Falscheingaben zu bieten, wenn beispielsweise Dritte versuchen, bei der Anmeldung das Passwort eines Benutzers zu erraten – oder im noch größeren Stil das Verhindern von Brute-Force-Attacken.
Hat die Account-Lockout-Policy in einer AD-Domäne noch eher eine fixe und statische Funktionsweise, die sich strikt nach den Werten von Anzahl und Dauer richtet, so ist das Azure-AD-Pendant etwas dynamischer und intuitiver ausgelegt. Schließlich kommt der Begriff "smart" nicht von irgendwoher, sondern signalisiert eine differenzierte Arbeitsweise, je nachdem, welche Situation gerade vorliegt.
Schlauer Algorithmus
Bei der Anmeldung am Azure Active Directory werden die Falscheingaben für das Benutzerkonto für jedes Rechenzentrum gezählt. Meldet sich ein User von seinem gewohnten Arbeitsplatz aus an und findet parallel eine Attacke aus einer anderen Region statt, kann der Benutzer sich wie gewohnt einloggen und erfährt in seinem Benutzererlebnis keine Einschränkung. Genauso finden für die sogenannte "familiar" und "unfamiliar location" eigene Zähler Verwendung, um böswillige Aktionen zu erkennen.
Die Funktion kann aber noch mehr: Haben Sie in Ihrem hybriden Setup die Synchronisation von Password-Hashes aktiviert, erhöht sich der Zähler bei Falscheingabe nicht, wenn der Hash des eingegebenen Passworts einem Hash der vergangenen drei Kennwörter entspricht. Hierbei ist es verständlicherweise notwendig, dass alle Hashes in Azure liegen und die Option zum Synchronisieren der Hashes beim Azure AD Connect Server aktiviert ist.
Das Ganze funktioniert unabhängig von der gewählten Authentifizierungsmethode in Azure AD Connect. Die Einbeziehung alter Hashes ist sowohl bei PTA (Pass-Through Authentication) als auch bei PHS (Password Hash Sync) aktiv. Der Mechanismus geht aber noch weiter. Wird ein Passwort, nachdem die Anmeldung für das Konto gesperrt war, erneut falsch eingegeben, ist die Anmeldung direkt nach dem ersten Mal wieder gesperrt, und die Anzahl an Falscheingaben findet für eine erneute Sperrung keine Berücksichtigung, wohlwissentlich, dass da etwas nicht stimmen kann.
Zusammenspiel in hybriden Umgebungen
In einem hybriden Setup, und besonders wenn Sie PTA einsetzen, müssen Sie darauf achten, dass die Einstellungen von "Custom Smart Lockout" mit der "Account Lockout Policy" im Einklang sind, um lokale Benutzerkonten zu schützen. PTA verwendet zur Authentifizierung lokale Domänencontroller, die mit einem lokalen Proxyagent in Kontakt stehen, der wiederum die Anmeldung an einen DC zur Validierung weiterreicht. Erhöht sich in diesem Fall der Counter in Azure bei einem falschen Passwort, wird trotzdem der lokale DC kontaktiert, der gleichfalls seinen Zähler aufgrund des fehlgeschlagenen Anmeldeversuchs um eins erhöht. So ist es theoretisch möglich, dass ein Angreifer nicht nur die Azure-Identität, sondern auch das synchronisierte lokale Original in Mitleidenschaft zieht.
Um dies zu verhindern, muss der "Lockout Counter" im Azure AD geringer sein als der Counter in der Gruppenrichtlinie des lokalen AD. Gleichzeitig ist es ratsam, die Dauer, für die eine Anmeldung unmöglich ist, in Azure mit einem größeren Wert auszustatten. Nur so garantieren Sie maximalen Schutz im Zusammenspiel der beiden Verzeichnisdienste. Um zu prüfen, welche Einstellungen lokal in Ihren Domain Services aktuell gelten, navigieren Sie als Administrator ins betreffende GPO, normalerweise die "Default Domain Policy", zu "Computer Configuration / Policies / Windows Settings / Security Settings / Account Policies / Account Lockout Policy". Die beiden Werte, auf die es hier ankommt, befinden sich hinter "Account lockout threshold" und "Reset account lockout count after".
Die Überlegungen bezüglich des Zusammenspiels der Einstellung aus lokalem und Azure AD sind allerdings nur relevant, wenn Sie PTA verwenden, da in diesem Fall die On-Premises-Identitäten schützenswert sind. Microsoft erläutert dies und weitere Aspekte von "Custom Smart Lockout" in einem Docs-Artikel [1].
Das sieht der Anwender
Wurde durch Falscheingaben die maximal erlaubte Anzahl an Fehlversuchen erreicht, ist die Anmeldesperrung aktiv. Für diesen Zeitraum bekommt der Benutzer ein Fenster mit dem Hinweis zu sehen, dass die Anmeldung vorübergehend nicht gestattet ist. Für den Anwender bedeutet das, dass er die Zeitspanne, für die eine weitere Anmeldung unmöglich ist, abwarten muss. Erst wenn sie abgelaufen ist, funktioniert die Anmeldung mit dem Konto wieder. Auch ein Administrator kann hier nicht eingreifen und das Konto mal eben vorab wieder freischalten, selbst wenn der Hinweisdialog auf den Systemverwalter verweist. Als einzige Möglichkeit könnte der Benutzer selbst über "Self Service Password Reset" die Sperrung aufheben, ein vertrauenswürdiges Gerät und ein vertrauenswürdiger Standort vorausgesetzt.
Übrigens: Wenn Sie ein föderiertes Setup (ADFS) betreiben, lautet die dortige Funktion zum Schutz der Anmeldungen "Extranet Lockout and Extranet Smart Lockout" und bietet bei Anmeldungen über ADFS eine ähnliche Funktionalität.
Wirklich sichere Passwörter
Die zweite in Password Protection integrierte Funktion ist "Custom Banned Password". Anders als die eben vorgestellte Technologie trägt diese nicht zum Schutz direkt bei der Anmeldung bei, sondern die Absicherung erfolgt im Vorhinein, wenn der Anwender ein neues Passwort vergibt. Denn zu verhindern, dass Kennwörter schwach sind, ist auch eine Art des Schutzes, und genau dabei spielt die Funktionalität ihre Stärke aus.
Kern ist eine Liste mit verbotenen Wörtern oder besser gesagt Zeichenketten, die beim Eingeben von Kennwörtern nicht enthalten sein dürfen. Am Ende ist das Ganze ein Teil einer Richtlinie, da diverse Einstellungen in Azure AD den Umgang mit der Liste verschiedenartig gestalten, besonders wenn das lokale AD in die Arbeitsweise integriert sein soll, was in einer hybriden Konstellation sehr viel Sinn ergibt.
Aber der Reihe nach und eines vorweg: Microsoft stellt standardmäßig seine sogenannte "Banned Passwort List" bereit. Diese kommt immer zum Einsatz, sie ist nicht einsehbar, nicht änderbar und auch sonst hält Microsoft sich mit Details zu dieser Aufstellung bedeckt. Letztendlich findet eine Verzahnung von zwei Listen statt, der benutzerdefinierten und der Standardliste aus Redmond. Microsoft nennt dies die "combined banned password list". Immer wenn ein Passwort auf Gültigkeit geprüft wird, findet diese kombinierte Liste Verwendung.
Der erfahrene Administrator mag sich wundern und eventuell argwöhnen, dass eine Liste mit verbotenen Passwörtern keinen Sinn ergibt. Das ist grundsätzlich korrekt. Kommt eine derartige Liste aber als Teil eines Algorithmus zum Einsatz, hat dies durchaus Vorteile, wie wir uns später anschauen – die Strategie ist nämlich eine andere.
Standardphrasen unerwünscht
Bestimmte Inhalte sind standardmäßig als Teil eines Passwortes nur geschachtelt und kombiniert in hoher Komplexität erlaubt. So sind zum Beispiel "Bl@nk", "P@ssw0rd", "Secur1ty" sowie Teile des Benutzernamens oder des Tenants nicht als Passwörter zu verwenden – auch nicht, wenn sie mit Sonderzeichen drapiert sind.
Microsoft erwähnt, dass die Liste eine laufende Aktualisierung erfährt und dass der Konzern darauf verzichtet, externe Quellen oder Ähnliches als Referenz für schwache Passwörter zu verwenden. Das Azure-AD-Identity-Protection-Team analysiert vielmehr Telemetriedaten häufig verwendeter und kompromittierter Kennwörter aus der Azure Plattform und feilt an den Algorithmen zur Erkennung verwundbarer Identitäten.
Was sind nun in der Praxis sinnvolle Inhalte für die benutzerspezifische Liste verbotener Wörter? Wie der Name schon sagt, ist hier Platz für typische Begriffe aus dem individuellen Unternehmenskontext. Schließlich soll derlei nicht als Teil von Passwörtern dienen, da dies schwache Credentials zur Folge hätte. Typisch sind Markennamen, firmenspezifische und interne Begriffe oder Abkürzungen aus dem Umfeld der Organisation.
Übrigens sollte der Administrator darauf achten, dass jedes Wort in der Liste in einer Zeile steht, es vier bis 16 Zeichen Länge aufweist und maximal 1000 Einträge zulässig sind. Je länger die Liste ist, desto herausfordernder gestaltet sich der regelmäßige Check, ob die Einträge noch zeitgemäß sind – eine Tätigkeit, die zu den dokumentierten Arbeiten eines Azure-AD-Betriebshandbuchs gehört.
Custom Banned Password im Detail
Die Herausforderung besteht darin, mit einer Liste von einfachen Wörtern eine größtmögliche Reichweite an auszuschließenden schwachen Passwörtern zu erwirken. In der "Custom banned password list" Wörter mit Sonderzeichen zu integrieren, ist nicht sinnvoll und würde auch nicht alle Variationen abdecken. Denn beim Anlegen oder Ändern des Passworts wird dieses normalisiert und über ein Punktesystem bewertet.
Dabei ist wichtig zu erwähnen, dass das ganze Procedere nur der Ermittlung eines gültigen Passwortes dient. Ist der Vorgang abgeschlossen und das Kennwort als gültig hinterlegt, wird der Hash aus dem zu Beginn eingegebenen Passwort gebildet. Es geht also nur darum, ob das, was der Anwender als Passwort eingegeben hat, auch im Sinne des Administrators ein gültiges Passwort ist und keine durch Dritte leicht zu erratenden Schwächen aufweist.
Zuallererst wird das Kennwort also normalisiert und in eine leicht zu vergleichende und einfache Form gebracht. Großbuchstaben mutieren zu Kleinbuchstaben und Sonderzeichen werden durch repräsentative Zeichen des Alphabets ersetzt. Also wird zum Beispiel aus einem @ ein a, aus einem $ ein s und so weiter. Nach diesen beiden Schritten hat das eingegebene Passwort nicht mehr viel mit dem zu tun, was der Anwender eingegeben hat. Beispielsweise würde die Eingabe "BL@nK" umgewandelt in "blank". Etwas komplizierter würde aus "$3CureP@$$w0rd8" dann "securepassword8".
Im nächsten Schritt kommt wieder die bereits erwähnte kombinierte "Banned password list" ins Spiel. Sie gleicht die eben gebildete Zeichenkette beziehungsweise Teile daraus mit der Liste verbotener Wörter ab, was die Verwendung des Begriffs als Passwort erschwert. Es ist zwar nicht ganz ausgeschlossen, dass diese Begriffe sich nutzen lassen, ein Punktesystem sorgt jedoch dafür, dass das Passwort eine ausreichende Komplexität aufweist.
Denn der Algorithmus, der ein eingegebenes Passwort als gültig identifiziert, basiert auf einem Zähler. Hat dieser fünf Punkte erreicht, ist die eingegebene Zeichenkette als Passwort valide. Hierbei zählt jeder in der "Banned password list" enthaltene Begriff als ein Punkt und jedes weitere Zeichen oder Zahl als ein weiterer Punkt. Es dürfen also nicht zu wenige kritische Begriffe oder Sonderzeichen in einem Kennwort enthalten sein.
Schauen wir uns das an einem Beispiel an: Angenommen in unserer "Custom banned password list" ist der Begriff "Zugspitze" enthalten. Gibt ein Benutzer nun beim Erstellen eines neuen Passworts "!ZugspItze#" ein, wird daraus nach der Normalisierung für den Vergleich mit der Liste "!zugspitze#". Dabei wird die Zeichenkette weiter zerlegt und die Punkte ermittelt: "!" plus "zugspitze" plus "#" ergeben drei Punkte – das eingegebene Passwort ist ungültig.
Erweitern wir das Beispiel um zwei zusätzliche Zeichen, also "!ZugspItze#?1", und schauen wir uns nach der Normalisierung die Punkte an: "!" plus "zugspitze" plus "#" plus "?" plus "1" ergibt fünf Punkte. Nun handelt es sich um ein gültiges Passwort. Um unsere Exempel abzuschließen, nehmen wir noch einen weiteren Begriff: "!AlpspItze#". Da "Alpspitze" weder in der Microsoft-Liste noch in unserer enthalten ist, gilt es nicht als verbotener Begriff und ist als Passwort auch ohne Punktezählung gültig.
Diese Beispiele sollen verdeutlichen, wie der Algorithmus arbeitet und wie sinnvoll es für den Administrator ist, sich damit auseinanderzusetzen, um die Stärke der Passwörter im Unternehmen zu erhöhen und leicht zu erratende Passwörter auszuschließen.
Die technische Prozedur, die hier bei der Ermittlung werkelt, hat im Detail noch ein paar weitere Raffinessen zu bieten. Das und Formalitäten in Bezug auf die Lizenzierung beschreibt Microsoft unter [2].
Als kleiner Nachteil ist zu erwähnen, dass die "Banned password list" pauschal für alle Anwender zur Anwendung kommt. Unterschiedliche Listen für verschiedene Gruppen von Benutzern oder die Filterung für Zielgruppen im Tenant sind derzeit nicht möglich. Szenarien dieser Art könnten im Praxisalltag eines Administrators aber durchaus vorhanden sein.
Einbeziehen des lokalen AD
In einer hybriden Landschaft werden die Passwörter sowohl im lokalen Active Directory als auch im Azure AD geändert. Sollten Sie dies so konfiguriert haben, sorgt die Synchronisation dafür, dass die Hashes beiderorts immer aktuell sind. Wenn Sie nun für starke Passwörter sorgen möchten, ergibt dies aber nur Sinn, wenn das eben vorgestellte Verfahren unter Berücksichtigung verbotener Wörter für die Benutzer transparent abläuft und immer zur Anwendung kommt. Beispielsweise bei der lokalen Anmeldung, wenn gemäß Definition der Domänenrichtlinie ein User-Passwort zu erneuern ist oder wenn Sie über "https://aka.ms/sspr" das Azure-Password ändern möchten. Wollen Sie also das Wort "Zugspitze" ausschließen, um bei unserem Beispiel zu bleiben, soll dies ja ohne Umschweife jederzeit und überall der Fall sein.
Hierzu besteht die Möglichkeit, die Liste unerwünschter Kennwörter auch lokal vorzuhalten und dem Domänencontroller die Ermittlung starker Passwörter mit aufs Auge zu drücken. Alles, was Sie zur lokalen Bereitstellung des Azure-AD-Kennwortschutzes benötigen, finden Sie auf einer Downloadseite [3]. Hier stehen zwei Installationspakete bereit: eines für die Domänencontroller und eines für die Proxies. Das Setup auf einem DC beinhaltet eine Passwordfilter-DLL. Hierbei kommt eine dokumentierte Schnittstelle für Entwickler zum Einsatz, die es gestattet, eigenen Code zu erstellen, der das Verhalten bei Passworteingaben individuell erweitert.
Das zweite Installationspaket mit der Proxy-Komponente ist für einen oder mehrere Mitgliedsserver gedacht. Sie erhalten auf diese Weise die Funktion, die Liste mit unerlaubten Passwörtern regelmäßig herunterzuladen. Somit agieren Sie als Proxy-Server für die Domänencontroller. Wenn auch technisch möglich, ist es nicht ratsam, dass Domänencontroller direkt über das Internet mit Azure kommunizieren. Ein DC sollte niemals eine Verbindung zum Internet haben.
Fehlerversuche und Ausfallsicherheit
Selbst wenn das Setup einfach erscheint, sind doch unter der Haube recht vielschichtige, aufeinander basierende Komponenten am Start. Das beginnt mit den Endpunkten in Azure, die vom Proxy-Dienst aus erreichbar sein müssen, und geht bis hin zur Interaktion von Domänencontroller und Proxy. Wenn Sie in diesem Konstrukt Fehler vermuten, kann neben den grundlegenden PowerShell-Cmdlets das Ereignisprotokoll Hinweise zu Ungereimtheiten liefern. Sowohl Proxy-Dienst als auch der DC-Agent bringen ihre eigenen Ereignisprotokolle mit. Diese finden Sie im Event Viewer unterhalb der Microsoft-ProtokolleAußerdem ist es empfehlenswert, mehrere Proxy-Dienste zu installieren. Dadurch sind Sie auf der sicheren Seite, sollte ein Server ausfallen. Microsoft rät zu zwei Servern, es sind aber durchaus mehr möglich. Der DC-Agent ermittelt über einen Roundrobin-Verfahren, von welchem Proxy er die Liste der nicht erlaubten Passwörter bezieht. Antwortet ein Proxy-Server nicht, kontaktiert er den nächsten und so weiter. Für den Fall, dass sämtliche Proxies ausfallen, greift der DC-Agent auf jeden Fall auf seine zuletzt benutzte Liste verbotener Passwörter zurück und ist von dem Ausfall der Proxies nicht weiter betroffen – abgesehen davon, dass die Liste aus Azure nicht mehr up-to-date ist.
Schrittweise Implementierung
Wenn Sie die "Custom banned password list" nicht auf einen Schlag in der gesamten On-Premises-Landschaft ausrollen möchten, lässt sich das auch sukzessive umsetzen. Hierzu besteht zum einen die Möglichkeit, auf der Portalseite von "Password protection" statt "Enforced" auf den "Audit"-Modus zu wechseln. In dieser Betriebsart werden von einem Domänencontroller schwache Passwörter nicht abgelehnt, sondern es kommt lediglich zu einem Eintrag im Event Log. Der weist darauf hin, dass normalerweise ein Passwort als ungültig erkannt worden ist, es aufgrund der "Audit"-Einstellung aber zugelassen wurde. Einen ebensolchen Eintrag gibt es, wenn ein Passwort als stark identifiziert wurde. Auf diese Art kann der Administrator, ohne dass er die Funktion lokal scharfschaltet, über die Auswertung der DC-Event-Logs und über konsolidierte Protokolle mit seinem jeweiligen Monitoring ein Gefühl dafür bekommen, wie stark die Passwörter der Identitäten in seinem Netzwerk sind.
Eine weitere Möglichkeit, den Dienst schrittweise bereitzustellen, besteht darin, das Setup auf einem oder wenigen Domänencontrollern durchzuführen. Das geht problemlos. Nur Domänencontroller mit installierter DC-Agent-Komponente agieren gemäß der "Banned password list", alle anderen DCs wissen davon nichts und machen ihren Dienst weiter wie gehabt. Das hat den Vorteil, dass Sie zum Beispiel an einem Standort beginnen und Erfahrung mit der Funktion sammeln, bevor Sie die Installation in andere Regionen ausweiten.
Schutz von der Kommandozeile
Beide Setuproutinen, sowohl die für den Proxydienst als auch der DC-Agent, beinhalten ein PowerShell-Modul namens "AzureADPasswordProtection". Es handelt sich in beiden Varianten um das gleiche Modul. Entsprechende Befehle ergeben nur auf dem jeweiligen Zielsystem Sinn. Eine überschaubare Anzahl an Cmdlets hilft dabei, im Fehlerfall zu kontrollieren, ob die Verbindung Richtung Azure intakt ist, oder um zu prüfen, ob die Erweiterung auf dem Domänencontroller richtig tickt. Nach der Installation müssen Sie im ersten Schritt den Proxy registrieren und danach den Forest. Hierzu dienen entsprechende Cmdlets, die weitestgehend selbsterklärend sind.
Eine Liste der Cmdlets aus dem Modul erhalten Sie durch Eingabe von
get-command -module AzureADPasswordProtection. Für einen Rundumcheck, ob der Agent intakt ist, stehen Test-Cmdlets zur Verfügung. Test-AzureADPasswordProtectionDCAgentHealth etwa führt auf einem DC diverse Überprüfungen durch und vergewissert sich, ob der Forest korrekt registriert wurde und sich die Verbindungen herstellen ließen.Das Aufspielen der Agenten erfordert keinen Neustart der Server. Tests im Rahmen dieses Workshops haben aber gezeigt, dass zum Beispiel die PowerShell-Cmdlets erst dann saubere Arbeit liefern, nachdem die jeweilige Maschine durchgestartet war. Ohne Reboot erwarten Sie eventuell nichtssagende Fehlermeldungen.
Für weitere Informationen zur Installation und zu den PowerShell-Modulen sei Ihnen der bereits erwähnte Microsoft-Docs-Artikel [3] empfohlen. Hier haben Sie zudem die Möglichkeit, die Installationspakete herunterzuladen, und erfahren, welche Anforderungen es beispielsweise an das Netzwerk und die zu öffnenden Ports oder die erreichbaren Endpunkte gibt.
Fazit
Der Administrator benötigt viel Fingerspitzengefühl und genaue Kenntnisse seiner Anwenderschaft, um einerseits bei den Richtlinien für Passwörter eine ausreichende Komplexität zu garantieren, andererseits die Nutzer aber nicht unnötig zu gängeln.
Microsoft liefert mit Password Protection einen weiteren Baustein mit dem Fokus, die Wechselintervalle für Passwörter gering zu halten, dafür aber stärkere Kennwörter zu verwenden.
(ln)
Link-Codes
[1] Benutzerkonten mit Smart Lockout absichern: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout/
[2] Funktionsweise von Azure AD Password Protection: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad/
[3] Azure-AD-Kennwortschutz lokal bereitstellen: https://docs.microsoft.com/de-de/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy/