Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Gruppenrichtlinien
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: 0011101010010
 
 Sunday, October 05, 2008

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.
Dazu ist folgendes zu tun:

  • 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).

Sunday, October 05, 2008 8:44:31 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Gruppenrichtlinien  | 
 Sunday, September 23, 2007

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

Sunday, September 23, 2007 10:49:02 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | Objektverwaltung | Gruppenrichtlinien  | 
 Sunday, November 19, 2006


Den Dateizugriff auf einem NTFS formatierten Datenträger kann man mit Windows-Boardmitteln überwachen.
Der Einsatz dieser Funktion sollte aber gut durchdacht sein, denn
 

  1. ist diese Einstellung vom Betriebsrat zu genehmigen bzw. ist Mitbestimmungspflichtig und
  2. 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.

Sunday, November 19, 2006 10:32:49 AM (W. Europe Standard Time, UTC+01:00)  #      Gruppenrichtlinien  | 
 Sunday, November 12, 2006

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

 

Sunday, November 12, 2006 1:46:51 PM (W. Europe Standard Time, UTC+01:00)  #      Gruppenrichtlinien  | 
 Tuesday, September 26, 2006

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\winre­g"
das Konto "LOKALER DIENST" als Leseberechtigten einzutragen und anschließend muss der Server neu gestartet werden.

 

Tuesday, September 26, 2006 9:07:39 PM (W. Europe Standard Time, UTC+01:00)  #      Gruppenrichtlinien  | 
 Friday, September 15, 2006

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

 

Friday, September 15, 2006 12:00:22 PM (W. Europe Standard Time, UTC+01:00)  #      Gruppenrichtlinien  | 
 Monday, August 07, 2006

Wenn man Probleme mit den Standard-Gruppenrichtlinien hat (unter Windows Server 2003), kann man einiges mit dem Befehl "DCGPOFIX" wieder reparieren.

Mit diesem Befehl werden die beiden GPOs "Default Domain Policy" sowie "Default Domain Controllers Policy" in ihren Ursprungszustand versetzt, sprich, in die "Werkseinstellung". Genauer, DCGPOFIX setzt die Berechtigungen innerhalb des AD zurück.

 

Existiert ein Exchange im Netzwerk, kann es (oder wird es) nach ausführen von DCGPOFIX Probleme mit Exchange geben.

Daher ist es notwendig das Exchangesetup mit /DOMAINPREP nach DCGPOFIX erneut aufzurufen.

Siehe dazu folgenden Artikel:

The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state


Führt man den Befehl auf einem Windows Server 2003 R2 Domänencontroller aus, kommt es zu folgender Fehlermeldung:

 





Stattdessen muss DCGPOFIX mit dem Parameter "ignoreschema" ausgeführt werden:
dcgpofix.exe /ignoreschema.


Error message when you use the Dcgpofix.exe command-line tool in a Windows Server 2003 R2-based domain: "Active Directory schema version for this domain, and the version supported by this tool do not match"

Monday, August 07, 2006 3:25:25 PM (W. Europe Standard Time, UTC+01:00)  #      Gruppenrichtlinien  | 
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: