5
Gruppenrichtlinie Vererbung bzw Auslesen
Hallo!
Ich habe folgende Problem und ich hoffe mir kann jemand schnell helfen.
Wir haben in unsrem Domain-Forest folgende Situation
Root-Domain
Sub-Domain
wir haben in der Sub-Domain eine GPO (Password) die den Kennwortwechsel nach 90 Tagen erzwingt (Computerkonfiguration - Windows-Einstellungen - Sicherheitseinstellungen - Kontorichtlinien - Kennwortrichtlinien)
Komplexität = deaktiviert
Kennwortchronik = 1
umgekehrte Verschlüsselung speichern = deaktiviert
max. Kennwortalter = 90
min. Kennwortlänge = 6
min. Kennwortalter = 0
dies ist eine eigene GPO und nicht eine Einstellung aus einer großen GPO bzw. von der DefaultDomainPolicy!
die DefaultDomainPolicy ist in der DomainStruktur nicht verknüpft und auch deaktiviert.
Es gibt in der Root-Domain eine GPO die ganz oben verknüpft ist - in diesem Fall ist das die DefaultDomainPolicy, bei der folgende Einstellung gesetzt ist:
Computerkonfiguration - Windows-Einstellungen - Sicherheitseinstellungen - Kontorichtlinien - Kennwortrichtlinien)
Komplexität = deaktiviert
Kennwortchronik = 24
umgekehrte Verschlüsselung speichern = deaktiviert
max. Kennwortalter = 42
min. Kennwortlänge = 7
min. Kennwortalter = 1
Jetzt die Fragen:
1. Welche Policy greift auf die User & Computer in der Subdomain?
Es gibt keine Vererbungsdeaktiverung auf der Sub-Domain.
Die Root-Domain beinhaltet keine User & Comuter - das Leben spielt sich in den Sub-Domains ab.
2. Wie kann ich auf einem PC auslesen, welche GPOs effektiv greifen?
Mit gpresult seh ich es zwar, aba da seh ich nicht ob was von einer übergeordneten Domain kommt, oder irre ich mich?
Warum ich das Frage?
Es soll in der Subdomain das Kennwort nach 90 Tagen geändert werden, doch User bei denen das Kennwort 28 Tage alt ist bzw älter, bei denen kommt jetzt bereits die Meldund dass das Kennwort in 14 Tagen oder kürzer, abläuft.
Warum? es soll doch erst nach 90 Tage geändert werden müssen.
Vielleicht kennt jemand ein Tool bei dem ich genau auslesen kann welche GPOs greifen bzw. vl. gibt es in der Registry einen Key wo ich mir das anschaun kann.
Hoffe ich konnte die Problematik klar und deutlich darstellen.
Ich habe folgende Problem und ich hoffe mir kann jemand schnell helfen.
Wir haben in unsrem Domain-Forest folgende Situation
Root-Domain
Sub-Domain
wir haben in der Sub-Domain eine GPO (Password) die den Kennwortwechsel nach 90 Tagen erzwingt (Computerkonfiguration - Windows-Einstellungen - Sicherheitseinstellungen - Kontorichtlinien - Kennwortrichtlinien)
Komplexität = deaktiviert
Kennwortchronik = 1
umgekehrte Verschlüsselung speichern = deaktiviert
max. Kennwortalter = 90
min. Kennwortlänge = 6
min. Kennwortalter = 0
dies ist eine eigene GPO und nicht eine Einstellung aus einer großen GPO bzw. von der DefaultDomainPolicy!
die DefaultDomainPolicy ist in der DomainStruktur nicht verknüpft und auch deaktiviert.
Es gibt in der Root-Domain eine GPO die ganz oben verknüpft ist - in diesem Fall ist das die DefaultDomainPolicy, bei der folgende Einstellung gesetzt ist:
Computerkonfiguration - Windows-Einstellungen - Sicherheitseinstellungen - Kontorichtlinien - Kennwortrichtlinien)
Komplexität = deaktiviert
Kennwortchronik = 24
umgekehrte Verschlüsselung speichern = deaktiviert
max. Kennwortalter = 42
min. Kennwortlänge = 7
min. Kennwortalter = 1
Jetzt die Fragen:
1. Welche Policy greift auf die User & Computer in der Subdomain?
Es gibt keine Vererbungsdeaktiverung auf der Sub-Domain.
Die Root-Domain beinhaltet keine User & Comuter - das Leben spielt sich in den Sub-Domains ab.
2. Wie kann ich auf einem PC auslesen, welche GPOs effektiv greifen?
Mit gpresult seh ich es zwar, aba da seh ich nicht ob was von einer übergeordneten Domain kommt, oder irre ich mich?
Warum ich das Frage?
Es soll in der Subdomain das Kennwort nach 90 Tagen geändert werden, doch User bei denen das Kennwort 28 Tage alt ist bzw älter, bei denen kommt jetzt bereits die Meldund dass das Kennwort in 14 Tagen oder kürzer, abläuft.
Warum? es soll doch erst nach 90 Tage geändert werden müssen.
Vielleicht kennt jemand ein Tool bei dem ich genau auslesen kann welche GPOs greifen bzw. vl. gibt es in der Registry einen Key wo ich mir das anschaun kann.
Hoffe ich konnte die Problematik klar und deutlich darstellen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 92705
Url: https://administrator.de/contentid/92705
Ausgedruckt am: 26.11.2024 um 02:11 Uhr
5 Kommentare
Neuester Kommentar
Moin Moin
Mit einen Richtlinien ergebnissatz im der GPMC.
Das wird Dir nicht nur angezeigt, welche GPOs greifen, sondern auch warum diese evtl. abgewisen wurden, sowie die Finalen einstellungen und aus welcher GPO diese kommen.
Gruß L.
1. Welche Policy greift auf die User & Computer in der Subdomain?
2. Wie kann ich auf einem PC auslesen, welche GPOs effektiv greifen?
2. Wie kann ich auf einem PC auslesen, welche GPOs effektiv greifen?
Mit einen Richtlinien ergebnissatz im der GPMC.
Das wird Dir nicht nur angezeigt, welche GPOs greifen, sondern auch warum diese evtl. abgewisen wurden, sowie die Finalen einstellungen und aus welcher GPO diese kommen.
Gruß L.
Hallo,
die Vererbung der GPO´s endet an der Domänengrenze. Alle GPO´s die mit der Strukturstammdomäne verknüpft wurden, haben keinen direkten Einfluss auf Benutzer/Computerkonten in untergeordneten Domänen. Es kann natürlich sein, das das GPO der übergeordneten Domäne auch mit einer OU oder der ganzen untergeordneten Domäne verknüpft wurde. Einstellungen zur Kennwortkomplexität, Gültigkeit usw. können immer nur einmal pro Domäne konfiguriert werden. Alle weiteren GPO´s mit Einstellungen dieser Art werden ignoriert.
Du kannst sehr genau herausfinden welche Einstellungen aus welchen GPO´s auf einem Computer wirken. Es gibt 3 Möglichkeiten:
1. Installiere wie von Logan000 beschrieben die GPMC (GroupPolicyManagementConsole) und füre dort einen Richtlinienergebnissatz im Planungsmodus in der untergeordneten Domäne mit den entsprechenden OU´s für Benutzer und Computer aus. Anschließend kannst du alle übernommenen Einstellungen und auswerten.
2. Starte auf einem Client die MMC (Start->Ausführen->MMC), füge das SnapIn "Richtlinienergebnissatz" hinzu (Datei->SnapIn Hinzufügen->Hinzufügen->Richtlinienergebnissatz). Anschließend die Daten sammeln indem du den Assistenten startest (rechtsklick auf Richtlinienergebnissatz -> ...satzdaten generieren) und alle Dialoge mit Weiter bestätigst. Nun kannst du alle Einstellungen auswerten.
3. starte von der Konsole das Tool gpresult.exe mit dem Parameter /v und leite die Ausgabe in eine Datei zur späteren Auswertung um
Das sollte aufschluss darüber geben welches GPO die Einstellungen verursacht.
die Vererbung der GPO´s endet an der Domänengrenze. Alle GPO´s die mit der Strukturstammdomäne verknüpft wurden, haben keinen direkten Einfluss auf Benutzer/Computerkonten in untergeordneten Domänen. Es kann natürlich sein, das das GPO der übergeordneten Domäne auch mit einer OU oder der ganzen untergeordneten Domäne verknüpft wurde. Einstellungen zur Kennwortkomplexität, Gültigkeit usw. können immer nur einmal pro Domäne konfiguriert werden. Alle weiteren GPO´s mit Einstellungen dieser Art werden ignoriert.
Du kannst sehr genau herausfinden welche Einstellungen aus welchen GPO´s auf einem Computer wirken. Es gibt 3 Möglichkeiten:
1. Installiere wie von Logan000 beschrieben die GPMC (GroupPolicyManagementConsole) und füre dort einen Richtlinienergebnissatz im Planungsmodus in der untergeordneten Domäne mit den entsprechenden OU´s für Benutzer und Computer aus. Anschließend kannst du alle übernommenen Einstellungen und auswerten.
2. Starte auf einem Client die MMC (Start->Ausführen->MMC), füge das SnapIn "Richtlinienergebnissatz" hinzu (Datei->SnapIn Hinzufügen->Hinzufügen->Richtlinienergebnissatz). Anschließend die Daten sammeln indem du den Assistenten startest (rechtsklick auf Richtlinienergebnissatz -> ...satzdaten generieren) und alle Dialoge mit Weiter bestätigst. Nun kannst du alle Einstellungen auswerten.
3. starte von der Konsole das Tool gpresult.exe mit dem Parameter /v und leite die Ausgabe in eine Datei zur späteren Auswertung um
gpresult /v > gpresult.txtDas sollte aufschluss darüber geben welches GPO die Einstellungen verursacht.
Hier die Erklärung:
Passwort-Richtlinien können nur in der Default Domain Policy vergeben werden. Auch wenn diese nicht verknüpft und/oder deaktiviert ist und es eine neue Richtlinie mit den Passwort-Einstellungen gibt, greift immer die Default Domain Policy.
Hier ein Microsoft Artikel dazu (ab Server 2008 ist das anders):
http://technet.microsoft.com/en-us/magazine/cc137749.aspx
Dies ist nur bei den Passwort-Einstellungen so, bei anderen Richtlinien gilt die normale GPO-Hierachie.
Wir haben jetzt in der Default Domain Policy die Passwort-Einstellungen gesetzt, wieder aktiviert und verknüpft, jetzt funktioniert es.
Passwort-Richtlinien können nur in der Default Domain Policy vergeben werden. Auch wenn diese nicht verknüpft und/oder deaktiviert ist und es eine neue Richtlinie mit den Passwort-Einstellungen gibt, greift immer die Default Domain Policy.
Hier ein Microsoft Artikel dazu (ab Server 2008 ist das anders):
http://technet.microsoft.com/en-us/magazine/cc137749.aspx
Dies ist nur bei den Passwort-Einstellungen so, bei anderen Richtlinien gilt die normale GPO-Hierachie.
Wir haben jetzt in der Default Domain Policy die Passwort-Einstellungen gesetzt, wieder aktiviert und verknüpft, jetzt funktioniert es.
Habe ich doch bereits geschrieben 
Zitat:
Naja, das das nur in der Default Domain Policy (DDP) gesetzt werden kann ist nicht ganz richtig. Das GPO, mit der höchsten Priorität und gesetzten PW-Settings wird übernommen. verknüpfst du zb. ein neues GPO mit der Domäne und änderst die Prio über die der DDP, ist dieses wirksam. Ich fasse die DDP eigentlich niemals an. Pasen die DDP GPO Einstellungen garnicht, deaktiviere ich es meistens. Das rücksetzen einer DDP in den Default-zustand ist somit jederzeit durch deaktivieren der nachträglichen GPO´s möglich. Damit lassen sich auch besser Änderungen dokumentieren.
Aso, bei 2k8-Domänen kannst du verschiedene Kennwortrichtlinien definieren. Bei 2k3-Domänen ginge das auch, wenn du das GPO auf Mitgliedsserver anwendest und alle anderen GPO´s für die OU dieses Servers deaktivierst. Zb. kannst du auf dem ISA-Server, der ja kein DC sein sollte, andere Kennworteinstellungen mitgeben. ich verwende diese "Hintertür" um einigen Client-Systemen, besonders Laptops, wesentlich schärfere Kennwortrichtlinien für die lokalen Benutzer-Accounts mitzugeben (um zb. zu verhindern, das lokale Accounts das PW des gleichnamigen Domänenbenutzers verwenden können).
Zitat:
Einstellungen zur Kennwortkomplexität, Gültigkeit usw. können immer nur einmal pro Domäne konfiguriert werden.
Naja, das das nur in der Default Domain Policy (DDP) gesetzt werden kann ist nicht ganz richtig. Das GPO, mit der höchsten Priorität und gesetzten PW-Settings wird übernommen. verknüpfst du zb. ein neues GPO mit der Domäne und änderst die Prio über die der DDP, ist dieses wirksam. Ich fasse die DDP eigentlich niemals an. Pasen die DDP GPO Einstellungen garnicht, deaktiviere ich es meistens. Das rücksetzen einer DDP in den Default-zustand ist somit jederzeit durch deaktivieren der nachträglichen GPO´s möglich. Damit lassen sich auch besser Änderungen dokumentieren.
Aso, bei 2k8-Domänen kannst du verschiedene Kennwortrichtlinien definieren. Bei 2k3-Domänen ginge das auch, wenn du das GPO auf Mitgliedsserver anwendest und alle anderen GPO´s für die OU dieses Servers deaktivierst. Zb. kannst du auf dem ISA-Server, der ja kein DC sein sollte, andere Kennworteinstellungen mitgeben. ich verwende diese "Hintertür" um einigen Client-Systemen, besonders Laptops, wesentlich schärfere Kennwortrichtlinien für die lokalen Benutzer-Accounts mitzugeben (um zb. zu verhindern, das lokale Accounts das PW des gleichnamigen Domänenbenutzers verwenden können).
Danke nochmals für eure Hilfe!
in meinem Fall (wie oben beschrieben) habe ich sogar die DDP deaktiviert (und natürlich auch nicht verknüpft). Und die DDP von der Root-Domain war auf 256 Tage eingestellt - testweise - um zu sehen von wo ich die 42 Tage bekomme. Die Priorität der Policys definiert sich doch in der Reihenfolge der Verknüpfung, wenn ich das richtig sehe. Da aber keine andere Policy (auch nicht die DDP) irgendwo mit Kennworteinstellungen verknüpft war, hab ich mich eben selbst gewundert warum meine neue Policy (Verknüpfungspriorität 1) nicht gegriffen hat.
Auch in greife die DDP normalerweise nicht an, aber eben wegen den Kennwort-Einstellungen musste ich das machen.
Habe auch einige andere Domains gecheckt und gesehen dass die Kennwort-Einstellungen immer in der DDP gesetzt wurden.
mfg
in meinem Fall (wie oben beschrieben) habe ich sogar die DDP deaktiviert (und natürlich auch nicht verknüpft). Und die DDP von der Root-Domain war auf 256 Tage eingestellt - testweise - um zu sehen von wo ich die 42 Tage bekomme. Die Priorität der Policys definiert sich doch in der Reihenfolge der Verknüpfung, wenn ich das richtig sehe. Da aber keine andere Policy (auch nicht die DDP) irgendwo mit Kennworteinstellungen verknüpft war, hab ich mich eben selbst gewundert warum meine neue Policy (Verknüpfungspriorität 1) nicht gegriffen hat.
Auch in greife die DDP normalerweise nicht an, aber eben wegen den Kennwort-Einstellungen musste ich das machen.
Habe auch einige andere Domains gecheckt und gesehen dass die Kennwort-Einstellungen immer in der DDP gesetzt wurden.
mfg
