Bis einschließlich Windows Server 2003 kann mit Bordmittel nur eine Kennwort- und Kontosperrungsrichtlinie innerhalb einer Domäne auf Domänenbenutzer wirken. Damit die Richtlinien auf Domänenbenutzer wirken, müssen diese zwingend auf Domänenebene verlinkt werden. Wenn stattdessen die beiden Richtlinien auf eine Organisationseinheit (OU) verlinkt werden, wirkt sich das lediglich auf die Computer die sich in dieser OU befinden aus und die Kennwortvorgaben gelten somit nur für die lokalen Benutzerkonten, die sich auf diesen Computern befinden!
Möchte man bis Windows Server 2003 mit Bordmittel mehrere Kennwortrichtlinien nutzen, muss man weitere Domänen erstellen, was natürlich den Ressourceneinsatz sowie den Verwaltungsaufwand wesentlich erhöht. Man kann sich aber auch zusätzliche Kennwortfilter erstellen oder weicht auf Dritt-Anbieter Lösungen aus.
Die Kennwort- und Kontosperrungsrichtlinie sollten in allen Serverversionen stets in der Default Domain Policy (DDP) konfiguriert werden, nicht zuletzt, da die DDP standardmäßig ohnehin schon auf der Domänenebene verlinkt ist. Ein weiterer viel wichtiger Punkt ist, das man in den Eigenschaften der Domänenpartition die Attribute die für beide Richtlinien relevant sind (maxPwdAge, minPwdAge, minPwdLength, pwdHistoryLength, pwdProperties, lockoutDuration, lockOutObservationWindow, lockouThreshold etc.) auf dem PDC-Emulator auch direkt konfigurieren kann. Die Konfiguration der Kennwortvorgaben muss nicht zwingend in der DDP vorgenommen werden. Durch einen automatisierten Prozess werden dann die Änderungen die man in den Attributen vorgenommen hat vom PDC-Emulator in die beiden Richtlinien, aber nur in die DDP übertragen!
Es gilt zu beachten, dass die Kennwortoptionen unter den Computerkonfigurationen in der Gruppenrichtlinie und nicht wie man annehmen könnte, unter den Benutzerkonfigurationen konfiguriert wird! Die Benutzerobjekte können mit den Kennworteinstellungen nichts anfangen. Die Kennwortoptionen werden nur von Computerobjekten verwertet und befinden sich unter:
Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kennwortrichtlinien
und
Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kontosperrungsrichtlinien
Die fein abgestimmten Kennwortrichtlinien
Seit Windows Server 2008 ist es mit Bordmittel nun endlich möglich, mehrere Kennwort- und Kontosperrungsrichtlinien für verschiedene Benutzergruppen innerhalb einer einzigen Domäne zu erstellen. Genau genommen sind es keine weiteren Richtlinien, sondern Active Directory (AD) Objekte. Die AD Objekte nennen sich Kennworteinstellungsobjekte und lauten im Fachjargon Password Setting Objects, kurz PSO.
Mit dieser Funktion die auch als granulare Kennwort- und Kontosperrungsrichtlinien oder als fein abgestimmte/abgestufte Kennwortrichtlinien (auf Englisch: Fine-Grained Password Policy, FGPP) bezeichnet wird, können getrennte Kennwort- und Kontosperreinstellungen für bestimmte Benutzer in der Domäne eingerichtet werden. Standardmäßig können die Mitglieder der Gruppe Domänen-Admins verschiedene Kennwortbeschränkungen und Kontosperreinstellungen für verschiedene Benutzertypen in der Domäne einrichten. Das Erstellen und administrieren von PSOs kann aber auch an eine entsprechende Gruppe delegiert werden.
Durch die beiden neuen Objektklassen Password Settings Container (PSC) und Password Settings die dem AD-Schema ab Windows Server 2008 hinzugefügt wurden, ist das Erstellen und Speichern von PSOs möglich. Der PSC in dem die PSOs für die Domäne gespeichert werden wird standardmäßig im Container System erstellt, dass sich in jeder Domänenpartition befindet. Der LDAP-Pfad zum PSC lautet CN=Password Settings Container,CN=System,DC=Domäne,DC=de.
Aktiviert man in der MMC Active Directory-Benutzer und -Computer unter Ansicht die „Erweiterten Features“, kommt der System Container in dem sich der PSC befindet zum Vorschein. Das systemflags Attribut in den Eigenschaften des PSCs verhindert, dass der Container weder verschoben, noch umbenannt oder gar gelöscht werden kann.
Die Voraussetzungen
- Der Domänenfunktionsmodus muss sich mindestens auf der Ebene Windows Server 2008 befinden! Der Gesamtstrukturfunktionsmodus wiederum kann sich z.B. auf der Ebene Windows Server 2003 befinden. Somit dürften sich in der Gesamtstruktur noch Domänen mit Windows Server 2003 DCs befinden, die dann aber keine PSOs einsetzen können!
- PSOs können nur auf Benutzerobjekte, globale Sicherheitsgruppen und auf inetOrgPerson-Objekte angewendet werden. Die Gruppenbereiche „Lokal (in Domäne)“ und „Universal“ sowie der Gruppentyp „Verteiler“ werden nicht berücksichtigt! Es ist empfehlenswert PSOs lediglich auf globale Gruppen zu verlinken. Dadurch müssen die Benutzer die eine andere Kennwortvorgabe erhalten sollen, nur noch zur entsprechenden Gruppe hinzugefügt werden.
- Auf eine OU können PSOs nicht direkt angewendet werden! Stattdessen kann man eine Schattengruppe (shadow group) verwenden, die der OU logisch zugeordnet ist. Eine Schattengruppe ist nichts anderes als eine globale Sicherheitsgruppe. Alle Benutzer einer OU werden dann zu dieser Schattengruppe hinzugefügt und die PSO wird dieser Schattengruppe zugewiesen. Wird ein Benutzer aus einer OU in eine andere verschoben, muss die Mitgliedschaft der Schattengruppe angepasst werden, falls der Benutzer die PSO der neuen OU zugewiesen bekommen soll.
- Auf einen Benutzer kann immer nur ein einziges PSO wirken!
- PSOs können nur im PSC erstellt werden!
- Das ein und dasselbe PSO kann auf mehrere Benutzer und/oder Gruppen angewandt werden, die sich in der gleichen Domäne befinden wie das PSO.
- Es gibt kein eigenes Bordmittel für PSOs. Ein PSO kann nicht in der MMC Active Directory-Benutzer und -Computer erstellt werden, lediglich das Anzeigen ist möglich. PSOs können mit Bordmittel mit der MMC ADSIEdit, mit dem Kommandozeilentool LDIFDE, LDP oder der AD-PowerShell erstellt und administriert werden. Zusätzlich gibt es aber im Internet kostenlose Tools, die einem das Leben mit den PSOs erleichtern.
Die Attribute eines PSO
Ein PSO in dem die Kennwortvorgaben und Kontosperreinstellungen konfiguriert werden, hat Attribute für alle Kennwortoptionen, die ebenfalls in der DDP festgelegt werden können (bis auf die Kerberos-Einstellungen).
In einem PSO existieren die Attribute für die folgenden Kennwort- und Kontosperreinstellungen:
- Vorrang: Das Attribut msDS-PasswordSettingsPrecedence dient zum Lösen von Konflikten, wenn auf ein Benutzer- oder Gruppenobjekt mehrere PSOs verlinkt sind. Dieses Attribut entscheidet letztendlich darüber welches PSO angewendet wird, falls mehrere PSOs auf ein Benutzer- oder Gruppenobjekt verlinkt sind. Das PSO, das den niedrigsten Wert in diesem Attribut enthält wird angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist! Als Werte wird jeder Wert akzeptiert, der größer als 0 ist.
- Kennwörter mit umkehrbarer Verschlüsselung speichern: Diese Option wird im Attribut msDS-PasswordReversibleEncryptionEnabled konfiguriert. Als Werte können FALSE und TRUE vergeben werden. Es versteht sich von selbst, dass man der Empfehlung folgen und hier als Wert FALSE vergeben sollte. Ansonsten würden die Kennwörter im Klartext abgespeichert werden, was ein erhebliches Sicherheitsrisiko darstellt!
- Kennwortchronik erzwingen: Für diese Option ist das Attribut msDS-PasswordHistoryLength zuständig. Hiermit wird die Anzahl der zu speichernden Kennwörter festgelegt. Wird als Wert 10 konfiguriert, werden die letzten 10 Kennwörter die der Benutzer vergeben hatte gespeichert. Wenn der Benutzer aufgefordert wird ein neues Kennwort zu vergeben, darf es kein Kennwort von den letzten 10 Kennwörtern sein. Der Wert muss zwischen 0 und 1024 liegen. Wird als Wert 0 vergeben, werden keine Kennwörter gespeichert.
Kennwort muss Komplexitätsvoraussetzungen entsprechen: Hinter dieser Option steckt das Attribut msDS-PasswordComplexityEnabled. Als Werte können hier FALSE (Deaktiviert) und TRUE (Aktiviert) vergeben werden, wobei TRUE empfohlen ist. Mit dieser Option wird festgelegt, dass das Kennwort komplex sein muss.
Komplex bedeutet:
1. Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.
- Großbuchstaben (A bis Z)
2. Das Kennwort muss mindestens sechs Zeichen lang sein.
3. Das Kennwort muss Zeichen aus drei der folgenden Kategorien enthalten:
- Kleinbuchstaben (a bis z)
- Zahlen zur Basis 10 (0 bis 9)
- Nicht alphabetische Zeichen (zum Beispiel !, $, #, %)
- Minimale Kennwortlänge: Die minimale Kennwortlänge wird im Attribut msDS-MinimumPasswordLength konfiguriert. In diesem Attribut muss angegeben werden, aus wie vielen Zeichen das Kennwort mindestens bestehen muss. Als Wert kann 0 bis 255 vergeben werden, wobei mit 0 der Benutzer selbst die Länge seines Kennworts bestimmen kann.
- Minimales Kennwortalter: Das minimale Kennwortalter im PSO konfiguriert man im Attribut msDS-MinimumPasswordAge. Dieses Attribut gibt vor, wie alt ein Kennwort mindestens sein muss ehe es geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Soll der Benutzer erst nach fünf Tagen sein Kennwort ändern dürfen, so muss als Wert 5:00:00:00 eingetragen werden. Man kann aber auch als Wert mit Klammern (Nie) oder 0 eingeben, um kein Mindestalter zu definieren. Dadurch kann der Benutzer noch am selben Tag sein Kennwort erneut ändern. Der Wert von msDS-MinimumPasswordAge muss „kleiner als“ oder „gleich“ dem Wert von msDS-MaximumPasswordAge sein.
- Maximales Kennwortalter: Das Attribut das hinter dieser Option steckt lautet msDS-MaximumPasswordAge. Mit dieser Option wird angegeben, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss. Dieser Wert muss „gleich“ oder „größer“ als der Wert im Attribut msDS-MinimumPasswordAge sein. Die Zeitangabe muss in diesem Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) eingegeben werden. Vergibt man als Wert mit Klammern (Nie), läuft das Kennwort des Benutzers nicht ab. Als Wert kann nicht 0 konfiguriert werden.
Des Weiteren existieren im PSO Attribute, mit denen man die folgenden Kontosperreinstellungen konfigurieren kann:
- Kontensperrungsschwelle: Die Anzahl maximal möglicher Fehlversuche bei der Benutzeranmeldung bestimmt das Attribut msDS-LockoutThreshold. Als Wert kann man 0 bis 65535 eintragen, wobei 0 diese Option deaktiviert. Dann erfolgt niemals eine Kontosperrung. Das ist allerdings aus Sicherheitsgründen, z.B. wegen Brute Force Attacken nicht zu empfehlen!
- Zurücksetzungsdauer des Kontosperrungszählers: Wie lange die fehlgeschlagenen Anmeldeversuche zwischengespeichert werden, bevor der Kontosperrungszähler auf 0 zurückgesetzt wird, bestimmt das Attribut msDS-LockoutObservationWindow. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man als Wert 30 Minuten eintragen, so gilt es die Zeit wie folgt einzugeben 00:00:30:00. Der Wert von msDS-LockoutObservationWindow darf nicht „größer“ als der Wert von msDS-LockoutDuration sein, höchstens „gleich“! Denn es ist nicht möglich, den Kontosperrungszähler länger aktiv zu halten als die Zeit, die das Konto gesperrt und somit im Attribut msDS-LockoutDuration konfiguriert ist.
- Kontosperrdauer: Wie lange ein Benutzerkonto nach den Anmeldefehlversuchen (es zählt der Wert im Attribut msDS-LockoutThreshold) gesperrt werden soll, ehe es automatisch entsperrt wird, definiert man im Attribut msDS-LockoutDuration. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Wird als Wert mit Klammern (Nie) eingetragen, entsperrt sich das Benutzerkonto nicht automatisch. Stattdessen muss ein Administrator manuell das Konto entsperren. Der Wert im Attribut msDS-LockoutDuration darf nicht „kleiner“ sondern höchstens „gleich“ sein, als der Wert in msDS-LockoutObservationWindow.
Ferner existiert im PSO zusätzlich noch dieses Attribut:
PSO-Link: Im PSO-Link hinter dem das mehrwertige Attribut msDS-PSOAppliesTo steckt, konfiguriert man auf welche Objekte das PSO angewendet werden soll. Das bedeutet, ein PSO kann auf mehrere Benutzer und/oder Gruppen angewendet werden. In diesem Forward-Link muss der LDAP-Pfad bzw. der Distinguished Name (DN) des Objekts eingetragen werden, auf dem das PSO wirken soll.
Das Pendant zum Forward-Link ist das Back-Link, dass Attribut msDS-PSOApplied. In diesem Back-Link das den Benutzer und Gruppenobjekten ab Windows Server 2008 hinzugefügt wurde, ist das PSO bzw. wenn mehrere PSOs auf ein Benutzerobjekt direkt oder indirekt infrage kommen, sind die PSOs enthalten, mit dem das Objekt verknüpft ist. Welches PSO dann letztendlich auf ein Benutzerkonto angewandt wird, entscheidet der Richtlinienergebnissatz (Resultant Set of Policy, RSOP), genauer das Attribut msDS-ResultantPSO das sich ebenfalls in den Eigenschaften eines Benutzerobjekts befindet.
Back-Links werden als constructed Attributes bezeichnet was nichts anderes bedeutet, als dass diese Art von Attribut von jedem DC selbst veraltet wird und der Wert eines solchen Attributs auch nicht vom Administrator bearbeitet werden kann. Es ist ein system-only Attribut und wird auch nicht auf andere DCs repliziert. Des Weiteren wird ein Back-Link und sein Wert erst zum Zeitpunkt der Abfrage generiert.
Verknüpfte Attribute
Die konstruierten Attribute abfragen
Die PSO-Attribute mit einer Zeitangabe
Es gibt im PSO vier Attribute die als Wert eine Zeitangabe im Form von Tage:Stunden:Minuten:Sekunden verlangen.
Die vier Attribute sind:
- msDS-MaximumPasswordAge
- msDS-MinimumPasswordAge
- msDS-LockoutObservationWindow
- msDS-LockoutDuration
Erstellt man ein PSO in der AD-PowerShell oder mit ADSIEdit, muss man die Zeitangabe nach der Vorgabe tt:ss:mm:ss konfigurieren. Möchte man jedoch ein oder mehrere PSOs mit LDIFDE erstellen, so müssen die Werte in diesen Attributen im I8-Format angegeben werden! Im I8-Format wird die Zeit in Intervallen von -100 Nanosekunden (Schema: attributeSyntax = 2.5.5.16 (I8)) gespeichert. Unter Windows Server 2003 wird in der Default Domain Policy genau diese Zeiteinheit für die entsprechenden Zeit-bezogenen Attribute verwendet. Um in diesen vier Attributen die entsprechenden Werte zu konfigurieren, gilt es die Zeitangabe in Tage, Stunden oder Minuten in die Intervalle von -100 Nanosekunden zu konvertieren. Anschließend muss dem konvertierten Ergebnis noch ein negatives Vorzeichen (das Minuszeichen „-„) vorangestellt werden.
Zum umrechnen der Zeit können die folgenden Umrechnungsformel verwendet werden, um die entsprechenden I8-Werte zu erhalten:
Tage: Die Umrechnungsformel für einen Tag lautet = -24*60*60*(10^7) = -864000000000.
Demzufolge würde der Wert für fünf Tage so lauten: -4320000000000 (5*864000000000).
Stunden: Eine Stunde wird wie folgt umgerechnet: -60*60*(10^7) = -36000000000.
Der Wert für zwei Stunden lautet -72000000000 (2*36000000000).
Minuten: Die Formel für eine Minute lautet = -60*(10^7) = -600000000.
Sollen 30 Minuten ins I8-Format konvertiert werden, so lautet das Ergebnis -18000000000 (30*600000000).
Welches PSO wird angewendet und hat Vorrang, falls mehrere PSOs infrage kommen?
PSOs können sowohl Benutzerobjekten als auch globalen Sicherheitsgruppen zugewiesen werden. Der Richtlinienergebnissatz (RSOP) kann jedoch nur für das Benutzerobjekt berechnet werden. Sind mehrere PSOs mit einem Benutzer oder einer globalen Gruppe verknüpft, wird der RSOP wie folgt berechnet:
- Es wird zuerst geprüft, ob ein PSO direkt mit dem Benutzerkonto verknüpft ist. Ist das der Fall, wird dieses PSO angewendet. Sind mehrere PSOs direkt mit dem Benutzerkonto verknüpft, gewinnt das PSO, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence enthält! Existieren mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
- Wenn kein PSO direkt mit dem Benutzerobjekt verknüpft ist, werden die Mitgliedschaften in den globalen Sicherheitsgruppen des betreffenden Benutzers überprüft. Existiert darunter eine Gruppe das mit einem PSO verknüpft ist, wird das PSO auf Umwege auf das Benutzerkonto angewendet. Befindet sich der Benutzer in mehreren globalen Gruppen auf denen verschiedene PSOs verknüpft sind, wird das PSO auf das Benutzerkonto angewendet, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence hat! Wenn mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence existieren, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
- Wenn kein PSO direkt oder indirekt per globaler Sicherheitsgruppe mit einem Benutzerobjekt verknüpft ist, werden die Kennwort- und Kontosperrungsrichtlinien aus der Default Domain Policy angewandt! Deshalb sollten immer die Kennwort- und Kontosperrungsrichtlinien in der DDP konfiguriert werden, um eine Mindestanforderung an die Benutzerkennwörter zu stellen.
- Existiert ein PSO das direkt oder indirekt mit einem Benutzerobjekt verknüpft ist, hat das PSO stets vor der DDP Vorrang! Erst wenn ermittelt wurde, dass letztendlich einem Benutzerobjekt kein PSO zugewiesen wurde, greifen die Kennwortbeschränkungen aus der DDP.
- Welches PSO letzten Endes auf ein Benutzerkonto angewendet wird, entscheidet das RSOP! Denn ein weiteres neues constructed Attribut das dem Benutzerobjekt ab Windows Server 2008 hinzugefügt wurde, lautet msDS-ResultantPSO. In diesem Attribut ist der DN des PSOs gespeichert, das letztendlich nach den o.g. Regeln auf den Benutzer angewandt wird.
Mehr über constructed Attribute gibt es hier:
Die konstruierten Attribute abfragen
Es gibt jedoch drei Einstellungen die direkt im Benutzerobjekt vorgenommen werden können, um stets die Kennwortvorgaben eines PSOs auszuhebeln. Die drei Optionen lassen sich mit den Flags des userAccountControl Attributs konfigurieren und sind:
- Kennwort läuft nie ab
- Kennwort mit umkehrbarer Verschlüsselung speichern
- Kennwort nicht erforderlich
How to use the UserAccountControl flags to manipulate user account properties
Im Übrigen setzen diese drei Flags die Kennwortvorgaben die in der DDP konfiguriert sind, ebenso außer Kraft!
PSOs mit der AD-PowerShell erstellen und verwalten
Unter „Windows Server 2008“ konnten PSOs mit Bordmittel lediglich mit ADSIEdit, LDIFDE sowie LDP erstellt und administriert werden. Ab „Windows Server 2008 R2“ können PSOs mit einem weiteren Bordmittel, mit dem State of the Art Werkzeug der AD-PowerShell erstellt und verwaltet werden.
Auch unter Windows Server 2003 und Windows Server 2008 kann man die AD-PowerShell nach vorheriger Installation der AD-Management Gateway Services nutzen.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Zum Überprüfen und konfigurieren der Kennwort- und Kontosperrungsrichtlinie in der DDP gibt es ebenfalls die beiden AD-PowerShell Cmdlets Get-ADDefaultDomainPasswordPolicy und Set-ADDefaultDomainPasswordPolicy. Das Cmdlet Get-ADDefaultDomainPasswordPolicy mit dem die Kennwortoptionen direkt aus den Attributen (und nicht aus der DDP) die sich in der Domänenpartition befinden abgerufen werden, zeigt die Kennwortvorgaben die mit der DDP verteilt werden an.
Das Cmdlet Set-ADDefaultDomainPasswordPolicy ändert nicht etwa die Kennworteinstellungen in der DDP, sondern direkt die Attribute die sich in der Domänenpartition befinden. Wie die einzelnen Kennwortoptionen zum Konfigurieren in der AD-PowerShell lauten, erfährt man mit dem Befehl Get-Help <Cmdlet> -Full. Also z.B. Get-Help Set-ADDefaultDomainPasswordPolicy –Full.
Zum Administrieren der PSOs in der AD-PowerShell stellt Microsoft diese acht Cmdlets zur Verfügung:
- Add-ADFineGrainedPasswordPolicySubject
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADUserResultantPasswordPolicy
- New-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Set-ADFineGrainedPasswordPolicy
- Mit diesem Einzeiler lässt sich ein PSO wie folgt erstellen:
New-ADFineGrainedPasswordPolicy –Name “PSO für die GF” –Precedence 20 –ComplexityEnabled $true –Description “Dieses PSO gilt nur für die GF” –Displayname “GF-PSO” –LockoutDuration “0.00:15:00” –LockoutObservationWindow “0.00:15:00” –LockoutThreshold 15 -MaxPasswordAge “60.00:00:00″ -MinPasswordAge “5.00:00:00″ -MinPasswordLength 8 -PasswordHistoryCount 10 -ReversibleEncryptionEnabled $false
- Ist das PSO erstellt, muss es anschließend mit dem folgenden Befehl an einen Benutzer oder eine Gruppe wie folgt zugewiesen werden:
Add-ADFineGrainedPasswordPolicySubject <Name der PSO> <Benutzer/Gruppe>
- Einzelne Optionen lassen sich in einem bestehenden PSO folgendermaßen ändern:
Set-ADFineGrainedPasswordPolicy “CN=<Name der PSO>,CN=Password Settings Container,CN=System,DC=Domäne,DC=de” –Precedence 15 -MinPasswordLength 12
- Alle PSOs mit den konfigurierten Kennwortoptionen lassen sich mit diesem Befehl Anzeigen:
Get-ADFineGrainedPasswordPolicy -Filter { Name -Like “*” }
- Welches PSO letzten Endes auf einen Benutzer wirkt und wie die einzelnen Kennwortoptionen konfiguriert sind, erfährt man mit diesem Befehl:
Get-ADUserResultantPasswordPolicy <Benutzer>
- Mit der AD-PowerShell kann man sogar abfragen, auf welche Benutzer- und/oder Gruppenobjekte ein bestimmtes PSO verlinkt ist. Der Befehl lautet:
Get-ADFineGrainedPasswordPolicySubject <Name der PSO>
- Um die Verlinkung einer PSO von einem Benutzer oder von einer Gruppe zu entfernen, muss dieser Befehl ausgeführt werden:
Remove-ADFineGrainedPasswordPolicySubject <Name der PSO> -Subjects <Benutzer/Gruppen> -Confirm:$False
- Eine PSO kann man in der AD-PowerShell so löschen:
Remove-ADFineGrainedPasswordPolicy <Name der PSO> -Confirm:$False
Ein PSO mit ADSIEdit erstellen
Die Attribute eines PSO, müssen zwingend in dieser Reihenfolge bei der Erstellung mit ADSIEdit konfiguriert werden.
Das Erstellen eines PSOs erfolgt mit Bordmittel in ADSIEdit wie folgt:
- Zuerst verbindet man sich in ADSIEdit mit der Domänenpartition und navigiert zum Container CN=Password Settings Container,CN=System,DC=Domäne,DC=de.
- Mit einem Rechtsklick auf den PSC kann man unter Neu – Objekt… ein PSO, das zur Klasse msDS-PasswordSettings gehört erstellen.
- Mit einem Klick auf Weiter muss der Common-Name im Attribut cn angegeben werden. Der CN ist ein Name, der das PSO eindeutig identifiziert (z.B. „PSO für GF“ etc.).
- Im nächsten Schritt muss der Password Settings Precedence, der Wert für das Attribut msDS-PasswordSettingsPrecedence angegeben werden. Der Wert (der größer 0 sein muss!) der hier eingetragen wird entscheidet darüber, welches PSO auf das Objekt letztendlich angewendet wird, falls mehrere PSOs auf das Objekt verlinkt sind. Das PSO das den niedrigsten Wert in diesem Attribut enthält, wird auf das Objekt angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist.
- Dann muss für die Option Password reversible encryption status for user accounts im Attribut msDS-PasswordReversibleEncryptionEnabled entweder als Wert FALSE (was empfohlen ist!) oder TRUE eingegeben werden.
- Als nächstes muss bei der Option Password History Length for user accounts ein Wert zwischen 0 und 1024 im Attribut msDS-PasswordHistoryLength vergeben werden.
- Bei der Option Password complexity status for user accounts muss im Attribut msDS-PasswordComplexityEnabled als Wert FALSE oder TRUE vergeben werden. Wobei TRUE die empfohlene Einstellung ist.
- Danach gibt man bei der Option Minimum Password Length for user accounts im Attribut msDS-MinimumPasswordLength die Mindestlänge, die ein Kennwort zwingend haben muss an! Es kann ein Wert zwischen 0 und 255 vergeben werden.
- Nun muss im Attribut msDS-MinimumPasswordAge für die Option Minimum Password Age for user accounts das minimale Kennwortalter angegeben werden, ehe es vom Benutzer geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden (z.B. 7:00:00:00 für sieben Tage). Wird als Wert mit Klammern (Nie) eingetragen, wird kein Mindestalter definiert.
- Im darauffolgenden Schritt muss man in der Option Maximum Password Age for user accounts im Attribut msDS-MaximumPasswordAge diesmal das maximale Alter eines Kennworts eingeben. In diesem Attribut wird definiert, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss! Auch hier muss die Zeitangabe im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Es dürfte jedem klar sein, dass dieser Wert gleich oder höher sein muss als der Wert im Attribut msDS-MinimumPasswordAge.
- Bei der nächsten Option Lockout threshold for lockout of user accounts muss im Attribut msDS-LockoutThreshold der Wert für die Kontosperrschwelle eingegeben werden. Wie oft der Benutzer sein Kennwort falsch eingeben darf ehe sein Benutzerkonto gesperrt wird, legt man in diesem Attribut fest. Als Wert kann zwischen 0 und 65535 gewählt werden. Gibt man als Wert 0 ein, wird das Benutzerkonto nie gesperrt.
- Mit der Option Observation Window for lockout of user accounts bestimmt man im Attribut msDS-LockoutObservationWindow, wie lange die Anmeldefehlversuche gespeichert werden sollen, ehe der Kontosperrungszähler zurückgesetzt wird. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man die Zeit auf 20 Minuten festlegen, so muss der Wert folgendermaßen konfiguriert werden 00:00:20:00.
- Zum Schluss muss man noch für die Option Lockout duration for locked out user accounts im Attribut msDS-LockoutDuration die Kontosperrdauer angeben. Das Format der Zeitangabe muss so aussehen Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss). Wenn also der Benutzer sein Kennwort mehr als der Wert, der im Attribut msDS-LockoutThreshold definiert ist falsch eingegeben hat und das Benutzerkonto für zehn Minuten gesperrt werden soll, muss man diesen Wert eintragen 00:00:10:00.
- Nun gelangt man auf die letzte Seite, auf der man zum einen Fertig stellen und zum anderen auf Weitere Attribute klicken kann. Mit einem Klick auf Weitere Attribute öffnet sich ein weiteres Dialogfenster in dem man die Benutzer und Gruppen angeben kann, mit denen dieses PSO verknüpft werden soll. Dort gilt es im Feld Anzuzeigende Eigenschaften den Eintrag Optional und im Feld Anzuzeigende Eigenschaft das Attribut msDS-PSOAppliesTo auszuwählen. Daraufhin muss im Feld Attribut bearbeiten der DN des Objekts angegeben werden, auf dem das PSO angewendet werden soll. Da es sich hierbei um ein mehrwertiges Attribut handelt, können mehrere Objekte angegeben werden, auf denen dasselbe PSO wirken soll. Wenn ein DN eingetragen wurde, muss der Wert mit Hinzufügen in das Feld Wert(e) übernommen werden. Wurden alle Werte eingetragen, gelangt man mit OK zum Dialogfeld Objekt erstellen zurück.
- Mit einem Klick auf Fertig stellen wird nun endlich das PSO im „Password Settings Container“ erstellt. Falls ein Attribut einen ungültigen Wert enthält, erscheint nach dem Klick auf Fertig stellen eine Fehlermeldung.
Nach dem bestätigen der Fehlermeldung mit OK kann man im Dialogfenster Objekt erstellen zurück zum bemängelten Attribut navigieren, um den Wert zu korrigieren. Die Verdächtigen sind dabei die Attribute, die eine Zeitangabe in Form von Tage:Stunden:Minuten:Sekunden enthalten. Z.B. darf der Wert im Attribut msDS-LockoutObservationWindow nicht größer sein (höchstens gleich) als der Wert im Attribut msDS-LockoutDuration. Auch das UAC kann schuld sein. Das ADSIEdit sollte explizit als Administrator gestartet werden.
PSOs mit LDIFDE erstellen
Es gibt auch eine skriptbasierte Alternative, mit dem PSOs erstellt werden können. Das Erstellen von PSOs kann auch mit dem Kommandozeilentool LDIFDE automatisiert durchgeführt werden.
Die Einträge in der LDF Datei müssen folgendermaßen aussehen:
dn:CN=PSO,CN=Password Settings Container,CN=System,DC=Domäne,DC=de
changetype:add
objectClass:msDS-PasswordSettings
msDS-MaximumPasswordAge:-51840000000000 (entspricht 60 Tage)
msDS-MinimumPasswordAge:-1728000000000 (entspricht 2 Tage)
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:20
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-36000000000 (entspricht 60 Minuten)
msDS-LockoutDuration:-36000000000 (entspricht 60 Minuten)
msDS-LockoutThreshold:0
msDS-PasswordSettingsPrecedence:10
msDS-PSOAppliesTo:CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de
Der Import erfolgt mit diesem Befehl:
Ldifde -i -f C:\PSO.ldf
Weitere Informationen:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Domänen- und Gesamtstrukturfunktionsmodus
LDIFDE – LDAP Data Interchange Format Data Exchange
Comments are closed, but trackbacks and pingbacks are open.