Windows Server 2025 / Kennwort- und Kontosperrrichtlinien mit FGPP einrichten

Für unterschiedliche Kennwort- und Kontosperrvorgaben für bestimmte Domänenbenutzer verwenden Sie differenzierte Kennwortrichtlinien (FGPP, Fine-Grained Password Policies) und prüfen die resultierende Richtlinie des Benutzers. Ein gewöhnliches Gruppenrichtlinienobjekt (GPO) an einer Benutzer-Organisationseinheit (OU) erzeugt keine separate Domänenkennwortrichtlinie für diese OU. Diese Übung belässt die Standardrichtlinie unverändert und weist ein Kennworteinstellungsobjekt (PSO, Password Settings Object) einer ausschließlich für das Labor vorgesehenen Gruppe zu.

Domänenstandard und differenzierte Richtlinien unterscheiden

FGPP gelten für Benutzerobjekte und globale Sicherheitsgruppen; eine OU ist kein direktes Zuweisungsziel. Die offizielle FGPP-Anleitung beschreibt Domänen- und Werkzeugvoraussetzungen. Verwenden Sie DC1 oder einen Verwaltungsrechner mit dem Modul ActiveDirectory, Verbindung zu ad.example.test und einem berechtigten Konto. Standardmäßig benötigen Sie Domänenadministratorenrechte; die Verwaltung kann auch passend delegiert werden. Lokale Administratorrechte auf dem PC erlauben nicht automatisch das Erstellen von PSOs. Beginnen Sie im richtigen Domänenkontext mit diesen lesenden Abfragen:

Get-ADDefaultDomainPasswordPolicy
Get-ADUserResultantPasswordPolicy -Identity 'labuser1'
Get-ADFineGrainedPasswordPolicy -Filter *

Die erste Abfrage liest die Standardkennwortrichtlinie der Domäne im Sitzungskontext; bestätigen Sie ad.example.test. Die zweite zeigt das resultierende PSO von labuser1, die dritte vorhandene PSOs. Halten Sie Ausgangswerte und Zuweisungen ohne Kennwörter fest. Es werden nicht die jeweils strengsten Einzelwerte aller PSOs kombiniert, sondern ein resultierendes PSO bestimmt. Direkte Benutzerzuweisungen gehen Gruppenzuweisungen vor; unter vergleichbaren Kandidaten hat die kleinere Precedence-Zahl Vorrang. Die Zahl 100 garantiert deshalb keinen Vorrang dieses Beispiels. Bei vorhandenen Richtlinien oder Namens- beziehungsweise Prioritätskonflikten halten Sie vor der Erstellung an und prüfen zuerst das Resultat.

Laborgruppe und Beispielwerte vorbereiten

Verwenden Sie GG_LabUsers und den normalen Benutzer labuser1 aus der Übung zu Active Directory-Benutzern und -Gruppen. Prüfen Sie in Active Directory-Benutzer und -Computer (dsa.msc), dass GG_LabUsers eine globale Sicherheitsgruppe ist, und kontrollieren Sie sämtliche Mitglieder einschließlich möglicher verschachtelter Gruppen. Erfasst werden dürfen nur dafür vorgesehene Laborkonten. Weisen Sie das PSO nicht zu, wenn dadurch Administratoren, Dienste oder echte Benutzer betroffen wären. Entfernen Sie keine Mitglieder einer produktiven Gruppe, um diese für die Übung passend zu machen. Die folgenden Werte dienen dem Lernen und sind keine allgemeine Sicherheitsempfehlung:

Das Mindestalter von 0 Tagen erleichtert Kennwortänderungen während der Übung und ist kein Produktionsentwurf. Auch 30 Tage Höchstalter und 5 Fehlversuche sind Demonstrationswerte. Im Betrieb sind Erkennung, Mehrfaktorauthentifizierung (MFA), Kontotyp und Wiederherstellung gemeinsam zu betrachten. Sehr niedrige Sperrschwellen können häufige Sperrungen oder einen Angriff zur Dienstverweigerung begünstigen. Länge, Komplexität und Ablauf allein beschreiben nicht den gesamten Kontoschutz.

