AD-Kennwortrichtlinien: PSO für Admin-Konten richtig setzen

Differenzierte Kennwortrichtlinien: PSO richtig aufsetzen

In den meisten Domänen gilt genau eine Kennwortrichtlinie – die der Default Domain Policy. Für privilegierte Konten ist das zu wenig: Wer Domänen-Administrator ist, sollte ein längeres Kennwort und eine kürzere Sperrzeit haben als der Durchschnittsnutzer. Genau dafür gibt es Password Settings Objects (PSO), auch feingranulare oder differenzierte Kennwortrichtlinien genannt.

Was PSOs leisten – und was nicht

Ein PSO bündelt Kennwort- und Kontosperrungsregeln und wird direkt Benutzern oder globalen Sicherheitsgruppen zugewiesen. Eine Verknüpfung an Organisationseinheiten gibt es nicht, und Computerkonten lassen sich damit nicht steuern. Wer lokale Administratorkennwörter verwalten will, braucht weiterhin Windows LAPS.

Voraussetzung ist die Domänenfunktionsebene Windows Server 2012 oder höher sowie Mitgliedschaft in „Domänen-Admins“. Greift kein PSO, gilt automatisch die Kennwortrichtlinie der Domäne. Kennwortregeln wirken erst bei der nächsten Kennwortänderung, Sperrzeit und Sperrschwelle dagegen sofort.

Präzedenz: der kleinste Wert gewinnt

Jedes PSO trägt eine Rangfolge im Attribut msDS-PasswordSettingsPrecedence. Ist ein Benutzer Mitglied mehrerer Gruppen mit PSO, gewinnt der niedrigste Wert. Bei identischer Präzedenz entscheidet die kleiner als GUID sortierte Objekt-ID – ein Ergebnis, das niemand vorhersagen will. Deshalb besser in Zehnerschritten planen: 10 für Administrative Tier 0, 20 für Server-Administratoren, 30 für Helpdesk.

Schritt 1: Zielgruppe als globale Sicherheitsgruppe

Die Gruppe sollte nur die Konten enthalten, die wirklich strengere Regeln brauchen. Eine eigene Gruppe ist auch deshalb sinnvoll, weil „Domänen-Benutzer“ als primäre Gruppe eines Kontos bei der PSO-Auswertung nicht berücksichtigt wird.

New-ADGroup -Name 'PSO-Admin-Konten' -GroupScope Global -GroupCategory Security `
  -Path 'OU=Gruppen,DC=contoso,DC=local' -Description 'PSO-Zielgruppe Tier 0'

Schritt 2: PSO anlegen

Das folgende Beispiel setzt 20 Zeichen Mindestlänge, 24 Kennwörter Historie und eine Sperre nach fünf Fehlversuchen für 15 Minuten. Die Präzedenz 10 stellt sicher, dass diese Richtlinie alle anderen PSOs der betroffenen Konten schlägt.

$pso = @{
  Name                        = 'PSO-Admin-Tier0'
  Precedence                  = 10
  MinPasswordLength           = 20
  PasswordHistoryCount        = 24
  ComplexityEnabled           = $true
  MaxPasswordAge              = '365.00:00:00'
  MinPasswordAge              = '1.00:00:00'
  LockoutThreshold            = 5
  LockoutDuration             = '00:15:00'
  LockoutObservationWindow    = '00:15:00'
  ReversibleEncryptionEnabled = $false
}
New-ADFineGrainedPasswordPolicy @pso

Schritt 3: PSO zuweisen

Die Zuweisung erfolgt nicht über die Gruppenmitgliedschaft allein, sondern über ein eigenes Cmdlet. Nur so landet die Gruppe im Attribut msDS-PSOAppliesTo des PSO.

Add-ADFineGrainedPasswordPolicySubject -Identity 'PSO-Admin-Tier0' `
  -Subjects 'PSO-Admin-Konten'

Ergebnis prüfen

Statt zu raten, fragt man das resultierende PSO direkt ab – das geht auch als normaler Benutzer, weil authentifizierte Konten das Attribut lesen dürfen. Im Active Directory-Verwaltungscenter liegt die gleiche Funktion unter „Resultierende Kennworteinstellungen anzeigen“.

Get-ADUserResultantPasswordPolicy -Identity mmustermann |
  Select-Object Name, Precedence, MinPasswordLength, LockoutThreshold

Kommt keine Ausgabe zurück, greift kein PSO. Das ist nach dem Anlegen normal, solange das Konto noch kein neues Kennwort gesetzt hat – die Zuweisung selbst ist aber sofort sichtbar.

Typische Fehler beim Rollout

Erstens: PSO an eine OU hängen wollen – das geht in AD DS nicht, nur Benutzer und globale Gruppen sind zulässig. Zweitens: PSO auf „Domänen-Benutzer“ legen; als primäre Gruppe wird sie nicht ausgewertet, die Richtlinie läuft ins Leere. Drittens: gleiche Präzedenzwerte vergeben und sich auf die GUID-Reihenfolge verlassen.

Viertens: Dienstkonten mit Ausnahmen von der Ablaufregel versehen, statt group Managed Service Accounts (gMSA) zu nutzen. Fünftens: nach dem Anlegen nicht prüfen, ob alle Domänencontroller das Objekt repliziert haben – das PSO liegt im System-Container unter „Password Settings“, nicht in SYSVOL. Ein Get-ADFineGrainedPasswordPolicy -Server dc02 schafft Klarheit.

Quellen

• Microsoft Learn: Differenzierte Kennwortrichtlinien für AD DS konfigurieren (Stand 15.08.2025)
• Microsoft Learn: New-ADFineGrainedPasswordPolicy (PowerShell-Referenz, Windows Server 2025)
• Microsoft Learn: Get-ADUserResultantPasswordPolicy

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.