Ausgangslage: Komplex bedeutet noch nicht schwer zu erraten

Die Windows-Einstellung „Kennwort muss Komplexitätsvoraussetzungen entsprechen“ wird in vielen Active-Directory-Umgebungen als fertige Sicherheitsmaßnahme behandelt. Technisch prüft der native Filter jedoch nur eine kleine Zahl formaler Regeln: Der vollständige sAMAccountName wird ab drei Zeichen ohne Beachtung der Groß-/Kleinschreibung ausgeschlossen; beim Anzeigenamen gilt dies für durch Trennzeichen gebildete Tokens ab drei Zeichen. Zusätzlich muss das Kennwort Zeichen aus drei von fünf Kategorien verwenden. Zu diesen Kategorien gehören Großbuchstaben, Kleinbuchstaben, Ziffern, Sonderzeichen sowie sonstige alphabetische Unicode-Zeichen.

Das ist ein sinnvoller Mindestfilter, aber kein Qualitätsnachweis. Ein kurzer, verbreiteter Begriff mit vorhersehbarer Saison-, Jahreszahl- und Sonderzeichenvariation erfüllt die formale Regel häufig trotzdem. Der Filter kennt weder unternehmensspezifische Namen noch typische Tastaturfolgen oder häufig verwendete Basisbegriffe. Seine Regeln sind Bestandteil von Passfilt.dll und lassen sich nicht über eine zusätzliche GPO-Checkbox verfeinern.

In gewachsenen Domänen sieht die Ausgangslage deshalb oft so aus:

  • Die Komplexitätsoption ist aktiviert, die Mindestlänge liegt aber weiterhin bei sieben oder acht Zeichen.
  • Benutzer werden alle 30, 60 oder 90 Tage zu einem Wechsel gezwungen und variieren nur einen vorhersehbaren Teil ihres Kennworts.
  • Ein GPO in einer Benutzer- oder Workstation-OU soll die Domänenkennwortrichtlinie härten, wirkt für Domänenkonten aber nicht wie erwartet.
  • Fine-Grained Password Policies wurden über Jahre ergänzt; ihre Zuweisungen und Precedence sind nicht mehr nachvollziehbar.
  • Privilegierte, normale und technische Konten teilen dieselbe Richtlinie, obwohl ihre Authentifizierungs- und Betriebsmodelle verschieden sind.
  • Helpdesk-Reset, Self-Service, Provisioning, Passwort-Writeback und Fachanwendungen wurden nie gegen dieselben Zielregeln getestet.
  • In hybriden Umgebungen blockiert Microsoft Entra ID schwache Kennwörter in der Cloud, während lokale AD-Änderungen nur den nativen Windows-Filter durchlaufen.
  • Servicekonten mit Password never expires werden über Ausnahmen konserviert, statt auf gMSA oder einen verwalteten Secret-Lifecycle umgestellt zu werden.

Eine reine Zeichensortenregel löst außerdem keine Wiederverwendung. Sie verhindert weder ein bereits extern verwendetes Kennwort noch den Missbrauch eines gestohlenen Hashes, einer abgegriffenen Sitzung oder eines erfolgreich bestätigten Anmeldevorgangs. Kennwortqualität bleibt nur eine Schicht der Identitätssicherung.

Zielbild: Lange, einzigartige Kennwörter mit kontrollierten Ausschlüssen

Ein belastbarer Zielzustand besteht aus mehreren aufeinander abgestimmten Kontrollen:

  1. Die wirksame Policy ist pro Konto bekannt. Default Domain Password Policy und Fine-Grained Password Policies werden gemeinsam inventarisiert; repräsentative Benutzer werden über ihre resultierende Policy geprüft.
  2. Länge trägt den Hauptteil der Kennwortstärke. Für menschliche Konten ist ein dokumentierter Mindestwert definiert. Vierzehn Zeichen sind ein praktikabler Ausgangspunkt; höhere Werte werden erst nach Kompatibilitätsaudit auf allen Domain Controllern durchgesetzt.
  3. Die native Komplexitätsregel bleibt eine Baseline, nicht das Qualitätsmodell. Sie wird nicht als Ersatz für Länge, Sperrlisten oder risikobasierte Authentifizierung dokumentiert.
  4. Vorhersehbare Basisbegriffe verschlechtern die Kennwortbewertung. Eine zentral verwaltete globale und organisationsspezifische Sperrliste ergänzt die AD-Regeln bei Kennwortänderungen und -resets; normalisierte Treffer fließen in eine Gesamtbewertung ein.
  5. Nur wenige Kontoklassen erhalten eigene PSOs. Fine-Grained Password Policies werden über kontrollierte globale Sicherheitsgruppen zugewiesen und nicht als Sammlung individueller Benutzerausnahmen betrieben.
  6. Kennwortalter ist eine bewusste Risikoentscheidung. Periodische Wechsel ohne Anlass werden nicht mit Sicherheit verwechselt. Vorgaben aus Regulierung oder Altanwendungen bleiben dokumentiert; kompromittierte oder unsicher übertragene Kennwörter werden sofort geändert.
  7. Technische Identitäten nutzen verwaltete Secrets. gMSA, Managed Identities, Zertifikate oder ein Vault mit automatischer Rotation ersetzen manuell gepflegte Dauerkennwörter, soweit die Anwendung dies unterstützt.
  8. MFA und phishing-resistente Verfahren begrenzen den Restschaden. Privilegierte und extern erreichbare Zugänge verlassen sich nicht allein auf ein starkes Kennwort.
  9. Jeder Änderungsweg ist getestet. Anmeldung, Self-Service, Helpdesk-Reset, Joiner/Mover/Leaver-Prozesse, Passwort-Writeback und automatisierte Provisionierung liefern ein konsistentes Ergebnis.
  10. Audit, Rollout und Ausnahmeprozess sind messbar. Blockierte Muster, technische Fehler, DC-Abdeckung, Helpdesk-Auswirkung und Rest-Ausnahmen besitzen Owner und Review-Termin.

Das Ziel ist nicht, Benutzer zu möglichst vielen Sonderzeichen zu zwingen. Es ist eine Richtlinie, die erratbare Kennwörter zuverlässig ablehnt, lange merkbare Passphrasen zulässt und technische Abhängigkeiten nicht still umgeht.

Umsetzung: Kennwortrichtlinie als kontrollierten Identitätsdienst betreiben

1) Default Policy und PSOs read-only erfassen

Die Inventur gehört auf einen administrativ geschützten Managementhost mit aktuellem ActiveDirectory-Modul. Sie liest keine Kennwörter und keine internen Credential-Attribute. Die Ausgabe enthält jedoch Konten- und Gruppennamen und gehört deshalb nicht in offene Tickets oder ungeschützte Shares.

& {
  Set-StrictMode -Version Latest
  Import-Module ActiveDirectory -ErrorAction Stop

  $domain = Get-ADDomain -ErrorAction Stop
  $defaultPolicy = Get-ADDefaultDomainPasswordPolicy `
    -Identity $domain.DNSRoot `
    -ErrorAction Stop

  [pscustomobject]@{
    Scope                         = $domain.DNSRoot
    PolicyType                    = 'DefaultDomainPasswordPolicy'
    ComplexityEnabled             = $defaultPolicy.ComplexityEnabled
    MinPasswordLength             = $defaultPolicy.MinPasswordLength
    PasswordHistoryCount          = $defaultPolicy.PasswordHistoryCount
    MinPasswordAge                = $defaultPolicy.MinPasswordAge
    MaxPasswordAge                = $defaultPolicy.MaxPasswordAge
    LockoutThreshold              = $defaultPolicy.LockoutThreshold
    LockoutObservationWindow      = $defaultPolicy.LockoutObservationWindow
    LockoutDuration               = $defaultPolicy.LockoutDuration
    ReversibleEncryptionEnabled  = $defaultPolicy.ReversibleEncryptionEnabled
  }

  Get-ADFineGrainedPasswordPolicy -Filter * -ErrorAction Stop |
    Sort-Object Precedence |
    Select-Object Name, Precedence, ComplexityEnabled, MinPasswordLength,
      PasswordHistoryCount, MinPasswordAge, MaxPasswordAge,
      LockoutThreshold, LockoutObservationWindow, LockoutDuration,
      ReversibleEncryptionEnabled, AppliesTo
}

Die Liste der PSOs zeigt Zuweisungen, aber noch nicht sicher die wirksame Richtlinie eines konkreten Benutzers. Direkt zugewiesene und gruppenbasierte PSOs sowie deren numerische Priorität können ein unerwartetes Ergebnis erzeugen. Prüfe deshalb repräsentative Konten aus jeder Klasse separat:

Get-ADUserResultantPasswordPolicy `
  -Identity 'pilot.user' `
  -ErrorAction Stop |
  Select-Object Name, Precedence, ComplexityEnabled, MinPasswordLength,
    PasswordHistoryCount, MinPasswordAge, MaxPasswordAge,
    ReversibleEncryptionEnabled

Liefert der Befehl kein PSO, gilt für dieses Konto die Default Domain Password Policy. Für den Projektstart reichen bewusst ausgewählte Canary-Konten; eine ungedrosselte Abfrage jedes Benutzers gegen einen Domain Controller ist weder nötig noch betrieblich sauber.

Ergänze die Policy-Inventur um alle realen Kennwortpfade: Windows-Dialog, Self-Service-Portal, Helpdesk-Tool, Identity-Governance-Plattform, Passwort-Writeback, LDAP-Anwendung, Unix-Integration und technische Provisionierung. Ein grüner GPO-Report beweist nicht, dass diese Clients lange Kennwörter korrekt annehmen oder verständliche Fehler anzeigen.

2) Kontoklassen und konkrete Zielwerte festlegen

Ein einzelner Zahlenwert für alle Identitäten ist selten ausreichend. Die Policy-Matrix sollte mindestens folgende Klassen trennen:

  • Normale personenbezogene Konten: lange, einzigartige Kennwörter oder Passphrasen, Sperrliste, History und MFA für relevante Zugänge.
  • Privilegierte personenbezogene Konten: mindestens dieselbe Kennwortqualität, zusätzlich getrennte Admin-Identität, phishing-resistente MFA und begrenzte Anmeldeziele. Eine höhere Zeichenzahl allein ersetzt diese Kontrollen nicht.
  • Klassische Servicekonten: Migration auf gMSA bevorzugen; verbleibende Secrets werden zufällig erzeugt, im Vault gehalten, regelmäßig technisch rotiert und nicht interaktiv verwendet.
  • Break-Glass-Konten: lange zufällige Secrets, geschützte Offline-Hinterlegung, starke Überwachung und eigener Testprozess. Sie erhalten keine bequeme, vorhersehbare Ausnahme.
  • Legacy- und Appliance-Konten: nur zeitlich begrenzte PSO-Ausnahme mit technischem Owner, dokumentierter Maximallänge des Produkts, Kompensationskontrollen und Migrationsdatum.

Vierzehn Zeichen bilden für viele Umgebungen einen belastbaren Startwert, nicht automatisch das Endziel. Ein Ziel oberhalb von 14 Zeichen verbessert die Reserve für Passphrasen, berührt aber alte Kennwort-APIs, Cluster-, Service-, Appliance- und Provisioning-Pfade. Der Wert wird deshalb aus Schutzbedarf, Plattformbestand und Testergebnis abgeleitet.

Kennworthistorie und Mindestalter müssen zusammenpassen. Eine History ohne sinnvolles Mindestalter kann durch schnelle aufeinanderfolgende Änderungen umgangen werden. Ein Mindestalter darf andererseits keinen Incident-Reset blockieren; der Helpdesk benötigt einen kontrollierten administrativen Prozess. Ein maximales Kennwortalter wird nicht blind aus einer historischen Baseline übernommen. Wo eine Frist weiterhin vorgeschrieben ist, werden Zweck, betroffene Konten und Nebenwirkungen explizit dokumentiert.

Eine Verkürzung von MaxPasswordAge kann Konten unmittelbar ablaufen lassen, wenn pwdLastSet plus neuer Maximalwert bereits in der Vergangenheit liegt. Simuliere die Treffermenge und plane Kommunikation, Ausnahmen und Resetkapazität, bevor dieser Wert geändert wird.

3) Die Domain Policy an der richtigen Stelle verwalten

Die Kontorichtlinie für Domänenkonten stammt aus der wirksamen GPO auf Domänenebene beziehungsweise aus einem PSO. Eine Kennwortrichtlinie, die nur an eine Benutzer-, Server- oder Workstation-OU gebunden ist, härtet Domänenbenutzer nicht selektiv. Auf Mitgliedssystemen beeinflusst eine solche Einstellung gegebenenfalls deren lokale SAM-Konten – eine andere Schutzfläche.

Verwalte die autoritative Domain-Root-GPO über Change Control, Backup und Peer Review. Ob dafür die Default Domain Policy oder eine klar priorisierte dedizierte GPO verwendet wird, muss im Betriebsmodell eindeutig sein; konkurrierende Quellen sind zu vermeiden. Der GPO-Pfad lautet:

Computerkonfiguration
  Richtlinien
    Windows-Einstellungen
      Sicherheitseinstellungen
        Kontorichtlinien
          Kennwortrichtlinien

Ein direkter Cmdlet-Change eignet sich nur als kontrollierter Teil desselben Runbooks, weil eine widersprechende GPO den Wert später erneut setzen kann. -WhatIf zeigt ausschließlich den beabsichtigten Verzeichnis-Write; es testet weder GPO-Konflikte noch DC-, Client- oder Anwendungskompatibilität. Die geplante Baseline kann damit zuerst auf Ziel und Parameter geprüft werden:

$domain = Get-ADDomain -ErrorAction Stop