PSO erstellen und der Gruppe zuweisen

Öffnen Sie Windows PowerShell mit Administratorrechten und der erforderlichen Active Directory-Autorisierung. Fahren Sie nur fort, wenn Lab-Password-Policy nicht vorhanden ist und die bestehenden Prioritäten geprüft wurden. Der Block legt die Beispielwerte fest, erstellt das PSO, weist es mit Add-ADFineGrainedPasswordPolicySubject zu und fragt das Ergebnis für labuser1 ab. Prüfen Sie die Parameter von New-ADFineGrainedPasswordPolicy und führen Sie die Anweisungen schrittweise aus: Schlägt die Erstellung fehl, darf die Zuweisung nicht ungeprüft an ein altes Objekt gleichen Namens anschließen.

$policyParameters = @{
    Name = 'Lab-Password-Policy'
    Precedence = 100
    MinPasswordLength = 14
    ComplexityEnabled = $true
    PasswordHistoryCount = 5
    MinPasswordAge = (New-TimeSpan -Days 0)
    MaxPasswordAge = (New-TimeSpan -Days 30)
    LockoutThreshold = 5
    LockoutDuration = (New-TimeSpan -Minutes 15)
    LockoutObservationWindow = (New-TimeSpan -Minutes 15)
    ReversibleEncryptionEnabled = $false
}
New-ADFineGrainedPasswordPolicy @policyParameters
Add-ADFineGrainedPasswordPolicySubject -Identity 'Lab-Password-Policy' -Subjects 'GG_LabUsers'
Get-ADUserResultantPasswordPolicy -Identity 'labuser1'

Nach der Zuweisung wird für labuser1 das PSO Lab-Password-Policy mit Precedence 100 und den Tabellenwerten erwartet. Kontrollieren Sie insbesondere Länge 14, Verlauf 5, Alter 0/30 Tage, Schwelle 5 und beide Zeitintervalle von 15 Minuten. Das erstellte Objekt oder GG_LabUsers in dessen Zielen beweist noch nicht, dass genau dieses PSO für den Benutzer wirksam ist. Prüfen Sie bei Abweichungen tatsächliche Mitgliedschaft, weitere Zuweisungen und Replikation; wiederholen Sie nicht einfach die Erstellung.

Alternativ öffnen Sie das Active Directory-Verwaltungscenter (ADAC) mit dsac.exe. Wählen Sie die richtige Domäne → System → Container für Kennworteinstellungen (Password Settings Container). Unter Aufgaben wählen Sie Neu → Kennworteinstellungen. Tragen Sie Lab-Password-Policy, Rangfolge 100 und die Tabellenwerte ein. Unter Direkt anwendbar auf (Directly Applies To) fügen Sie GG_LabUsers hinzu und bestätigen. Wählen Sie danach labuser1 und Resultierende Kennworteinstellungen anzeigen. Dies ersetzt den Erstellungsblock; legen Sie das PSO nicht mit beiden Verfahren doppelt an.

Kennwort ändern und das Ergebnis prüfen

Eine Richtlinienänderung verlängert oder ersetzt ein gespeichertes Kennwort nicht rückwirkend. Sie kann aber die geltenden Bedingungen einschließlich des Ablaufs abhängig vom aktuellen Kennwortalter verändern. Die Zuweisung beweist also nicht, dass ein altes Kennwort die neue Länge erfüllt. Prüfen Sie zuerst das resultierende PSO und melden Sie sich auf CLIENT1 als Domänenbenutzer labuser1 an. Öffnen Sie Strg+Alt+Entf → Kennwort ändern; bei einer virtuellen Konsole nutzen Sie deren Funktion zum Senden dieser Tastenkombination an das Gastsystem. Geben Sie das aktuelle und ein neues, eindeutiges Kennwort ein, das die Anforderungen erfüllt, und bestätigen Sie es im vorgesehenen Feld. Kopieren Sie kein veröffentlichtes Beispielkennwort und schreiben Sie es nicht in Skripte, Protokolle oder Screenshots. Prüfen Sie erfolgreiche Änderung und spätere Anmeldung ohne absichtlich wiederholte Fehlversuche.

