Active Directory (AD) basierte Gruppenrichtlinienobjekte (auf Englisch: Group Policy Object, kurz GPO) bestehen hauptsächlich aus zwei Komponenten, bestehend aus der logischen und physikalischen Struktur. Der logische Teil einer GPO wird in der AD-Datenbank (NTDS.dit) gespeichert und wird als Gruppenrichtliniencontainer (auf Englisch: Group Policy Container, kurz GPC) bezeichnet. Die physikalische Komponente einer GPO wird im Dateisystem, im replizierten Verzeichnis SYSVOL gespeichert und lautet Gruppenrichtlinienvorlage (auf Englisch: Group Policy Template, kurz GPT).
In den Eigenschaften eines GPC werden alle AD relevanten Konfigurationsdaten einer GPO gespeichert, wie beispielsweise der Pfad zur Gruppenrichtlinienvorlage (das Attribut gPCFileSysPath im entsprechenden GPC, also der Pfad zum GPT), der Status von Gruppenrichtlinienobjekten (das Attribut flags) oder die Zugriffsteuerungsliste (Access Control List, kurz ACL) die bestimmt, welcher Benutzer bzw. Gruppe die Einstellungen eines GPOs verwalten darf. Den GPC selbst findet man in der Domänenpartition im Container CN=Policies,CN=System,DC=<Domäne>. Diesen Container kann man in der MMC Active Directory-Benutzer und –Computer (dsa.msc) zum Vorschein bringen. Dazu muss man jedoch zuerst in der MMC dsa.msc unter Ansicht die „Erweiterte Features“ aktivieren. Die GPC werden im AD-Container Policies mit ihrer {GUID} dargestellt und ist derselbe, wie er auch im GPT angezeigt wird.
Im GPT befinden sich die meisten Einstellungen eines GPOs sowie verschiedene Verzeichnisse und Konfigurationsdateien. Im GPT werden also alle aktuellen GPO-Einstellungen eines GPOs gespeichert. Die GPTs werden im Dateisystem tatsächlich unter %windir%\SYSVOL\domain\Policies, jeweils dargestellt mit ihrer {GUID}, gespeichert. Nicht zu verwechseln mit den Junction Points unter %windir%\SYSVOL\sysvol\<Domäne>\Policies. Tools für die Verwaltung von GPOs (z.B. die GPMC) verwenden die Junction Points und nicht den echten Speicherort der GPTs.
Wichtig für das Troubleshooting ist zu wissen, dass die hauptsächlichen Komponenten einer GPO, nämlich der GPC und das GPT, auf unterschiedliche Weise repliziert werden. Der GPC wird im Rahmen der AD-Replikation repliziert. Das GPT wird je nach Domänenfunktionsmodus entweder vom FRS (File Replication Service) oder vom DFS-R (Distributed File System Replication) repliziert. Liegen die Wurzeln einer Domäne im Domänenfunktionsmodus „Windows Server 2003“ oder niedriger, wird das GPT durch den FRS repliziert. Wurde die Domäne mindestens im Domänenfunktionsmodus „Windows Server 2008“ installiert, kommt DFS-R für die Replikation des GPT und somit des SYSVOLs zum Einsatz.
Die Performance bei der Abarbeitung von GPOs erhöhen
Für die Performance des Clients bei der Abarbeitung von GPOs (die auf ihn wirken) ist es empfehlenswert, den nicht konfigurierten Teil einer GPO stets zu deaktivieren. Das bedeutet, wenn in einer GPO lediglich Einstellungen im Benutzerkonfigurationsteil vorgenommen wurden, sollte der Computerkonfigurationsteil deaktiviert werden und vice versa.
Deaktivieren lässt sich ein Teil oder die gesamte GPO in der GPMC (Group Policy Management Console, zu Deutsch: Gruppenrichtlinienverwaltungskonsole). Mit einem Rechtsklick auf der entsprechenden GPO wählt man die Option Objektstatus aus und kann dann den gewünschten Teil oder die gesamte GPO deaktivieren. Das funktioniert auch wenn man die entsprechende GPO in der GPMC ausgewählt hat und danach zum Reiter Details wechselt.
Den Status der GPOs abfragen
Den Status einer GPO veranschaulicht das Attribut flags, das sich in den Eigenschaften jedes GPCs befindet.
Dabei kann das Attribut flags folgende Werte enthalten:
- Der Wert 0 im Attribut flags bedeutet, das gesamte Gruppenrichtlinienobjekt, also der Benutzerkonfigurations- und Computerkonfigurationsteil ist aktiviert.
- Der Wert 1 bedeutet, der Benutzerkonfigurationsteil einer GPO ist deaktiviert.
- Ist der Wert 2, wurde der Computerkonfigurationsteil einer GPO deaktiviert.
- Beim Wert 3 ist das gesamte GPO deaktiviert.
State of the Art kann man den Status der GPOs in der AD-PowerShell mit folgenden Einzeilern abfragen:
# Alle GPOs mit ihrem Status anzeigen lassen:
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs anzeigen, die beide Teile (Benutzer- und Computerkonfiguration) aktiviert haben:
Get-ADObject -Server <DC> -LDAPFilter "(flags=0)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs die den Teil der Benutzerkonfiguration deaktiviert haben, werden folgendermaßen angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=1)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs die den Computerkonfigurationsteil deaktiviert haben, werden wie folgt angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=2)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle komplett deaktivierten GPOs (beide Teile Benutzer- und Computerkonfigurationsteil sind deaktiviert) werden so angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=3)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
Das Attribut flags automatisiert mit einem AD-PowerShellskript abfragen
Man kann die Abfrage auch automatisiert mit folgendem AD-PowerShellskript durchführen.
######################################################
#
# AD-PowerShellskript zur Statusabfrage von GPOs
#
# Von: Yusuf Dikmenoglu 05/2011
#
# http://blog.dikmenoglu.de
#
######################################################
$auswahl = Read-Host "Welcher GPO-Status soll angezeigt werden (0... Alle komplett aktiven GPOs anzeigen 1...Benutzerkonfiguration ist deaktiviert 2...Computerkonfiguration ist deaktiviert 3...GPOs die komplett deaktiviert sind):"
switch ($auswahl){
0 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 0){
write-host "Gesamte GPO aktiviert: " $_.displayName
}
}
}
1 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 1){
write-host "Benutzerkonfiguration des GPO ist deaktiviert: " $_.displayName
}
}
}
2 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 2){
write-host "Computerkonfiguration des GPO ist deaktiviert: " $_.displayName
}
}
}
3 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 3){
write-host "Gesamte GPO deaktiviert: " $_.displayName
}
}
}
default{
Write-Host "Ungültige Eingabe"
}
}
Setzt man Password Setting Objects (kurz PSOs) auch bekannt als fein abgestimmte Kennwortrichtlinien ein, kann es zu Verwirrungen bei der Meldung die Windows liefert kommen, wenn ein Benutzer ein Kennwort vergeben möchte das nicht den Vorgaben des ihm zugewiesenen PSO entspricht.
Welche Voraussetzungen existieren müssen damit PSOs eingesetzt werden können oder wie PSOs konfiguriert werden, steht neben weiteren Details im folgenden Artikel:
Password Setting Objects erstellen und verwalten
Damit man nicht aufs Glatteis durch die von Windows erzeugte Meldung geführt wird und um PSOs erfolgreich zu implementieren, hier ein paar wichtige Hinweise:
- Versucht ein Benutzer auf den ein PSO verlinkt wurde, auf einem Windows XP Client oder Windows Server 2003 sein Kennwort zu ändern, erhält er diese Meldung:
In diesem Fall hat der Benutzer erfolglos versucht sein Kennwort zu ändern. Das neue Kennwort entsprach nicht den Vorgaben aus dem PSO. Daher ist es folgerichtig, dass eine Meldung erscheint. Allerdings stammen die Kennwort-Anforderungen in dem Dialogfenster aus der Domänenrichtlinie Default Domain Policy, die auf Domänenebene verlinkt ist! Die Meldung hat sich leider mit Einführung von PSOs nicht verändert. Es erscheint kein eigenes Dialogfenster, in dem die Kennwortvorgaben des PSO enthalten sind!
- Versucht der Benutzer auf einem Windows 7 Client oder Windows Server 2008/R2 sein Kennwort zu ändern, erhält er bei nicht Einhaltung der Kennwortvorgaben aus dem PSO diese Meldung:
Auch diese Meldung ist irreführend, denn es wird auf die Kennwortrichtlinie der Domäne, also auf die Default Domain Policy verwiesen, in der standardmäßig die Kennwortvorgaben auf Domänenebene definiert sind. Eine andere Meldung mit den Kennwortvorgaben der PSO erscheint weiterhin nicht!
- Versucht der Administrator, das Kennwort eines Benutzers auf den ein PSO verlinkt wurde zu ändern, erscheint diese Meldung:
Diese Meldung ist ebenfalls trügerisch, denn angeblich entspricht das neue Kennwort nicht den Anforderungen der Kennwortrichtlinien. Abgesehen davon das es sich bei dem PSO nicht um eine Kennwortrichtlinie sondern um ein AD-Objekt handelt, erscheint einmal mehr kein Hinweis auf das PSO!
-
Führt man auf dem Client unter Start – Ausführen das Resultant Set of Policy (RSoP) aus, werden dort die Kennwortvorgaben wieder aus der Default Domain Policy angezeigt! Daher bringt ein RSOP.msc für die Überprüfung eines PSO nichts! Denn da es sich bei den PSOs nicht um Gruppenrichtlinien (GPOs) handelt, werden diese auch nicht im RSOP angezeigt. Und abgesehen davon ist RSOP.msc zum Überprüfen von GPOs nicht mehr State oft the Art und sollte ab Windows 7 und Windows Server 2008 R2 auch nicht mehr verwendet werden. Besser ist es in der Kommandozeile diesen Befehl zu verwenden: GPResult /h GPO-Report.html.
- PSOs dürfen erst erstellt werden, wenn sich der Domänenfunktionsmodus bereits im Modus Windows Server 2008 oder höher befindet. Wenn PSOs erstellt werden bevor sich der Domänenfunktionsmodus mindestens in der Ebene Windows Server 2008 befindet, werden diese auch nach dem Hochstufen nicht angewendet!
- Ob und welches PSO auf einen Benutzer verlinkt ist, sollte mit dem Kommandozeilenbefehl dsget user <DN des Benutzers> -effectivepso kontrolliert werden. Beispielsweise: dsget user " CN=Yusuf Dikmenoglu,OU=IT,DC=ad2008R2,DC=Dikmenoglu,DC=de" -effectivepso
Einige werden das Verhalten unter Windows 7 unter Windows Server 2008 R2 sicherlich kennen.
Angenommen man lässt sich unter Windows 7 oder Windows Server 2008 R2 in der Gruppenrichtlinienverwaltungskonsole (GPMC) die konfigurierten Einstellungen einer Gruppenrichtlinie (GPO) im Reiter Einstellungen anzeigen.
Möchte man dann die GPO umbenennen während man sich im Reiter Einstellungen befindet, so wählt man im Kontextmenü der entsprechenden GPO die Option Umbenennen. Durch einfaches los tippen kann man der GPO einen neuen Namen vergeben.
Versucht man jedoch, anstatt direkt los zu tippen mit den Pfeiltasten den Cursor zu bewegen oder mit der Backspace-Taste einzelne Buchstaben zu löschen, so funktioniert das nicht! Der Cursor lässt sich nur mit der Maus bewegen.
Endlich hat Microsoft reagiert und einen Hotfix veröffentlicht, der dieses Verhalten ändert.
Der Hotfix kann von hier angefordert werden:
BACKSPACE or arrow keys do not work in MMC on a computer that is running Windows 7 or Windows Server 2008 R2
Der Hotfix ist im Service Pack 1 für Windows 7 und Windows Server 2008 R2 nicht enthalten. Auch wenn das SP1 installiert ist, muss zum Ändern dieses Verhalten der Hotfix installiert werden!
Im KB-Artikel steht zwar das ein Neustart nach der Installation des Hotfix durchgeführt werden muss, jedoch fordert Windows nicht zu einem Neustart auf und auch ohne Neustart, ist das Problem behoben.
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.
2. Das Kennwort muss mindestens sechs Zeichen lang sein.
3. Das Kennwort muss Zeichen aus drei der folgenden Kategorien enthalten: - Großbuchstaben (A bis Z)
- 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
Wer für die Administration von Gruppenrichtlinien in einem Windows Netzwerk zuständig ist, der sollte und wird die Gruppenrichtlinien-Verwaltungskonsole (auf Englisch: Group Policy Management Console, kurz GPMC) kennen. Installiert man sich unter Windows XP und Windows Server 2003 die GPMC das separat heruntergeladen werden muss, stehen einem 32 Skripte im Verzeichnis %PROGRAMFILES%\GPMC\Scripts zur Verfügung. Mit diesen GPMC-Skripts kann man viele alltägliche Gruppenrichtlinien-Aufgaben leicht und automatisiert durchführen. Viele Gruppenrichtlinien-Administratoren werden diese Skripte zu schätzen wissen.
Doch mit Vista und Windows Server 2008 stehen die GPMC-Skripte erst mal nicht zur Verfügung. Die GPMC steht zwar ab Vista nach der Installation der Remote Server Administration Tools (RSAT) und unter Windows Server 2008, erst nach Aktivierung der Gruppenrichtlinienverwaltung in den Features weiterhin zur Verfügung, doch die GPMC Skripte fehlen hingegen. Stattdessen stellt Microsoft die GPMC Skripte als separaten Download für Vista und Windows Server 2008 zur Verfügung. Nach der Installation stehen die GPMC Skripte in gewohnter Weise zur Verfügung.
GPMC Sample Scripts
Unter Windows 7 und Windows Server 2008 R2 steht die GPMC ohne die GPMC Skripte in den RSAT auch zur Verfügung. Es gibt jedoch keinen separaten Download der GPMC Skripte für Windows 7 und Windows Server 2008 R2. Aber die GPMC Skripte für Vista und Windows Server 2008 lassen sich auch unter Windows 7 und Windows Server 2008 R2 weiterhin nutzen. Wer allerdings für die Administration der Gruppenrichtlinien zukunftsorientiert sein möchte, der nutzt die PowerShell! Microsoft stellt 25 Cmdlets allein für Gruppenrichtlinien bereit, mit denen weitestgehend die gleichen Administrationsaufgaben durchgeführt werden können wie mit den GPMC Skripts. Die GPO Cmdlets die in der Zukunft erweitert werden, sind die Nachfolger der GPMC Skripts.
Damit die 25 GPO Cmdlets zur Verfügung stehen, müssen diese zuerst mit dem PowerShellbefehl Import-Module GroupPolicy geladen werden. Das Laden der GPO Cmdlets muss sowohl in der AD-PowerShell, als auch in der Windows PowerShell v2 durchgeführt werden. Man kann sich natürlich ein PowerShell-Profil erstellen, damit beim Starten der AD-/PowerShell die GPO Cmdlets beim Öffnen der PowerShell Konsole automatisch geladen werden. Nach dem Import kann man sich die folgenden 25 GPO Cmdlets mit Get-Command *-GP* anzeigen lassen. Startet man dagegen die Konsole Windows PowerShell Modules, wird beim Starten der Konsole unter anderem automatisch das GPO-Modul geladen.
Die 25 GPO Cmdlets sind:
- Backup-GPO: Mit diesem Cmdlet sichert man das angegebene Gruppenrichtlinienobjekt (GPO) oder alle Gruppenrichtlinienobjekte in einer angegebenen Domäne in ein Sicherungsverzeichnis. Dabei muss das Sicherungsverzeichnis bereits existieren.
- Copy-GPO: Dieses Cmdlet erstellt eine neue GPO und kopiert die Einstellungen aus der Quell-GPO in die neue GPO. Mit diesem Cmdlet kann eine GPO aus einer Domäne in eine andere Domäne innerhalb der gleichen Gesamtstruktur kopiert werden.
- Get-GPInheritance: Informationen zur Gruppenrichtlinienvererbung für eine angegebene Domäne oder Organisationseinheit kann man sich mit diesem Cmdlet ausgeben lassen.
- Get-GPO: Eine bestimmte GPO oder alle GPOs innerhalb einer Domäne kann man sich mit diesem Cmdlet anzeigen lassen.
- Get-GPOReport: Hiermit wird ein Bericht im XML- oder HTML-Format generiert, in dem die Eigenschaften und Richtlinieneinstellungen für eine angegebene GPO oder für alle GPOs einer Domäne angezeigt werden. Dieses Cmdlet eignet sich ideal zu Dokumentationszwecken. Möchte man alle Richtlinieneinstellungen aller GPOs innerhalb der Domäne in eine HTML Datei exportieren, so gilt es diesen Befehl auszuführen: Get-GPOReport -All -Domain <Domäne.de> -ReportType HTML -Path C:\GPOReport\GPOReport.html. Das Zielverzeichnis muss bereits existieren, sonst erhält man eine Fehlermeldung.
- Get-GPPermissions: Die Berechtigungen für einen oder mehrere Sicherheitsprinzipale kann man mit diesem Cmdlet in der angegebenen GPO abrufen.
- Get-GPPrefRegistryValue: Dieses Cmdlet zeigt eine oder mehrere Registrierungseinstellungen die unterhalb der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO getätigt wurden an.
- Get-GPRegistryValue: Bei diesem Cmdlet werden eine oder mehrere registrierungsbasierte Richtlinieneinstellungen aus der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO abgerufen.
- Get-GPResultantSetOfPolicy: Mit diesem Cmdlet kann man die Richtlinienergebnissatz-Informationen für einen Benutzer, einen Computer oder für beide in eine Datei im HTML- oder XML-Format ausgeben lassen.
- Get-GPStarterGPO: Ein bestimmtes oder alle Starter-GPOs werden mit diesem Cmdlet angezeigt.
- Import-GPO: Dieses Cmdlet importiert die Einstellungen aus einer gesicherten GPO in die angegebene Ziel-GPO. Dabei kann sich das Ziel-GPO in einer anderen Domäne oder in einer anderen Gesamtstruktur befinden als die Sicherungs-GPO und muss vorher nicht existieren.
- New-GPLink: Eine GPO wird auf eine Organisationseinheit (OU), einen AD-Standort oder auf die Domäne mit diesem Cmdlet verlinkt.
- New-GPO: Eine neue GPO wird mit diesem Cmdlet erstellt.
- New-GPStarterGPO: Mit diesem Cmdlet wird eine neue Starter-GPO erstellt.
- Remove-GPLink: Dieses Cmdlet entfernt eine GPO-Verklinkung von einer OU, einem AD-Standort oder von der Domäne.
- Remove-GPO: Eine GPO wird mit samt allen Verlinkungen, mit diesem Cmdlet gelöscht.
- Remove-GPPrefRegistryValue: Eine oder mehrere Registrierungseinstellungen werden aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO mit diesem Cmdlet entfernt.
- Remove-GPRegistryValue: Um eine oder mehrere Registrierungsbasierte Richtlinieneinstellungen aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO zu entfernen, muss dazu dieses Cmdlet verwendet werden.
- Rename-GPO: Mit diesem Cmdlet kann man eine GPO umbenennen bzw. der GPO einen anderen Anzeigenamen zuweisen. Dabei bleibt die GUID der umbenannten GPO erhalten.
- Restore-GPO: Dieses Cmdlet stellt eine GPO-Sicherung in der Domäne wieder her, in der sie ursprünglich gespeichert wurde. Ist die ursprüngliche Domäne oder die GPO nicht mehr in der Domäne vorhanden, tritt ein Fehler auf.
- Set-GPInheritance: Die Vererbung einer GPO kann mit diesem Cmdlet deaktiviert werden. Oder die Deaktivierung der Vererbung für eine angegebene OU oder Domäne lässt sich ebenfalls mit diesem Cmdlet aufheben.
- Set-GPLink: Die Eigenschaften einer GPO-Verknüpfung lassen sich mit diesem Cmdlet festlegen.
- Set-GPPermissions: Die Berechtigungen einer GPO oder für alle GPOs innerhalb einer Domäne lassen sich mit diesem Cmdlet bearbeiten.
- Set-GPPrefRegistryValue: Dieses Cmdlet konfiguriert eine Registrierungseinstellung unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.
- Set-GPRegistryValue: Mit diesem Cmdlet konfiguriert man eine oder mehrere registrierungsbasierte Richtlinieneinstellungen unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.
Die Hilfe zu jedem einzelnen Cmdlet lässt sich mit Get-Help <Cmdlet> -Full anzeigen. Also z.B.: Get-Help Get-GPOReports -Full.
Auch an dieser Stelle zeigt sich: Die Zukunft spricht PowerShell! 
Weitere Informationen:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
AD-PowerShell Befehle
Es ist empfehlenswert, dass jedes Unternehmen eine Kennwortrichtlinie einsetzt, die entsprechend konfiguriert ist
(Komplexität, Kennwortchronik, Kennwortlänge, Kennwortalter etc.).
Kennwortrichtlinien, die für Domänen-Benutzer gelten sollen, müssen auf Domänenebene verlinkt werden. Wenn eine Kennwortrichtlinie auf einer Organisationseinheit (OU) verlinkt wird, betrifft das lediglich die lokalen Benutzerkonten auf den Clients. Bis Windows Server 2003 kann es dabei pro Domäne nur eine Kennwortrichtlinie geben. Besteht der Bedarf für einen Standort eine eigene Kennwortrichtlinie zu definieren, so musste für diesen Standort eine Sub-Domäne erstellt werden. Anders war dieses Ziel mit Bordmitteln nicht lösbar. Erst ab Windows Server 2008 lassen sich mehrere Kennwortrichtlinien pro Domäne mit Bordmitteln einrichten und nennen sich dort "Password Settings Objects" kurz PSO. In einer Windows Server 2003 Umgebung kann man mehrere Kennwortrichtlinien pro Domäne nur mit Dritt-Anbieter Tools realisieren, wie z.B. Specops Password Policy oder nFront Password Filter.
Möchte ein Unternehmen das bisher keine Kennwortrichtlinie im Einsatz hatte, dieses nun nachholen, sollte die Einführung einer Kennwortrichtlinie sorgfältig geplant und die Benutzer ausführlich informiert werden. Es ist ratsam nach der Konfiguration der Kennwortrichtlinie, im Reiter Konto die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ in allen Benutzerkonten zu aktivieren. Denn schließlich existierte bisher keine Sicherheitsanforderung bei der Kennwortwahl, so dass es höchste Zeit wird dieses schnellstmöglich zu aktivieren.
Ist allerdings eines der Flags im userAccountControl Attribut, nämlich die Option „Kennwort läuft nie ab“ aktiviert, so ist ein zusätzliches aktivieren der Option Benutzer muss Kennwort bei der nächsten Anmeldung ändern nicht möglich. Es dürfte jedem klar sein, dass sich diese beiden Optionen widersprechen. Wird die Option „Kennwort läuft nie ab“ aktiviert, so wird mit einem Hinweis die evtl. bereits aktivierte Option „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ deaktiviert.
Wird in den Kennwortrichtlinien die Einstellung „Maximales Kennwortalter“ konfiguriert, so kann es passieren, dass die Benutzer bei ihrer nächsten Anmeldung aufgefordert werden ihr Kennwort zu ändern, ohne dass die Option „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ gesetzt ist. Denn angenommen ein Benutzer verwendet sein Kennwort, das bereits 200 Tage alt ist und es wird ein maximales Kennwortalter von 180 Tagen definiert, so erhält dieser Benutzer bei seiner nächsten Domänenanmeldung die Aufforderung sein Kennwort zu ändern. Das Alter des Kennworts wird vom Attribut Pwd-Last-Set errechnet. In dem Attribut wird ein 64Bit Integer Wert des Zeitpunkts der letzten Kennwortänderung gespeichert. Umrechnen lässt sich dieser Wert mit dem Befehl: w32tm /ntte <Wert>.
Es gibt aber eine Option, die verhindert, dass nach der Konfiguration eines maximalen Kennwortalters die Benutzer mit einem älteren Kennwort dies nicht bei der nächsten Domänenanmeldung ändern müssen.
-
In den Benutzerkonten ist zuerst die Kontooption Benutzer muss Kennwort bei der nächsten Anmeldung ändern zu aktivieren.
-
Danach gilt es die gewählte Option mit Übernehmen zu bestätigen.
-
Anschließend muss die soeben aktivierte Kontooption erneut deaktiviert und mit Übernehmen oder OK bestätigt werden.
Wird in den Eigenschaften eines Benutzerkontos im Reiter Konto die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ gesetzt, so erhält das Attribut pwdLastSet im entsprechenden Benutzerobjekt den Wert „0“. Wenn anschließend der Haken wieder entfernt wird, erhält das Attribut als Wert, dass Datum sowie die Uhrzeit von dem Moment, in dem diese Einstellung durchgeführt wurde.
In den Benutzerobjekten lässt sich die Kontooption z.B. durch ein Skript aktivieren oder deaktivieren. Eine andere Variante wäre zuerst die Benutzer mit STRG auszuwählen, dann mit einem Rechtsklick auf die Benutzerobjekte die Eigenschaften aufzurufen, um danach im Reiter Konto die entsprechende Option auszuwählen bzw. zu deaktivieren.
Verifizieren kann man das durch Überprüfen des Attributs pwdLastSet im Benutzerobjekt, mit dem Befehl: w32tm /ntte <Wert aus pwdLastSet>.
Dort sollte dann das aktuelle Datum stehen.
Wann das Kennwort zuletzt gesetzt wurde, kann man auch wie folgt kontrollieren: Net User <username> /Domain.
Oder mit der Account Info DLL (kurz Acctinfo.dll).
Seit der Einführung des "Active Directory" mit Windows 2000, können standardmäßig "authentifizierte Benutzer" 10 Clients in die Domäne aufnehmen.
Im weiteren Verlauf wird beschrieben, welche beiden Möglichkeiten dem Administrator zur Verfügung stehen um diese Konfiguration zu ändern
und wie die notwendige Berechtigung zum "Hinzufügen der Clients zur Domäne" an die entsprechenden Personen erteilt werden können.
Die Gruppenrichtlinie
In der Default Domain Controllers Richtlinie ist das Benutzerrecht festgelegt, wer Arbeitsstationen zur Domäne hinzufügen darf.
Der Pfad ist folgender:
Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\
Zuweisen von Benutzerrechten\Hinzufügen von Arbeitsstationen zur Domäne
Diese Richtlinie enthält standardmäßig bereits die Gruppe Authentifizierte Benutzer.
Somit ist es jedem Domänen-Benutzer möglich, 10 Clients in die Domäne hinzuzufügen.
Weitere Benutzer und/oder Gruppen können jederzeit in die Richtlinie hinzugefügt werden.
Dieses Verhalten ist aber meistens (wegen der Unternehmensrichtlinie) nicht gewünscht.
Nicht nur, dass der Domänen-Benutzer sein privates Laptop – das nicht den Sicherheitsrichtlinien des Unternehmens entspricht –
mitbringen und zur Domäne hinzufügen könnte, sondern, er kennt bereits das lokale Administrator Kennwort und kann sich damit lokal anmelden.
Danach hat er die Möglichkeit, seinen Domänen-Account (unter Angabe seiner Domänen-Benutzer Daten) der lokalen Gruppe Administratoren hinzufügen.
Um dies zu unterbinden, könnte man aus der o.g. Richtlinie die Gruppe „Authentifizierte Benutzer“
entfernen und lediglich autorisierte Benutzer aus der IT-Abteilung hinzufügen.
Das Kontingent von 10 Arbeitsstationen, wird im Attribut MS-DS-Machine-Account-Quota das sich in den Eigenschaften
der Domänenpartition befindet festgelegt. Dieser Wert lässt sich mit ADSIEdit verändern. Wird im Attribut als Wert "0" eingetragen,
können die in der Richtlinie eingetragenen Benutzer oder Gruppen keine Arbeitsstationen mehr zur Domäne hinzufügen.
Das im Attribut definierte Kontingent, gilt ausschließlich für die Benutzer und Gruppen die in der o.g. Richtlinie definiert sind.
Sie gilt nicht für Benutzer oder Gruppen, die die Berechtigung zum Erstellen von Computerobjekten delegiert bekommen haben.
Wie viele Arbeitsstationen der Benutzer bereits zur Domäne hinzugefügt hat, wird anhand des Attributs MS-DS-Creator-SID,
dass sich in den Eigenschaften der Computerkonten befindet errechnet. In diesem Attribut wird die ObjectSID (als ein "Octet Stream")
des Benutzers eingetragen, natürlich nur, wenn die Grenze des im Attribut MS-DS-MachineAccountQuota eingetragenen Werts (standardmäßig 10)
noch nicht erreicht wurde. Das überprüfen geht recht schnell, da das Attribut MS-DS-Creator-SID indiziert ist.
Wird ein Client der vom Benutzer zur Domäne hinzugefügt wurde aus der Domäne entfernt, deaktiviert sich lediglich das Computerkonto im AD.
Das Computerkonto bleibt jedoch weiterhin im AD bestehen. Erst wenn das Computerkonto aus dem AD gelöscht wird,
kann der Benutzer einen weiteren Client zur Domäne hinzufügen.
Falls aber ein Benutzer dem die Berechtigung "Erstellen von Computerobjekten" delegiert wurde oder ein administratives Konto (Domänen-Admin)
einen Client zur Domäne hinzufügt, erhält anschließend das Attribut MS-DS-Creator-SID im Computerkonto keinen Wert!
Wenn nun ein Client mithilfe des Benutzerrechts "Hinzufügen von Arbeitsstationen zur Domäne" zur Domäne hinzugefügt wurde,
wird als Besitzer des Computerkontos die Gruppe "Domänen-Admins" eingetragen. Das Computerkonto befindet sich
nicht im Besitz desjenigen, der den Client zur Domäne hinzugefügt hat. Natürlich wird aber im Attribut MS-DS-Creator-SID
die ObjektSID des Benutzers eingetragen.
Besitzt ein Benutzer das Recht Hinzufügen von Arbeitsstationen zur Domäne und wurde ihm zusätzlich die Berechtigung zum Estellen
von Computerkonten in der Domäne delegiert, wird der Client basierend auf der delegierten Berechtigung zur Domäne hinzugefügt und nicht
basierend auf dem Benutzerrecht.
Die Erklärung zu der o.g. Richtlinie lautet wie folgt:
Mit dieser Sicherheitseinstellung wird festgelegt, welche Gruppen oder Benutzer Arbeitsstationen zu einer Domäne hinzufügen können.
Diese Sicherheitseinstellung ist nur für Domänencontroller gültig. Standardmäßig besitzt jeder
authentifizierte Benutzer dieses Recht und kann bis zu 10 Computerkonten in der Domäne erstellen.
Durch Hinzufügen eines Computerkontos zur Domäne kann der Computer an der Active Directory-Vernetzung teilnehmen.
Wenn eine Arbeitsstation zum Beispiel einer Domäne hinzugefügt wird, kann diese Arbeitsstation Konten und Gruppen erkennen,
die in Active Directory vorhanden sind.
Standardwert: "Authentifizierte Benutzer" bei Domänencontrollern.
Hinweis: Benutzer, die für den Active Directory-Container "Computer" die Berechtigung zum Erstellen von Computerobjekten
besitzen, können auch in der Domäne Computerkonten erstellen. Der Unterschied ist, dass auf Benutzer, die über Berechtigungen
für den Container verfügen, die Einschränkung zum Erstellen von maximal 10 Benutzerkonten nicht zutrifft. Darüber hinaus sind
die Computerkonten, die mithilfe von "Hinzufügen von Arbeitsstationen zur Domäne" erstellt wurden, im Besitz von
Domänenadministratoren, während bei Computerkonten, die mithilfe der Berechtigungen für den Container "Computer" erstellt wurden,
der Ersteller des Computerkontos der Besitzer ist. Wenn ein Benutzer über Berechtigungen für den Container verfügt und auch das Benutzerrecht
"Hinzufügen von Arbeitsstationen zur Domäne" besitzt, wird der Computer basierend auf den Berechtigungen für den Container "Computer" und nicht
basierend auf dem Benutzerrecht hinzugefügt.
Die Objektdelegierung
Idealerweise delegiert man über die Objektverwaltung in der MMC Active Directory-Benutzer und Computer (dsa.msc) einem Benutzer (besser einer Gruppe) die Berechtigung "Fügt einen Computer einer Domäne hinzu", anstatt die Werte in der o.g. Gruppenrichtlinie zu verändern. Dazu kann man mit einem Rechtsklick auf den Domänennamen in der dsa.msc den Objektdelegierungsassistenten aufrufen. Die entsprechende Berechtigung wird dann durch einen "allgemeinen Task" delegiert.
Diese Vorgehensweise hat aber einen Nachteil. Da der Objektdelegierungsassistent auf "Domänenebene" ausgeführt wurde,
können die Benutzer die diese Berechtigung erhalten haben in der MMC dsa.msc in jedem Container (dazu zählen auch OUs)
Computerkonten erstellen. Für viele Administratoren sind das (zurecht) zu viele Berechtigungen, denn die Benutzer sollen nur die
nötigsten Berechtigungen erhalten. Aber dieser allgemeine Task steht standardmäßig weder auf dem Standard-Container Computers,
noch in einer OU zur Verfügung. Das kommt daher, da in der Datei delegwiz.inf im [template6] lediglich der Eintrag
AppliesToClasses=domainDNS existiert. Dieser Eintrag lässt sich bearbeiten, so das die allgemeine Aufgabe
"Fügt einen Computer einer Domäne hinzu" auch auf dem Standard-Container Computers und
auf OUs zur Verfügung steht. Das würde dann folgendermaßen aussehen:
;----------------------------------------------------------
[template6] <-- ACHTUNG: Bei dieser Vorlage muss auf die Groß- und Kleinschreibung geachtet werden!
AppliesToClasses=domainDNS,organizationalUnit,container
Description="Fügt einen Computer einer Domäne hinzu"
ObjectTypes=SCOPE,computer
[template6.SCOPE]
;Berechtigung um Computerobjekte zu erstellen
computer=CC
[template6.computer]
;Berechtigungen für das Hinzufügen eines Computers zur Domäne
CONTROLRIGHT="Validated write to DNS host name","Account Restrictions","Reset Password","Validated write to service principal name"
;----------------------------------------------------------
Nach der Bearbeitung der Datei kann nun die Delegierung z.B. auf dem Standard-Container Computers
durchgeführt werden. Danach kann der Benutzer der diese Berechtigung erteilt bekommen hat, vom Client aus
diesen zur Domäne hinzufügen.
Der Benutzer kann einen Client auch dann zur Domäne hinzufügen, wenn dieser zuvor vom Domänen-Admin (!)
zur Domäne hinzugefügt und später wieder entfernt wurde. Das Computerobjekt im AD bleibt weiterhin im Besitz
des Domänen-Admins. Jedoch kann der Benutzer der diese Berechtigung erteilt bekommen hat, einen Client der zuvor
vom Domänen-Admin aus der Domäne entfernt wurde, erneut zur Domäne hinzufügen.
Zur Erinnerung: Wird ein Client von der Domäne zu einer Arbeitsgruppe hinzugefügt, bleibt das Computerkonto im AD
bestehen und wird nicht gelöscht!
Wird jedoch diese Berechtigung auf einer OU delegiert, so muss der Benutzer zuerst in der entsprechenden OU
das Computerkonto erstellen und kann erst dann, den Client zur Domäne hinzufügen.
Die Delegierung muss nicht zwangsläufig über den Assistenten eingerichtet werden. Stattdessen kann die Delegierung
auch durch das Bearbeiten der "Discretionary Access Control List (DACL)" des Containers oder mit DSACLS eingerichtet werden.
Für die Delegierung über die DACL, ist nach Hinzufügen des entsprechenden Benutzers oder der Gruppe, im Feld "Übernehmen für"
die Option Dieses und alle untergeordneten Objekte auszuwählen. Bei den Berechtigungen gilt es dann
die Option "Computer" erstellen zuzulassen. Auch hierbei gilt, wird die Delegierung im Standard-Container Computers eingerichtet,
kann der Benutzer den Client vom Client aus zur Domäne hinzufügen. Andernfalls muss zuerst das Computerkonto in der OU erstellt werden,
ehe der Client zur Domäne hinzugefügt werden kann.
Objektdelegierungen einrichten
Benutzer die über diese Berechtigung verfügen, können unbegrenzt Clients zur Domäne hinzufügen.
Versierte Administratoren können diese Berechtigung (Computerobjekte erstellen) natürlich auch automatisiert mit DSACLS vergeben.
Weitere Informationen:
Der Objektdelegierungsassistent
Delegierte Berechtigungen im AD verstehen
Delegierte AD-Berechtigungen anzeigen und entfernen
Default Limit to Number of Workstations a User Can Join to the Domain
Domain Users Cannot Join Workstation or Server to a Domain
"You Have Exceeded the Maximum Number of Computer Accounts" Error Message When You Try to Join a Windows XP Computer to a Windows 2000 Domain
Den Dateizugriff auf einem NTFS formatierten Datenträger kann man mit Windows-Boardmitteln überwachen.
Der Einsatz dieser Funktion sollte aber gut durchdacht sein, denn
- ist diese Einstellung vom Betriebsrat zu genehmigen bzw. ist Mitbestimmungspflichtig und
- sollte man sich Gedanken darüber gemacht haben, was mit den gesammelten Informationen geschehen soll.
Findet diese Aufzeichnung statt, um längerfristige statistische Aussagen über das Zugriffsverhalten der Benutzer zu erlangen, so sollte die Protokollgröße vergrößert (in den Eigenschaften des jeweiligen Logs) oder die Protokolle des öfteren archiviert werden.
Die Überwachung sollte sich auf die (wenigen) wichtigsten Dateien/Ordner beschränken, denn es werden Rechenleistung sowie Speicherplatz beansprucht.
Im ersten Schritt gilt es, die folgende Richtlinie entweder auf Lokaler-, Standort-, Domänen- oder OU-Ebene zu aktivieren:
Computerkonfiguration\Windows-Einstellungen\
Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\Objektzugriffsversuche überwachen
Mit dieser Richtlinie, überwacht man die Ressourcenauslastung des Systems für Dateien, Verzeichnisse, Freigaben, Drucker und Active Directory Objekte.
Als zweiten Schritt gilt es, die Überwachungsebene (System Access Control List, SACL) für einzelne Ordner und Dateien festzulegen, damit eine genaue Überwachung des Zugriffs stattfinden kann. Dieses muss für jedes Objekt das überwacht werden soll, konfiguriert werden.
Zum konfigurieren der Datei- und Ordnerüberwachung geht man folgendermaßen vor:
- Im Kontextmenü der zu überwachenden Datei bzw. Ordner, wählt man die Option Eigenschaften aus
- Auf der Registerkarte Sicherheitseinstellungen gilt es auf Erweitert zu klicken
- Im Dialogfeld Erweiterte Sicherheitseinstellungen für <Dateiname/Ordnername> wählt man die Registerkarte Überwachung aus
- Soll an dieser Stelle die Vererbung der Überwachungseinstellungen eines übergeordneten Ordners aktiviert werden, so gilt es im Reiter Berechtigungen die Option Berechtigungen übergeordneter Objekte, sofern vererbbar, über alle untergeordneten Objekte verbreiten. Diese Objekte inklusive den hier definierten Einträgen mit einbeziehen zu aktivieren
- Ist es stattdessen gewünscht, die Einstellungen des aktuellen Ordners an die untergeordneten Dateien sowie Ordner zu vererben, so wählt man die Option Überwachungseinträge für alle untergeordneten Objekte durch die angezeigten Einträge, sofern anwendbar, ersetzen aus
- Im Listenfeld Überwachungseinträge können entweder der Benutzer, die Gruppe oder die Computer ausgewählt werden, deren Aktionen überwacht werden sollen
- Um einen bestimmten Benutzer, eine bestimmte Gruppe oder einen Computer auszuwählen, klickt man auf Hinzufügen… und wählt dann im darauf folgenden Dialogfeld Benutzer, Computer oder Gruppen wählen das entsprechende Objekt aus.
Anschließend wird das folgende Dialogfeld Überwachungseintrag für <Datei-/Ordnername> angezeigt. In der Dropdownliste Übernehmen für: kann die Überwachungseinstellung unter anderem für „Nur diesen Ordner“, „diesen Ordner, Unterordner und Dateien“, „Nur Dateien“ sowie weitere Kombinationen angewendet werden. Danach wählt man die erfolgreichen und/oder fehlgeschlagenen zu überwachenden Ereignisse aus und beendet die Auswahl-Fenster jeweils mit einem Klick auf OK:
Hinweis: Ausgeschlossen davon ist die Überwachung der Synchronisierung von Offlinedateien und -ordnern.
Möchte man unter Windows Server 2000, die beiden Richtlinien „Default Domain Controllers Policy“ sowie „Default Domain Policy“ in den Auslieferungszustand zurücksetzen, so kann man das mit dem „Windows 2000 Default Group Policy Restore Tool“ „RecreateDefPol.exe“ erledigen:
Windows 2000 Default Group Policy Restore Tool
Hinweis: Dieses Tool gilt nur für Windows Server 2000!
Unter Windows Server 2003 kann man die beiden Richtlinien folgendermaßen zurücksetzen:
DCGPOFIX auf einem DC/Exchange
Es ist auch möglich, die Richtlinien „händisch“ zurückzusetzen:
How to reset user rights in the Default Domain Controllers Group Policy object
How to reset security settings in the default Domain GPO in Windows 2000
How To Reset User Rights in the Default Domain Group Policy in Windows Server 2003
Falls ein Exchange Server im (Windows Server 2000 oder Windows Server 2003) Netzwerk existiert,
muss anschließend das Exchangesetup „setup.exe“ mit dem Schalter „/Domainprep“ von der Exchange Server CD ausgeführt werden:
Exchange Server permissions are removed by the RecreateDefPol.exe tool in Windows 2000 Server
The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state
Einen Windows 2000/XP - Client, kann man ebenfalls von den angewendeten Richtlinien „befreien“.
Das geht, in dem alle Ordner sowie Unterschlüssel unter den folgenden Registry-Pfaden gelöscht werden:
- HKEY_CURRENT_USER\Software\Policies
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies
Als nächstes navigiert man zu folgendem Verzeichnis: „%windir%\system32\GroupPolicy“.
Dort existieren (unter anderem) ein Ordner Namens "Machine" und ein Ordner "User".
In diesen beiden Ordnern, befindet sich jeweils die Datei "registry.pol", die es ebenfalls zu löschen gilt.
Zu guter Letzt gilt es noch, die "user.pol" (%userprofile%\ntuser.pol) zu löschen, denn diese enthält die Verweise,
welche Einstellung aus welcher GPO kommt/kam. Anschließend ist ein Neustart fällig.
Möchte man, dass der Client erneut die Richtlinien von seiner Active Directory-Domäne bekommt, muss auf diesem ein „Gpupdate /Force“ ausgeführt werden, denn aufgrund der Policy-History (und der gpt.ini) die sich auf dem Client befindet, meint dieser, dass er immer noch mit den aktuellen Richtlinien ausgestattet ist und wird deshalb die Richtlinien, nicht von alleine übernehmen. Es sei denn, man würde die Policy-History löschen, dann würde es ebenfalls funktionieren.
Group Policy History Stored in Registry
Weitere Informationen:
Wiederherstellung der Default Richtlinien
Wenn es vorkommen sollte, dass man den Zugriff auf die GPOs verweigert bekommt, hängt das in den meisten Fällen am SMB - Signing.
Das SMB - Signing dient kurzerhand der Sicherheit. Einzelheiten können in den folgenden Artikeln nachgelesen werden:
http://support.microsoft.com/kb/887429/de
http://www.gruppenrichtlinien.de/index.html?/HowTo/SMB_Signing.htm
Um den Zugriff auf die GPOs zu erhalten, kann man die SMB - Einstellungen auch direkt in der Registry vornehmen.
Dazu gilt es die Registry unter „Start - Ausführen - Regedit“ aufzurufen und folgende Keys zu setzen:
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature 1
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature 1
http://support.microsoft.com/kb/839499/EN-US/
Danach sollten mindestens die beiden Dienste "Serverdienst" und "Arbeitsstationsdienst" neu gestartet werden (oder man startet den Server neu).
Nun hat man ca. 5 Minuten Zeit, um die in der Registry vorgenommene Einstellung, in die beiden Standard-Richtlinien zu konfigurieren.
Denn danach werden die Einstellungen die man in der Registry getätigt hat, erneut von der GPO überschrieben.
Als nächsten Schritt, sollten folgende Einstellungen in der „Default Domain Policy“ sowie „Default Domain Controllers Policy“ vorgenommen werden:
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Aktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Aktiviert
Wenn das nichts brachte, kann man noch versuchen, auf folgenden Reg-Key:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg"
das Konto "LOKALER DIENST" als Leseberechtigten einzutragen und anschließend muss der Server neu gestartet werden.
Windows XP verwendet für den schnellen Start- sowie für den Anmeldungvorgang, eine "optimierte" (das kann man sehen wie man will) Anmeldung.
Anders als zu Windows 2000 Zeiten werden die Gruppenrichtlinien in Windows XP, beim starten des Rechners und der Anmeldung des Benutzers asynchron verarbeitet. Dadurch wird der Anmeldebildschirm als auch die Arbeitsoberfläche (Desktop) für den Benutzer schneller zur Verfügung gestellt.
Es gibt aber Situationen, in denen Windows XP die Gruppenrichtlinien synchron verarbeitet, als die wären:
- Bei dem ersten Startvorgang eines Computers in der Domäne
- Bei der ersten Anmeldung eines Domänen-Users an einem Client
- Wenn der User (oder Computer) über synchron zu verarbeitende Skripte verfügt
- Wenn der User ein konfiguriertes Basisverzeichnis (Home-Laufwerk) besitzt
- Wenn der Benutzer über ein servergespeichertes Profil verfügt
Durch diese "scheinbar" Verbesserung kommt es aber desöfteren vor, dass dieses Verhalten eher als "störend" empfunden wird, wenn man sich z.B. anmeldet und findet keine Netzlaufwerke vor oder die Netzlaufwerke im Explorer erst nach und nach erscheinen etc.
Deshalb sollten diese beiden Richtlinien aktiviert werden, damit Windows XP die Gruppenrichtlinien während des Startvorgangs bzw. bei der Anmeldung des Benutzers synchron verarbeitet:
Computerkonfiguration/Administrative Vorlagen/System/Skripts\Anmeldeskripts gleichzeitig ausführen
Computerkonfiguration/Administrative Vorlagen/System/Anmeldung\Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten
Weitere Informationen:
Description of the Windows XP Professional Fast Logon Optimization feature
|
Copyright © 2013 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|