Fine-grained Password Policy

Benutzername und Kennwort sind in den meisten Windows Netzwerken immer noch die primäre Anmeldung und entsprechend risikobehaftet. Ein wichtiger Schutz ist ein langes Kennwort, eine Sperrung bei zu vielen Fehlversuchen und die Erkennung solche Password Attacken. Aber lange Zeit konnte ein Administrator die Richtlinien nur "pro Domäne" einstellen. Seit Windows 2008 geht das viel feiner aber die meisten Administratoren haben davon immer noch nichts gehört.

Überlegungen

Ehe sie nun die MMC starten und loslegen, sollten Sie sich überlegen, was Sie damit bezwecken wollen. Letztlich geht es um unterschiedliche Richtlinien für verschiedene Konten in ihrem Active Directory. Ich würde da zumindest mal vier Konten unterscheiden

  • Administratoren
    Diese privilegierten Konten sollten schon eine ausreichende Mindestlänge und Komplexität haben
  • Dienstkonten
    Ein "Dienstkonto" vertippt sich eigentlich nicht. Sie sollten hier die Lockout-Policies aber so anpassen, dass das Konto schnell wieder entsperrt wird und die Eventlogs überwachen. Vor allem kann das Kennwort richtig lang gefordert sein
  • Prokuristen u.a.
    "Sensible Benutzer", die z.B. Überweisungen vornehmen können, Konstrukteure, Softwareentwickler mit Rechten zum Einchecken und Signieren von Code etc. sollten auch besonders geschützt werden
  • Normale Benutzer
    Vermutlich werden Sie nicht jedem normalen Benutzer ein 15-stellige komplexes Kennwort vorschreiben wollen.

Sie können gerne noch weitere Klassifizierungen vornehmen, denn sie können mehrere Richtlinien anlegen, die in einer Priorität abgearbeitet werden. Die Richtlinien werden dabei auf Gruppe oder direkt auf Benutzer gebunden. Für die Umsetzung gibt es nun zwei Optionen:

  • Default Streng
    Sie können die Domain Policy auf den höchsten Level zu setzen und dann die Konten, die "weniger streng" gesichert werden sollen. Konten, die so nicht explizit eine abweichende Richtlinie haben, unterliegen den strengsten Einstellungen
  • Explizit weniger gesichert
    Umgekehrt könnten Sie die Domain Policy so einstellen, dass sie auf die normalen Benutzer wirkt und abweichende strengere Richtlinien werden auf die Konten oder Gruppen von Konten zugewiesen, die strenger gehandhabt werden.

Mein Favorit ist natürlich "Default Streng". Die Einstellmöglichkeiten und Optionen hingegen wurden nicht nicht verändert. Am besten legen Sie eine Kennwort Richtlinie über das Windows Active Directory Administrative  Center an, indem Sie in die OU "/System/Password Settings Container" gehen. Mit "Neu" kommen Sie dann in diesen Dialog:

Dies sind hier meine "Defaults" bei einem Windows 2016 Server.

Wichtige Fakten

Ich habe einige Tests auf Windows 2016 DCs durchgeführt, um zu verstehen, wie die Richtlinien genau funktionieren.

  • Objekt "msDS-PasswordSettings" in der OU CN=Password Settings Container,CN=System,DC=<domain>,DC=<tld>
    Jede Kennwort-Richtlinie wird in dieser OU abgelegt. Sie können mehrere Richtlinien anlegen.
  • Zuweisung nur an "Security-Global"-Groups und Benutzer
    Die Richtlinie kann z.B. nicht an "Administratoren" zugewiesen werden, die eine "Domain - Lokale"-Gruppe ist. Ebensowenig können "Universal Groups". Das klingt aber logisch, dass eine Richtlinie nur an Objekte mit einem Scope auf der Domäne zugewiesen werden kann. Stellen Sie sich mal vor, ein Administrator einer Domäne im Forest legt eine Richtline an könnte diese an eine Gruppe einer anderen Domäne im gleichen Forest zuweisen
  • Rekursion in Gruppen
    Es ist durchaus möglich, dass ein Benutzer in einer Gruppe1 ist, die ihrerseits in Gruppe2 Mitglied ist und die Kennwort-Richtlinie auf Gruppe2 wirkt. Dann wirkt sie auch auf den Benutzer in der Gruppe1.
  • Priorität und Zuweisung
    Es kann durchaus passieren, dass ein Benutzer mehreren Richtlinien unterworfen ist. In dem Fall kommt dann die Preference zum Tragen. Die Richtlinie mit der kleinsten Preference wird angewendet. Wenn tatsächlich mehrere Richtlinien die gleiche Preference haben, dann wird der Eintrag mit der niedrigsten ObjectGUID genutzt. Ich würde raten, die Preference eindeutig zu halten.
  • Zuweisung per DistinguishedName
    Auf welche Gruppe oder welches Konto die Richtlinie zugewiesen wird, wird bei der Richtlinie selbst im Feld "msDS-PSOAppliesTo" hinterlegt. Dies ist ein "Array of DN", d.h. mehrere Einträge sind möglich aber es ist ein Verweis auf den DistinguishedName. Es ist als unkritisch die Zielobjekte innerhalb der Domain zu verschieben oder sie umzubenennen.
  • Geschwindigkeit
    Bei meiner "Single Server" Test-Umgebung wurden Änderungen quasi "sofort" aktiv. Wenn Sie mehrere DCs haben, dann müssen Sie zumindest die Replikation der AD-Änderungen abwarten.

Office 365/Microsoft 365

Die meisten Firmen nutzen mittlerweile auch Dienste in der Cloud. In Verbindung mit ADSync und ADFS ist natürlich interessant, wie die erweiterten lokalen Kennwortrichtlinien in der Cloud wirken.

Konten Beschreibung

Cloud Only-Konten

Konten, die es nur im AzureAD gibt, sind von den lokalen Richtlinien nicht verwaltet. Sie müssen hier im AzureAD entsprechende Einstellungen vornehmen.

AzureAD Domain Services

Eine weitere Stufe ist der Betrieb von Domains in AzureAD. Das ist aktuell wohl eher ein noch geringer Anteil

ADSync mit PHS

 Mit Password Hash Sync (PHS) nutzen die Anwender in der Cloud die gleichen Kennworte wie On-Premises. Das AzureAD vergleich einfach den Hashwert. Sie Benutzer ändern ihr Kennwort normalerweise nur im lokalen Active Directory. Damit greifen die lokalen Richtlinien.

ADSync mit PTA

 Mit Pass-Through Authentifizierung (PTA) nutzen die Anwender in der Cloud ebenfalls die gleichen Kennworte wie On-Premises. Allerdings übernimmt die Überprüfung der lokale DomainController über den PTA-Agenten. Die Anwender ändern ihr Kennwort normalerweise nur im lokalen Active Directory.

ADSync mit ADFS

 Hier erfolgt gleich die komplette Authentifizierung über den lokalen ADFS-Server in ihrem Active Directory. Wenn Benutzer ihr Kennwort ändern wollen, dann gelten auch hier die lokalen Richtlinien.

Ein Sonderfall ist die Funktion "Kennwort zurückschreiben". Mit der passenden Lizenz und Konfiguration können Sie Anwendern gestatten, ihr Kennwort auch im AzureAD über das Portal in der Cloud zu setzen. ADSync übernimmt dann die Aufgabe das Kennwort auf dem lokalen Active Directory gleich zu setzen. Allerdings weiß das AzureAD nichts von den besonderen lokalen Kennwortrichtlinien. Sie sollten daher im AzureAD einen vergleichbaren oder höheren Level einstellen, damit Anwender ohr Kennwort nicht auf einen zu schwachen Text setzen können. Dennoch hilft das nicht immer und Microsoft schreibt selbst dazu

Password policies in the On-Premises AD DS environment may prevent password resets from being correctly processed. For password writeback to work most efficiently, the group policy for Minimum password age must be set to 0. This setting can be found under Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies within gpedit.msc.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/authentication/tutorial-enable-sspr-writeback#configure-account-permissions-for-azure-ad-connect

Das "Minimum Age" auf 0 zu setzen ist sicher möglich aber ich habe keine Hinweise gefunden, dass .

LDIFDE-Auszug

Ich habe eine Kennwort-Richtlinie per LDIFDE exportiert.

dn: CN=PWPol1,CN=Password Settings Container,CN=System,DC=msxfaq,DC=de
changetype: add
objectClass: top
objectClass: msDS-PasswordSettings
cn: PWPol1
distinguishedName: 
 CN=PWPol1,CN=Password Settings Container,CN=System,DC=msxfaq,DC=de
instanceType: 4
whenCreated: 20210107183358.0Z
whenChanged: 20210107184947.0Z
uSNCreated: 1683909
uSNChanged: 1683970
name: PWPol1
objectGUID:: iRCeQDc+AE2LnCMpVNfnDA==
objectCategory: 
 CN=ms-DS-Password-Settings,CN=Schema,CN=Configuration,DC=msxfaq,DC=de
dSCorePropagationData: 20210107183358.0Z
dSCorePropagationData: 20210107183358.0Z
dSCorePropagationData: 16010101000000.0Z
msDS-MaximumPasswordAge: -9223372036854775808
msDS-MinimumPasswordAge: 0
msDS-MinimumPasswordLength: 15
msDS-PasswordHistoryLength: 0
msDS-PasswordComplexityEnabled: FALSE
msDS-PasswordReversibleEncryptionEnabled: FALSE
msDS-LockoutObservationWindow: -18000000000
msDS-LockoutDuration: -18000000000
msDS-LockoutThreshold: 0
msDS-PSOAppliesTo: CN=AdminB,OU=AdminPasswordtest,DC=msxfaq,DC=de
msDS-PSOAppliesTo: CN=Domain Guests,CN=Users,DC=msxfaq,DC=de
msDS-PasswordSettingsPrecedence: 1

Sie können gut sehen, dass auch die Einstellungen selbst alle als eigene Fehler "lesbar" hinterlegt sind. Ehe es die "Active Directory Administrative Center" gegeben hat, durften Sie diese Einstellungen noch per ADSIEDIT oder PowerShell pflegen/p>

Eine Pflege per ADSIEDIT oder PowerShell ist auch weiterhin möglich. Der normale Administrator sollte aber die MMC nutzen

PowerShell

Wer es dennoch tun möchte. Hier sind die Befehle

Interessant ist insbesondere der letzte Befehl, mit dem Sie die aktuell gültige Richtlinie für den Benutzer auswerten können.

PS C:\> Get-ADUserResultantPasswordPolicy adminb

AppliesTo                   : {CN=AdminB,OU=AdminPasswordtest,DC=msxfaq,DC=de, CN=Domain
                              Guests,CN=Users,DC=msxfaq,DC=de}
ComplexityEnabled           : False
DistinguishedName           : CN=PWPol1,CN=Password Settings Container,CN=System,DC=msxfaq,DC=de
LockoutDuration             : 00:30:00
LockoutObservationWindow    : 00:30:00
LockoutThreshold            : 0
MaxPasswordAge              : 00:00:00
MinPasswordAge              : 00:00:00
MinPasswordLength           : 15
Name                        : PWPol1
ObjectClass                 : msDS-PasswordSettings
ObjectGUID                  : 409e1089-3e37-4d00-8b9c-232954d7e70c
PasswordHistoryCount        : 0
Precedence                  : 1
ReversibleEncryptionEnabled : False

Wenn keine erweiterte Richtline anliegt, wird nichts angezeigt. Dieses Commandlet zeigt ihnen nicht die Einstellungen zu Kennworten aus der Gruppenrichtlinie an.

Weitere Links