Demonstrieren Sie Sperrungen nicht durch wiederholte falsche Kennwörter eines Administrators oder Dienstkontos. Die Schwelle zählt Authentifizierungsfehler; Wiederholungsversuche von Protokollen und Anwendungen verhindern die Annahme, jede Benutzeraktion entspreche genau einem gezählten Fehler. Wird labuser1 unerwartet gesperrt, untersuchen Sie alte Anmeldedaten in geplanten Aufgaben, Diensten und gespeicherten Verbindungen, bevor Sie weitere Anmeldeversuche unternehmen. Fragen Sie den Zustand aus der Verwaltungssitzung ab:

Get-ADUser -Identity 'labuser1' -Properties LockedOut,PasswordLastSet | Select-Object SamAccountName,LockedOut,PasswordLastSet

LockedOut zeigt den vom abgefragten Controller beobachteten Sperrzustand, nicht den verursachenden Prozess. PasswordLastSet nennt den Zeitpunkt des letzten Setzens, weder das Kennwort noch einen Nachweis der Einhaltung aller aktuellen Regeln. Nach erfolgreicher Änderung sollte der neue Zeitpunkt erscheinen, sobald die betreffende Information verfügbar ist. Beim Vergleich verschiedener Controller berücksichtigen Sie Replikation und Abfragezeit, ohne Kennwörter zu protokollieren.

Eine Entsperrung beseitigt nicht die Anwendung oder das Gerät, das weiterhin ein altes Kennwort sendet. Prüfen Sie Benutzer und Ursache, korrigieren Sie die betreffenden gespeicherten Anmeldedaten und kontrollieren Sie den Zustand erneut. Eine notwendige Entsperrung muss gezielt und autorisiert erfolgen. Lockern Sie nicht die Richtlinie und entsperren Sie nicht pauschal alle Benutzer, um das Symptom zu beseitigen.

Zuweisung entfernen und wirksame Richtlinie nachweisen

Entfernen Sie zum Abschluss nur die Zuweisung von GG_LabUsers mit Remove-ADFineGrainedPasswordPolicySubject. Lesen Sie eine mögliche Bestätigung, bevor Sie sie annehmen: Entfernt wird die Gruppe als PSO-Ziel, nicht das Gruppenobjekt oder labuser1. Fragen Sie anschließend resultierendes PSO und Domänenstandard erneut ab:

Remove-ADFineGrainedPasswordPolicySubject -Identity 'Lab-Password-Policy' -Subjects 'GG_LabUsers'
Get-ADUserResultantPasswordPolicy -Identity 'labuser1'
Get-ADDefaultDomainPasswordPolicy

Gilt kein anderes PSO, greift die Domänenstandardrichtlinie, und die Abfrage des resultierenden PSO kann ohne Objekt bleiben. Unterscheiden Sie diesen erwarteten Zustand von Fehlern bei Berechtigungen, Namen oder Verbindung. Erscheint ein anderes PSO, untersuchen Sie es, statt es für ein gewünschtes Ergebnis zu löschen. Vergleichen Sie den Domänenstandard mit dem Ausgangsprotokoll: Diese Übung verändert ihn nicht. Das Entfernen der Zuweisung stellt kein altes Kennwort wieder her; bewahren Sie das gültige neue Kennwort sicher auf. Prüfen Sie vor dem Löschen des PSO andere Zuweisungen oder behalten Sie es unzugewiesen für eine spätere Wiederverwendung. Löschen Sie bei dieser Bereinigung keine Konten oder Gruppen.