Erklärungen, (Aus-)Wirkungen, Brainstorms, Hinweise, Tipps und Tricks, allgemein Wissenswertes
- ungeordnet –
Unterschiede Systemrichtlinien NT4 und Gruppenrichtlinien:
|
Systemrichtlinien |
Gruppenrichtlinien |
||
|
- |
werden nur auf Domänen-Ebene angewandt |
- |
können mit Standorten, Domänen und Ordnungseinheiten (OU = Organisation Unit) verknüpft werden
|
|
- |
Auswirkung auf Benutzer, Sicherheitsgruppen und Computer |
- |
Benutzer und Computer sind die einzigen Active Directory-Objekte die Richtlinien erhalten. Sie können nur scheinbar auf Sicherheitsgruppen durch Berechtigungsstrukturen auf diese angewendet werden
|
|
- |
Die Einstellungen werden permanent in im Benutzerprofil, bzw. Computersystem und damit letztlich in der Registry gespeichert. Es findet ein so genanntes Tattoing statt. Der Eintrag ist (wie ein Tattoo) erst mal für immer hinterlegt. Das Löschen der ntconfig.pol verändert absolut nichts an der Situation. Die Systemrichtlinien sind immer noch aktiv, da sie in der Registry des jeweiligen Objekts eingetragen sind. |
- |
Durch das Löschen (oder Ungültigkeit) des Gruppenrichtlinien-Objektes werden automatisch 2 Schlüssel aus der Registry in HKLM und HKCU gelöscht: - \Software\Policies - \Software\Microsoft\Windows\CurrentVersion\Policies Es findet also kein Tattoing statt.
Nur diese Schlüssel werden gelöscht. Eigene ADM Templates sind weiterhin gültig, da sie in der Regel nicht in diesen Schlüssel hinterlegt sind.
Eine Unterscheidung zwischen permanenten (tattoing) und nicht permanenten Richtlinien ist optisch leicht zu treffen. - nicht permanente Policies werden „blau“ dargestellt - Permante Richtlinien sind „rot“
|
|
- |
Gelten als unsicher. Jeder Benutzer mit Zugriff auf die Registry kann diese editieren und evtl. die gesetzten Richtlinien per Hand entfernen. Das muss dann zwar pro Sitzung erfolgen, wäre aber eine Möglichkeit. |
- |
Gruppenichtlinien gelten im Gegensatz zu Systemrichtlinien als sicher, da die oben genannten Schlüssel schon per Default mit Berechtigungen ausgestattet sind. Selbst in HKCU, wo der User normalerweise Vollzugriff hat, sind obige Schlüssel nur für Administratoren mit „ändern“ Rechten ausgestattet. Ist der User kein lokaler Administrator, hat er an diesen Einträgen nur „lesen“ Rechte. |
Bedeutung von Konfiguriert, Nicht konfiguriert und Deaktiviert
|
Nicht konfiguriert |
Die aktuelle Einstellung wird nicht verändert. Dieses kann 2 Bedeutungen haben. An oberster Hierarchie Ebene kann mit dieser Einstellung nichts schief gehen, da es die Default Konfiguration darstellt. In einem tieferen GPO Objekt bedeutet es aber auch die Übernahme der übergeordneten Richtlinien Einstellung, denn die aktuelle Einstellung wird nicht übertschrieben
|
|
Aktiviert / Deaktiviert |
Fast
selbsterklärend, jedenfalls, was die Aussage ansich betrifft. |
Computer oder Benutzerkonfiguration:
Stehen 2 widersprüchliche Richtlinien im Konflikt, so setzt sich die Computerbezogene Einstellung durch.
Richtlinien kommen in folgender Reihenfolge zur Anwendung:
- Lokale Richtlinie
o Standortrichtlinien
§ Domänenrichtlinien
· OU-Richtlinien von der übergeordneten OU zur untergeordneten.
Wie verhalten sich in diesem Schema die Poledit-Systemrichtlinien und/oder lokal gesetzte Gruppenrichtlinien per gpedit.msc? Wie man der oberen Darstellung entnehmen kann, werden die Lokalen Richtlinien für ein System ausgewertet und eingelesen. Dabei unterscheiden sie sich aber in der Auswirkung und im Verhalten, bzgl. der Lokalen Benutzerkonten und Domänen Benutzer.
Poledit:
Einstellungen in der *.pol Datei, die für ein lokales System per "Update" und "NetworkPath" in der Registry definiert wurden, werden nur von lokalen Benutzerkonten angewendet. Bei der Anmeldung eines Domänenbenutzers ist keine der hinterlegten Einstellungen wirksam. (Gutes Beispiel: Desktop Symbole ausblenden).
Eine ntconfig.pol im NETLOGON wird komplett ignoriert.
GPEdit:
Einstellungen die über den lokalen Gruppenrichtlinieneditor gesetzt sind gelten für alle Benutzer an diesem System. Sowohl für Lokale Benutzerkonten, als auch für die Domänen Benutzer. Ist in der dort hinterlegten *.pol Datei die Richtlinie "Desktop Symbole ausblenden" gesetzt, so werden diese bei keinem Benutzer angezeigt, da diese Einstellungen unter normalen Bedingungen in der Richtlinie auf Domänen/OU Ebene "Nicht konfiguriert" ist.
Sind an eines dieser Objekte mehrere Richtlinien gebunden, so können diese in ihrer hierarchischen Struktur vom Administrator sortiert werden. Sie können im Eigenschaftsfenster „nach oben“, bzw. „nach unten“ sortiert werden und somit kann für diese Richtlinien die Priorität und die damit verbundene Reihenfolge der Anwendung festgelegt werden.
Die standardisierte Reihenfolge der Richtlinien kann durch 2, in der deutschen Übersetzung absolut unglücklich gewählten, Optionen beeinflusst werden => „Kein Vorrang“ und „Vererbung Deaktiviert“.
An dieser Stelle ist wieder jedem Empfohlen auf ein englisches Buch auszuweichen. Denn in diesem Fall sind die im Orginal verwendeten Ausdrücke absolut klar in ihrer Bedeutung.
|
"Kein Vorrang" vs. "No Override" |
Wenn eine Richtlinie "keinen Vorrang" hat, dann wird sie wörtlich gesehen, eine vorhandene Einstellung nicht überschreiben, aber genau das Gegenteil ist der Fall. Die Richtlinie steht auf NO OVERRIDE, sie kann nicht von den ihr folgenden Richtlinien überschrieben werden.
|
|
"Vererbung Deaktivieren" – vs. "Block Inheritance" |
Es wird nicht die von ihr ausgehende Vererbung deaktiviert, sondern die darüber liegende Richtlinieneinstellung wird nicht geerbt. Sie wird "blockiert" => BLOCK INHERITANCE
|
Wichtige Regeln dazu:
Hat mehr als eine GPO die Option „Kein Vorrang“ aktiviert, so setzt sich die im Active Directory hierarchisch höchste durch. Sind diese GPO-Objekte auf gleicher Ebene so, setzt sich die mit der höchsten Priorität durch.
Über die Option „Vererbung Deaktivieren“ kann eine Übernahme der übergeordneten Einstellungen verhindert werden. Mit einer Einschränkung: Ist bei dem hierarchisch übergeordneten Objekt „Kein Vorrang“ (NO OVERRIDE) aktiviert, so kann die Vererbung nicht verhindert werden. Somit kann sich der Domänen-Administrator mit seinen Einstellungen immer durchsetzen J
Der lokalen Sicherheitsrichtlinien kommt in einer Domäne genau betrachtet nur so viel Bedeutung zu, wie der Domänen-Administrator dies zulässt. Denn die lokalen Einstellungen werden von entgegenstehenden Einstellungen in den Richtlinien der Domäne „überstimmt“. Das heißt, dass Alles, was der Domänenadmin einstellt auch übernommen wird und dass dieses durch die lokale Sicherheitsrichtlinie nicht geändert werden kann. Nur das, was der Domänen-Administrator nicht konfiguriert kann lokal verändert werden.
Die lokale Sicherheitsrichtlinie ist nur dann uneingeschränkt wirksam, wenn sich der Computer innerhalb einer Arbeitsgruppe befindet. Sobald der Rechner ein Domänenmitglied ist werden die lokalen Sicherheitsrichtlinien von denen der Domäne überstimmt (wie gerade beschrieben).
Eine weitere Sonderstellung innerhalb der möglichen Einstellung nehmen die Kennwortrichtlinien ein. Jede Domäne hat genau eine Kontorichtlinie (i.d.R. Default Domain Policy). Die Einstellungen der Domänenrichtlinie gelten für die Domäne und damit für alle Domänenkonten. Es nicht möglich für die Nutzer in verschiedenen OUs unterschiedliche Kennwortrichtlinien (z.B.: Länge und Gültigkeit des Passwortes) einzustellen. Dieses ist nur pro Domäne möglich. Die Einstellung innerhalb einer OU wird nur von den Computerobjekten der OU übernommen (nicht von der Domäne) und wirken sich damit nur auf die jeweiligen lokalen Benutzerkonten aus.
Privater Kommentar zum Thema:
Genau genommen würde es auch keinen Sinn ergeben, denn dann würde irgendein „ganz wichtiger“ Abteilungsleiter mit extrem ungesunden, profunden Halbwissen für seine Abteilung darauf bestehen, dass bei „ihm“ die Passwortlänge mit 3 Buchstaben genügen würde … *lol* Keine Chance. Der Admin legt die Richtlinie ja genau deswegen für alle verbindlich fest, damit eben nicht jeder sein eigenes Süppchen kochen kann.
Einige Beispiele zum Verständnis:
|
Domäne |_ OU, darin Benutzer Willi
|
Destop-Icons werden ausgeblendet
In der OU „Nicht konfiguriert“ |
Normale Vererbung:
Willi hat keine Desktop Icons |
|
Domäne |_ OU, mit Willi |
Destop-Icons werden ausgeblendet
In der OU „Nicht konfiguriert“ mit der Option „Vererbung Deaktivieren“
|
Willi hat Desktop Icons |
|
Domäne | |_ OU, mit Willi |
Desktop-Icons werden ausgeblendet, GPO steht auf „Kein Vorrang“
In der OU „Nicht konfiguriert“ mit der Option „Vererbung Deaktivieren“
|
Willi hat keine Desktop Icons |
|
Domäne |_ OU, mit Willi |
Desktop-Icons „Nicht konfiguriert“
In der OU „Aktiviert“ |
Willi hat keine Desktop Icons
|
|
Domäne |_ OU, mit Willi |
Desktop-Icons werden ausgeblendet
In der OU „Deaktiviert“ |
Willi hat Desktop Icons
|
|
Domäne | |_ OU, mit Willi |
Desktop-Icons werden ausgeblendet mit der Option „Kein Vorrang“
In der OU „Deaktiviert“ |
Willi hat keine Desktop Icons |
Speicherort und Dateiablage der Gruppenrichtlinien:
Sobald ein Server zum Domänen Controller promotet wird, hält er auch die Informationen des Active Directory. Sämtliche Informationen die die Domäne betreffen werden im SYSVOL hinterlegt.
Die erstellten Gruppenrichtlinien werden im SYSVOL der Domäne hinterlegt. Sie können durch ihre GUID (Global Unique Identifier) unterschieden werden. Ihr werdet in dieser Ordnerstruktur keine „Namen“ wieder finden, die ihr für die Richtlinie vergeben habt. Die Zuordnung der einzelnen Ordner und damit der Richtlinien gestaltet sich deswegen ein wenig umständlich.
Über die Eigenschaften der Richtlinie ist eine genaue Zuordnung möglich.
Diese GUID findet sich dann hier in der Ordnerhierarchie wieder:
%systemroot%
-
SYSVOL
o SYSVOL
§
diedomain.tld
·
policies
·
{31B2F340-016D-11D2-945F-00C04FB984F9}
|
§ |
adm |
die verwendeten ADM Templates dieser Richtlinie |
|
§ |
MACHINE |
die Einstellungen die den Computer betreffen |
|
§ |
USER |
die Einstellungen die den Benutzer betreffen |
· scripts = NETLOGON
Dieser Ordner Scripts ist eure Freigabe NETLOGON, die ihr bei NT4 unter %systemroot%\system32\repl\import\scripts gefunden habt. Diese Freigabe wird immer noch benötigt um Richtlinien für NT4/9x Clients zu hinterlegen, Anmeldescripts, die im Benutzermanager definiert sind (somit hauptsächlich für NT4/9x Clients) und ist die allgemeine Anmelderessource, über die der Server für diese Clients kontaktiert wird.
|
adm |
|
hier sind die genutzten ADM Templates der Richtlinie hinterlegt. Wird ein Template importiert (egal aus welchem Pfad) so landet eine Kopie der Datei in diesem Ordner und diese *.adm Datei ist dann die aktive ausschlagegebende. Sollen Änderungen am Template erfolgen, so müssen sie an dieser Datei vorgenommer werden, oder das geänderte Template muss erneut importiert werden.
|
|
MACHINE |
|
Computerkonfiguration
|
|
|
Applikations |
Hier landen die *.aas Dateien in denen die Anweisungen für die zugewiesenen Software Pakete hinterlegt sind.
|
|
|
Microsoft\ - Windows NT\ - SecEdit |
Speicherort der GptTmpl.inf, die Vorlage der aktuell eingesetzten Sicherheitsrichtlinie. Wenn die der DefDomPol gelöscht worden ist oder korrupt ist, kann über folgenden Weg die Grundeinstellung wieder hergestellt werden. http://support.microsoft.com/?kbid=267553
|
|
|
Scripts\ - Startup\ - Shutdown\ |
Computerspezifische An- (Startup) und Abmelde Scripts (Shutdown). Auch hier gilt eine an NT4 erinnernde Regel: In der Richtlinie wird KEIN Pfad angegeben, sondern nur der Name des Scripts. Das Script wird im Scripts\Startup oder Scripts\Shutdown Ordner ERWARTET.
|
|
|
Registry.pol
|
Vergleichbar mit der ntconfig.pol, bzw. config.pol. In dieser Datei liegen die eigentlichen Regsitry-Einträge, die für das Objekt mit Systemberechtigen eingetragen werden.
|
|
USER |
|
Benutzerkonfiguration
|
|
|
Applikations |
Siehe Computerkonfiguration
|
|
|
Documents & Settings
|
Speicherort der fdeploy.ini in der u.A. der Status der Ordnerumleitungen hinterlegt ist.
|
|
|
Remoteinstall
|
Speicherort der OSCfilter.ini (nicht unbedingt vorhanden), hält Informationen für die RIS Installation bereit.
|
|
|
Microsoft\ - IEAK |
Ist der Voreinstellungsmodus für den InternetExplorer gewählt, dann befinden sich in diesem Ordner die Informationen
|
|
|
Scripts\ - Logon - Logoff
|
Siehe Computerkonfiguration. Verhält sich ähnlich dem NETLOGON. Das Script wird nur per Namen angegeben und an diesem Speicherort ERWARTET. |
|
|
Registry.pol
|
Siehe Computerkonfiguration
|
|
GPT.ini
|
|
In der GPT.ini wird u.A. die Versionsnummer der Richtlinie gespeichert, anhand derer der Client unterscheidet, ob die Richtlinie erneut angewendet werden muss.
Version=XXXXX ist ein Dword Eintrag, der dezimal dargestellt wird.
Beispiel: Zu lesen ist er als Dword: 65539 = 0X00010003 0001 = Versionsnummer des Benutzerobjektes (erste Version) 0003 = 3 Version des Computerobjekts, d.h. es wurden schon mehrmals (3x) Änderungen an der Computerrichtlinie vorgenommen.
|
|
„Group Policy Storage, Non-Local, Active
Directory–Based Storage” |
||
(c) 2003 - heute, Mark Heitbrink,
weitere Informationen unter WebSite-Info\Copyright