$policy = @{
  Identity                        = $domain.DNSRoot
  ComplexityEnabled               = $true
  MinPasswordLength               = 14
  PasswordHistoryCount            = 24
  MinPasswordAge                  = [timespan]::FromDays(1)
  ReversibleEncryptionEnabled     = $false
}

Set-ADDefaultDomainPasswordPolicy @policy -WhatIf

Der Beispielwert für MaxPasswordAge fehlt absichtlich. Er ist keine technische Konstante und muss zum beschlossenen Rotationsmodell passen. Nach Freigabe werden die finalen Werte über den autoritativen Policy-Weg umgesetzt, gegen mehrere DCs geprüft und mit den dokumentierten Sollwerten verglichen.

4) Die domänenweite GPO-Baseline über 14 Zeichen erst auditieren

Für eine domänenweite GPO-Baseline oberhalb der historischen 14-Zeichen-Grenze reicht es nicht, nur MinPasswordLength zu erhöhen. Das Längenaudit ist auf entsprechend gepatchten Windows-Server-2016- und -2019-DCs verfügbar; Microsoft dokumentiert die Durchsetzung ab 15 Zeichen für Windows Server, Version 2004, und spätere Servergenerationen. Alle DC-Versionen und administrativen Werkzeuge müssen den erweiterten Bereich unterstützen; alte Anwendungen können Kennwortänderungen, Servicekonfiguration oder gespeicherte Secrets weiterhin auf kürzere Werte begrenzen.

Das sichere Vorgehen ist gestuft:

  1. Alle Domain Controller und administrativen Managementsysteme auf einen unterstützten, aktuellen Patchstand bringen.
  2. Minimum password length audit mit dem geplanten Zielwert für die Domain Controller aktivieren.
  3. Directory-Services-SAM-Events 16977, 16978 und 16979 zentral sammeln. Event 16978 zeigt Kennwortsetzungen unterhalb des Auditwerts; 16979 weist auf eine ungültige Konstellation hin.
  4. Das Audit über einen repräsentativen Zeitraum laufen lassen. Microsoft empfiehlt für die Suche nach seltenen Softwarepfaden drei bis sechs Monate.
  5. Jede betroffene Anwendung entweder auf lange Secrets umstellen, aktualisieren oder über eine eng begrenzte FGPP vorübergehend kompatibel halten.
  6. Erst wenn alle Domain Controller die Durchsetzung unterstützen, Relax minimum password length limits aktivieren und den höheren Mindestwert setzen.
  7. Replikation, Policy-Event 16977, das Ausbleiben von 16979 und alle Kennwortänderungspfade erneut testen.

Auch Read-Only Domain Controller gehören bei der Plattformprüfung für die erweiterte Mindestlänge in den Scope. Ein auf 16 oder 20 gesetzter Wert, der wegen einer unvollständigen Konfiguration effektiv bei 14 bleibt, erzeugt nur Compliance-Schein.

FGPP bilden die Mindestlänge über ein separates Password Settings Object ab und können höhere Werte gezielt für Kontogruppen vorgeben. Das ersetzt jedoch keinen Kompatibilitätstest: Dieselben Reset-, Provisioning-, Service- und Anwendungswege müssen auch für ein PSO oberhalb von 14 Zeichen funktionieren.

Eine Massenänderung bestehender Kennwörter ist für diesen Schritt nicht erforderlich. Die neue Mindestlänge greift bei der nächsten Kennwortsetzung oder -änderung. Ein erzwungener gleichzeitiger Wechsel würde Helpdesk, Replikation und abhängige Anwendungen unnötig belasten.

5) Fine-Grained Password Policies klein und überprüfbar halten

PSOs erlauben unterschiedliche Kennwort- und Lockout-Regeln innerhalb einer Domäne. Sie werden auf Benutzerobjekte oder globale Sicherheitsgruppen angewendet, nicht auf OUs. Ein direkt einem Benutzer zugewiesenes PSO gewinnt gegenüber gruppenbasierten PSOs; innerhalb derselben Zuweisungsebene gewinnt die niedrigste numerische Precedence. Verschachtelte Gruppen können die Erwartung zusätzlich verändern. Der Betriebsnachweis ist deshalb immer Get-ADUserResultantPasswordPolicy, nicht nur die Mitgliederliste einer Zielgruppe. Für den aktuellen Microsoft-Verwaltungsweg sind außerdem mindestens Domain Functional Level Windows Server 2012 und aktuelle RSAT-Werkzeuge einzuplanen.

Vor der Änderung eines bereits genehmigten PSO werden Werte und Gruppenzuweisung mit -WhatIf geprüft:

Set-ADFineGrainedPasswordPolicy `
  -Identity 'Privileged-Human-Accounts' `
  -ComplexityEnabled $true `
  -MinPasswordLength 16 `
  -PasswordHistoryCount 24 `
  -ReversibleEncryptionEnabled $false `
  -WhatIf

Add-ADFineGrainedPasswordPolicySubject `
  -Identity 'Privileged-Human-Accounts' `
  -Subjects 'GG-Password-Privileged-Humans' `
  -WhatIf

Die Objektnamen und Werte sind technische Beispiele und werden durch genehmigte Objekte aus dem Change ersetzt. -WhatIf simuliert auch hier nur den Verzeichnis-Write. Nach der Freigabe werden Änderung und Zuweisung ohne -WhatIf ausgeführt, anschließend wird die resultierende Policy jedes Subjects neu berechnet und ein nicht privilegiertes Canary-Konto vorübergehend über denselben Gruppenpfad getestet. Kennwortalter und Lockout bleiben in diesem Beispiel bewusst unverändert; jede Änderung daran ist separat zu simulieren und zu genehmigen. Ein PSO sollte eine stabile Kontoklasse abbilden, einen Owner besitzen und gegen unbeabsichtigtes Löschen geschützt sein. Individuelle Benutzerzuweisungen sind Ausnahmen mit Ablaufdatum, nicht der normale Rolloutmechanismus.

6) Vorhersehbare Kennwörter mit einer Sperrliste blockieren

Der native AD-Filter erkennt keine verbreiteten Basisbegriffe und keine organisationsspezifischen Namen. Microsoft Entra Password Protection kann diese Lücke für AD DS ergänzen: Die globale Sperrliste und eine kleine benutzerdefinierte Liste werden bei lokalen Kennwortänderungen und administrativen Resets ausgewertet. Begriffe werden dabei normalisiert und mitsamt typischen Varianten in einer Punktebewertung berücksichtigt; ein Treffer wird innerhalb eines insgesamt ausreichend starken Kennworts nicht zwangsläufig abgelehnt. Die benutzerdefinierte Liste gehört für Firmen-, Produkt-, Standort- und interne Projektnamen genutzt – nicht als importierte Sammlung Millionen kompromittierter Kennwörter.

Für einen belastbaren On-Premises-Rollout gelten klare Architekturgrenzen:

  • Der Proxy-Service ist zwingend erforderlich. Für Redundanz empfiehlt Microsoft mindestens zwei Proxys pro Forest auf getrennten Member Servern.
  • Domain Controller benötigen keinen direkten Internetzugang; sie sprechen über RPC mit einem Proxy und verwenden eine lokal zwischengespeicherte Policy.
  • Der DC-Agent wird nach dem Pilot auf jedem beschreibbaren Domain Controller jeder geschützten Domäne installiert. RODCs verarbeiten Kennwortänderungen nicht selbst und benötigen den Agenten nicht.
  • SYSVOL muss DFSR verwenden; Plattform-, .NET-, Runtime-, Netzwerk- und Neustartvoraussetzungen werden vor dem Rollout geprüft.
  • Alle Proxys und die Gesamtstruktur werden an denselben Microsoft-Entra-Tenant gebunden.
  • Die erforderlichen Microsoft-Entra-ID-P1- oder -P2-Lizenzen werden für die geschützten Benutzer vor Projektfreigabe bestätigt.
  • Die On-Premises-Policy gilt für alle Benutzer einer geschützten Domäne; sie lässt sich nicht auf eine Pilotgruppe oder einzelne PSO-Subjects begrenzen.
  • Klartextkennwörter verlassen den Domain Controller bei der Prüfung nicht.
  • Der DC-Agent verwendet die zuletzt erfolgreich geladene Policy. Hat ein DC noch nie eine gültige Policy erhalten, wird ein Kennwortkandidat akzeptiert und der Zustand protokolliert; ein aktuelles PasswordPolicyDateUTC auf jedem beschreibbaren DC ist deshalb ein Enforcement-Gate.

Eine Teilinstallation ist nur ein Pilot, kein sicherer Endzustand. Clients wählen den DC für eine Kennwortänderung nicht nach dem Agentenstatus aus. Fehlt der Agent auf einem beschreibbaren DC, kann dort ein Kennwort akzeptiert werden, das ein anderer DC abgelehnt hätte.

Beginne in Audit. Schwache Kandidaten werden dabei protokolliert, aber noch akzeptiert. Prüfe über einen normalen Helpdesk- und Self-Service-Zyklus mindestens:

  • Benutzeränderung und administrativen Reset,
  • neu angelegte Konten und temporäre Startkennwörter,
  • Self-Service Password Reset und Passwort-Writeback,
  • Provisioning- und IAM-Workflows,
  • alle beschreibbaren DCs und Standorte,
  • Policy-Download, Proxy-Ausfall und Betrieb aus dem lokalen Cache.

Das mitgelieferte Summary-Reporting kann die Ereignisse pro Gesamtstruktur, Domäne oder DC zusammenfassen. Auf einem Proxy-System mit dem installierten Modul liefern folgende Abfragen in einer 64-Bit-PowerShell Agentenstatus und Ergebnisübersicht:

Import-Module AzureADPasswordProtection -ErrorAction Stop

Get-AzureADPasswordProtectionProxy -Forest
Get-AzureADPasswordProtectionDCAgent -Forest |
  Select-Object ServerFQDN, Domain, PasswordPolicyDateUTC, HeartbeatUTC
Get-AzureADPasswordProtectionSummaryReport -Forest

Das Summary-Reporting fragt die DC-Agent-Logs remote ab und kann in großen Umgebungen Last erzeugen. Für den Dauerbetrieb sind zentral weitergeleitete Events und eine SIEM-Auswertung mit definierten Schwellen besser geeignet. HeartbeatUTC und PasswordPolicyDateUTC werden ungefähr stündlich aktualisiert und enthalten zusätzlich Replikationslatenz; veraltete Werte sind ein Agent- oder Policy-Health-Signal. Audit-Treffer 10024/10025, Ereignisse 10016/10017, technische Fehler 10012/10013 und zugehörige 300xx-Details müssen über CorrelationId und den aktiven Modus korreliert werden. 10016/10017 allein beweisen keine harte Ablehnung. Wechsel erst zu Enforced, wenn alle beschreibbaren DCs abgedeckt, die Agenten gesund und legitime Resetpfade fehlerfrei sind.

Bereits vorhandene Kennwörter werden nicht rückwirkend bewertet. Der Filter sieht den Klartext nur bei einer neuen Kennwortsetzung. Plane deshalb einen risikobasierten Übergang statt einer unkoordinierten globalen Zwangsänderung. Konten mit Password never expires benötigen einen eigenen Migrations- oder Rotationsplan.

7) Benutzerführung und Helpdesk vor Enforcement vorbereiten

Lange Passphrasen funktionieren nur, wenn die Benutzeroberflächen sie vollständig annehmen und Menschen wissen, welche Muster vermieden werden sollen. Die Kommunikation sollte positiv und konkret sein:

  • lange, einzigartige Passphrase statt kurzer Pflichtvariation,
  • keine Firmen-, Produkt-, Standort- oder Personennamen,
  • keine Wiederverwendung privater oder externer Kennwörter,
  • Passwortmanager für nicht merkbare Anwendungskennwörter,
  • sofortige Meldung bei Phishing, versehentlicher Offenlegung oder unerwarteter MFA-Anfrage.

Behandle die globale und interne Sperrliste nicht als Website- oder Helpdesk-Inhalt. Gehe trotzdem davon aus, dass organisationsspezifische Begriffe erraten werden können; ihre Geheimhaltung ist keine Sicherheitsgrenze. Clientseitige Fehlermeldungen sind bei lokalen AD-Resets häufig generisch und nennen nur Länge, Komplexität oder History. Helpdesk und Self-Service-Oberfläche brauchen deshalb einen verständlichen Leitfaden, ohne konkrete Treffer unnötig preiszugeben.

Temporäre Kennwörter gehören zufällig erzeugt, über einen geschützten Kanal ausgegeben und bei der ersten Nutzung geändert. Ein Helpdesk-Agent sollte weder ein leicht erratbares Startmuster verwenden noch Kennwortkandidaten in Tickets oder Chatprotokolle kopieren.

8) Kennwortschutz mit MFA und Credential-Härtung ergänzen

Eine bessere Kennwortrichtlinie reduziert vorhersehbare Secrets. Sie verhindert nicht Phishing, Token-Diebstahl, Pass-the-Hash, gestohlene Kerberos-Tickets oder die Kompromittierung eines Domain Controllers. Besonders privilegierte Zugänge benötigen deshalb weitere Grenzen:

  • phishing-resistente MFA oder kennwortlose Anmeldung, wo der Zielpfad dies unterstützt,
  • getrennte Admin-Konten und gehärtete Admin Workstations,
  • Credential Guard, LSASS Protected Process und begrenzte lokale Anmeldung,
  • Schutz von DCs, Replikationsrechten, Backups und Identity-Management-Systemen,
  • Erkennung von Password Spraying, ungewöhnlichen Reset-Wellen und risikobehafteten Anmeldungen.

Benutzerdefinierte Password-Filter-DLLs sind kein leichtgewichtiger Ersatz. Solcher Code wird auf allen DCs in einem hochprivilegierten Prozess geladen. Falls eine Drittanbieterlösung statt Microsoft Entra Password Protection eingesetzt wird, benötigt sie eine belastbare Lieferkette, Signaturprüfung, Patch- und Rollbackprozess, Offlinefähigkeit, Lasttests und eine Architektur ohne Abfluss von Kennwortkandidaten.

Vorteile: Weniger erratbare Kennwörter, klarere Policy

  • Vorhersehbare Muster werden tatsächlich adressiert. Eine Sperrliste ergänzt die formale Zeichensortenprüfung um verbreitete und organisationsspezifische Begriffe.
  • Länge erhöht die Reserve. Lange Passphrasen sind in der Praxis leichter merkbar als kurze, ständig wechselnde Sonderzeichenmuster.
  • Die wirksame Regel wird nachweisbar. Default Policy, PSOs und resultierende Benutzerpolicy lassen sich getrennt prüfen.
  • Kontoklassen werden sauberer betrieben. Menschen, Servicekonten, Break-Glass- und Legacy-Identitäten erhalten passende statt zufällige Ausnahmen.
  • Der Rollout ist messbar. Längenaudit und Password-Protection-Audit zeigen technische Abhängigkeiten vor dem Enforcement.
  • Hybride Identitäten erhalten konsistentere Kontrollen. Lokale AD-Änderungen können dieselben globalen und organisationsspezifischen Sperrbegriffe berücksichtigen wie Cloud-Änderungen.
  • Helpdesk-Regeln werden belastbarer. Temporäre Kennwörter, Resetpfade und Fehlersituationen sind Teil des Designs statt nachträgliche Sonderfälle.

Nachteile und Grenzen: Kennwörter bleiben ein angreifbarer Faktor

  • Ein starkes Kennwort verhindert kein Phishing. MFA, risikobasierte Kontrollen und sichere Adminpfade bleiben notwendig.
  • Mehr als 14 Zeichen kann Legacy-Systeme brechen. Anwendungen, Appliances und APIs müssen über einen längeren Auditzeitraum geprüft werden.
  • Microsoft Entra Password Protection erweitert die Tier-0-Betriebsfläche. Proxy, DC-Agent, Registrierung, Updates, Monitoring und Lizenzvoraussetzungen brauchen Owner und Lifecycle.
  • Ein DC-Agent benötigt einen Neustart. Rollout und Update müssen in die Verfügbarkeitsplanung der Domain Controller passen.
  • Teilabdeckung erzeugt inkonsistentes Verhalten. Der Endzustand erfordert Agenten auf allen beschreibbaren DCs der geschützten Domäne.
  • Bestandskennwörter bleiben zunächst unverändert. Die neue Sperrliste greift erst beim nächsten Setzen oder Ändern.
  • Clientfehler sind oft unspezifisch. Benutzer und Helpdesk sehen nicht zuverlässig, welcher Filter das Kennwort abgelehnt hat.
  • PSOs erhöhen die Komplexität. Falsche Precedence, direkte Zuweisungen und verschachtelte Gruppen können den erwarteten Scope verändern.
  • Sperrlisten sind keine Leak-Datenbank. Sie reduzieren häufige Muster, garantieren aber nicht, dass ein Kennwort nie extern kompromittiert wurde.
  • Mehr Telemetrie braucht Betrieb. Events müssen geschützt, korreliert und bewertet werden; Kennwortkandidaten dürfen niemals protokolliert werden.

Typische Stolperfallen

  • ComplexityEnabled = True mit einem starken Kennwort gleichsetzen.
  • Vier Zeichensorten erzwingen und dabei kurze, vorhersehbare Muster fördern.
  • Mindestlänge erhöhen, ohne Self-Service, Helpdesk, Provisioning und Anwendungen zu testen.
  • Mehr als 14 Zeichen setzen, ohne Längenaudit, unterstützte DC-Versionen und Relax minimum password length limits zu prüfen.
  • Kennwortrichtlinien an eine OU binden und eine selektive Wirkung auf Domänenkonten erwarten.
  • AppliesTo eines PSO lesen, aber die resultierende Benutzerpolicy nicht prüfen.
  • Viele individuelle PSO-Ausnahmen ohne Owner und Ablaufdatum anlegen.
  • Niedrige numerische Precedence fälschlich als niedrige Priorität interpretieren.
  • Microsoft Entra Password Protection nur auf einem Teil der beschreibbaren DCs belassen.
  • Audit dauerhaft aktiv lassen, ohne Kriterien und Termin für Enforcement festzulegen.
  • Eine riesige Leak-Liste als organisationsspezifische Sperrliste importieren.
  • Firmenname, Standort und Produktnamen blockieren, aber alternative Schreibweisen und lokale Sprachen nicht pflegen.
  • Bestehende Kennwörter nach Agenteninstallation als bereits geprüft betrachten.
  • Alle Benutzer gleichzeitig zur Änderung zwingen und dadurch Helpdesk- und Authentifizierungsstürme erzeugen.
  • Servicekonten über schwache PSOs dauerhaft ausnehmen, statt auf gMSA oder Vault-Rotation zu migrieren.
  • Temporäre Helpdesk-Kennwörter nach einem öffentlichen Muster erzeugen oder in Tickets protokollieren.
  • Kennwortstärke als Ersatz für MFA, Tiering, LSASS-Schutz oder DC-Härtung behandeln.
  • Eine Drittanbieter-Filter-DLL ohne Tier-0-Supply-Chain- und Ausfallprüfung installieren.

Projekt-Checkliste

  • [ ] Default Domain Password Policy jeder Domäne als Objekt exportieren.
  • [ ] Alle PSOs mit Precedence, Werten, Schutzstatus und Zuweisungen erfassen.
  • [ ] Resultierende Policy für repräsentative normale, privilegierte, technische und Legacy-Konten prüfen.
  • [ ] Autoritative Domain-Root-GPO und konkurrierende Policy-Quellen identifizieren.
  • [ ] Windows-, Self-Service-, Helpdesk-, Writeback-, Provisioning- und Anwendungspfade inventarisieren.
  • [ ] Kontoklassen, Owner und gewünschte Authentifizierungsverfahren dokumentieren.
  • [ ] Mindestlänge und Passphrasenregeln pro Kontoklasse beschließen.
  • [ ] Kennworthistorie, Mindestalter, maximales Alter und Lockout gemeinsam bewerten.
  • [ ] Native Komplexität bewusst als Baseline aktivieren oder eine abweichende Strategie ausdrücklich begründen.
  • [ ] Reversible Kennwortspeicherung in Default Policy und allen PSOs deaktiviert bestätigen.
  • [ ] Für die Default-Domain-GPO über 14 Zeichen alle DCs einschließlich RODCs auf eine unterstützte Enforcement-Generation und Managementsysteme auf aktuellen Patchstand bringen.
  • [ ] Minimum password length audit mit dem geplanten Zielwert aktivieren.
  • [ ] Events 16977, 16978 und 16979 zentral sammeln und technische Verursacher zuordnen.
  • [ ] Audit über seltene Batch-, Cluster-, Appliance- und Wartungszyklen laufen lassen.
  • [ ] Inkompatible Systeme aktualisieren, migrieren oder mit befristeter FGPP isolieren.
  • [ ] Erst danach erweitertes Längenlimit und finalen Mindestwert kontrolliert erzwingen.
  • [ ] Kleine, gruppenbasierte PSOs mit eindeutiger Precedence und Löschschutz einführen.
  • [ ] Canary-Konten vor jeder breiten PSO-Zuweisung testen.
  • [ ] Globale und organisationsspezifische Sperrliste fachlich planen.
  • [ ] Mindestens zwei Password-Protection-Proxys auf getrennten Member Servern bereitstellen.
  • [ ] DFSR-, Netzwerk-, Runtime-, Tenant- und Neustartvoraussetzungen prüfen.
  • [ ] DC-Agent zunächst im Auditmodus auf Pilot-DCs testen.
  • [ ] Agent anschließend auf allen beschreibbaren DCs der geschützten Domänen ausrollen.
  • [ ] Agent-, Proxy-, Policy-Download- und Cache-Gesundheit zentral überwachen.
  • [ ] HeartbeatUTC und PasswordPolicyDateUTC auf jedem beschreibbaren DC als Freigabe- und Drift-Signal prüfen.
  • [ ] Audit-Treffer, technische Fehler und Helpdesk-Auswirkung vor Enforcement auswerten.
  • [ ] Enforcement mit klaren Freigabekriterien aktivieren und gegen jeden Resetpfad testen.
  • [ ] Bestehende Kennwörter risikobasiert in den neuen Prüfpfad überführen.
  • [ ] Password never expires-Konten separat prüfen und Servicekonten auf gMSA oder Vault-Rotation migrieren.
  • [ ] Benutzer- und Helpdesk-Kommunikation zu langen, einzigartigen Passphrasen vorbereiten.
  • [ ] MFA, privilegierte Adminpfade und Credential-Schutz als unabhängige Kontrollen verifizieren.
  • [ ] Jede Ausnahme mit Owner, Begründung, Scope, Kompensationskontrollen und Ablaufdatum führen.
  • [ ] Policy, PSO-Zuweisungen, DC-Abdeckung und Sperrlisten regelmäßig erneut prüfen.