Kennwortrichtlinienänderung greift nicht?

[Disceptator 10]

Zur Zeit der Richtlinieneinstellungsanwendung muss es dann auch einen korrespondierenden Eventeintrag geben, welcher ist das und was steht da drin ?

Hast Du mal geschaut, ob die Richtlinienvererbung auf der Domain Controllers OU deaktiviert wurde ?

Sehe keinerlei Logeinträge, weder positiv noch negativ.

Richtlinienvererbung auf die CD OU ist aktiv

[olc 18]

Hi,

 

einmal abgesehen von den RSOP "Problemen" (BTW: Ich meinte den GPMC HTML Report, aber das tut nichts zur Sache): Hast Du die anderen Punkte aus https://www.mcseboard.de/post23-872667.html ebenfalls geprüft?

 

Richtlinienvererbung auf die CD OU ist aktiv

 

D.h. es ist keine Verweigerung eingerichtet und auch die Sicherheitsberechtigungen auf der Default Domain Policy nicht verändert worden, ja?

 

Viele Grüße

olc

[Disceptator 10]

Hi,

 

einmal abgesehen von den RSOP "Problemen" (BTW: Ich meinte den GPMC HTML Report, aber das tut nichts zur Sache): Hast Du die anderen Punkte aus https://www.mcseboard.de/post23-872667.html ebenfalls geprüft?

 

 

 

D.h. es ist keine Verweigerung eingerichtet und auch die Sicherheitsberechtigungen auf der Default Domain Policy nicht verändert worden, ja?

 

Viele Grüße

olc

 

Die Vererbung ist aktiv = kein Häkchen

In dem NC Head stehen die fehlerhaften Werte drin. (Also nicht die die wir eingestellt haben, sondern die alten Werte)

Genau das ist ja das Problem :(.

Änderungen geschehen über defaulf Domain Policy.

 

 

Die esentutl /g %windir%\security\database\secedit.sdb -> Datenbank ist ok.

[olc 18]

Hi,

 

Die Vererbung ist aktiv = kein Häkchen

 

Ok, um zu verifizieren, aus welcher Policy die DCs die auf Ihnen aktive Kennwortrichtlinie bekommen, ziehe bitte trotzdem noch einen GPMC HTML Report und schaue, ob die Settings von der Default Domain Policy kommen oder einer anderen. Bitte für alle drei DCs prüfen.

Im SYSVOL scheinen ja die korrekten Policies zu liegen, sonst würden die Benutzer nicht die korrekten Richtlinien bekommen. Vielleicht kannst Du das ja noch einmal in der GptTmpl.inf der Default Domain Policy ( {31B...} prüfen (auf allen drei DCs).

 

In dem NC Head stehen die fehlerhaften Werte drin. (Also nicht die die wir eingestellt haben, sondern die alten Werte)

Genau das ist ja das Problem :(.

 

Ja, das wissen wir jetzt. Damit ist das Problem zumindest eingegrenzt. Ich würde also vorschlagen sich auf den PDC zu konzentrieren, denn der schreibt die Einträge in den NC Head. Hast Du Dich mit LDP o.ä. beim Auslesen des NC Heads auf den PDC verbunden oder einen anderen DC? Versuch es bitte einmal konkret mit dem PDC.

 

Die esentutl /g %windir%\security\database\secedit.sdb -> Datenbank ist ok.

 

Daß die Datenbank strukturell in Ordnung ist sagt nichts darüber aus, ob sie auch inhaltlich paßt. Ich würde daher wie beschrieben (sollten nicht manuell Einstellungen in der lokalen Gruppenrichtlinie des PDCs eingestellt worden sein) die im Link genannten Dateien zumindest auf dem PDC trotzdem einmal löschen und den PDC einmal neu starten.

 

Du hast oben geschrieben, daß keine Meldungen im Ereignisprotokoll zu finden waren - wenn im Anwendungs-Ereignisprotokoll auch keine Informational Meldungen mit Quelle SCECLI zu finden sind, dann solltest Du wie beschrieben vor dem Neustart auch einmal die "scecli.dll" neu registrieren.

 

[EDIT] Achso - die Frage, ob andere Einstellungen in den Security Settings der Default Domain Policy testweise greifen, wäre auch noch offen. ;) [/EDIT]

 

Viele Grüße

olc

[grizzly999 11]

Ok, um zu verifizieren, aus welcher Policy die DCs die auf Ihnen aktive Kennwortrichtlinie bekommen, ziehe bitte trotzdem noch einen GPMC HTML Report

 

Hey, mein Anliegen aus Beitrag #18 :jau:

Nachdem das bisher nicht möglich war, wer weiß, ob das jetzt was werden würde könnte hätte sollte :p

 

 

grizzly999

[olc 18]

Off-Topic:
Ja, da hast Du Recht. Aber zu meiner Entschuldigung sei gesagt, daß ich erst später in den Thread eingestiegen bin und auch diesen Punkt in dem ersten Beitrag von mir aufgenommen hatte. :)

Ist manchmal erschreckend, wie viel zwischendrin auf der Strecke bleibt, was hätte die Lösung sein können. ;)

Aber in diesem Fall denke ich nicht, daß das der Fall ist. Schließlich greifen die Policies ja "auf den Clients", was "auf den DCs" bedeutet.

Viele Grüße
olc

[Disceptator 10]

Also hier alles gesammelt :)

 

{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

 

DC1 (Exchange) -> auch der PDC emulator

 

[system Access]

MinimumPasswordAge = 0

MaximumPasswordAge = 56

MinimumPasswordLength = 6

PasswordComplexity = 1

LockoutBadCount = 0

RequireLogonToChangePassword = 0

ForceLogoffWhenHourExpire = 0

 

DC2 (Fileserver)

 

[system Access]

MinimumPasswordAge = 0

MaximumPasswordAge = 56

MinimumPasswordLength = 6

PasswordComplexity = 1

LockoutBadCount = 0

RequireLogonToChangePassword = 0

ForceLogoffWhenHourExpire = 0

 

DC3 (Aussenstelle)

 

[system Access]

MinimumPasswordAge = 0

MaximumPasswordAge = 56

MinimumPasswordLength = 6

PasswordComplexity = 1

LockoutBadCount = 0

RequireLogonToChangePassword = 0

ForceLogoffWhenHourExpire = 0

 

Soweit die Einstellungen.

 

 

• Als Zip der GPMC HTML Report der default domain policy.(Ist auf allen DCs gleich)

• Nc HEad hat die alten Einstellungen. War mit dem PDC verbunden. Hierzu eine Frage, reicht es vielelicht aus die Werte dort zu editieren? Was kann ich mir damit kaputtmachen? Naja, die gesamte Domäne :/

• Testweise änderungen von default domain policy funktionieren.

• Das mit der SCECLI löschung steht aus.

 

 

Hoffe hab nun alles beisammen :)

[olc 18]

Hi,

 

Also hier alles gesammelt :)

 

Na ja, nicht wirklich. ;)

 

{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

 

Wurden in der Zwischenzeit die Password Policies wieder geändert? Im Screenshot oben wurden 50 Tage minimales Kennwortalter angegeben. In dem Export der *.inf Datei steht der Wert auf 56.

 

Als Zip der GPMC HTML Report der default domain policy.(Ist auf allen DCs gleich)

 

Hier war zumindest nichts angehangen. Aber die Daten wären auch wahrschienlich nicht die korrekten - wir meinten nicht die Policy selbst, sondern einen RSOP Report, also die Group Policy Results ganz unten in der GPMC, siehe Resultant set of policy overview for GPMC: Group Policy .

Du mußt das hier aber auch nicht posten - Du sollst im Grunde nur prüfen, von welcher Policy die Einstellungen geschrieben werden. Dies findest Du rechts neben der entsprechenden Einstellung in diesem besagten GPMC Report.

 

Nc HEad hat die alten Einstellungen. War mit dem PDC verbunden. Hierzu eine Frage, reicht es vielelicht aus die Werte dort zu editieren? Was kann ich mir damit kaputtmachen? Naja, die gesamte Domäne :/

 

Ja, Du kannst damit etwas kaputt machen. ;)

Also bitte nicht manuell anpassen.

 

Testweise änderungen von default domain policy funktionieren.

 

Die Änderungen hast Du wie oben beschrieben auch in den Sicherheitseinstellungen vorgenommen, also etwa die Anmelderechte (log on locally) geändert o.ä.?

 

Das mit der SCECLI löschung steht aus.

 

Wenn die Änderungen von Test-Sicherheitseinstellungen wirklich greifen, ist das unnötig. Die Datenbank löschen und wieder neu anlegen könnte jedoch ggf. trotzdem Sinn machen.

 

Viele Grüße

olc

[Disceptator 10]

Wurden in der Zwischenzeit die Password Policies wieder geändert? Im Screenshot oben wurden 50 Tage minimales Kennwortalter angegeben. In dem Export der *.inf Datei steht der Wert auf 56.

 

Ja sie wurden geändert. sorry, hab vergessen das zu erwähnen.

 

Hier war zumindest nichts angehangen. Aber die Daten wären auch wahrschienlich nicht die korrekten - wir meinten nicht die Policy selbst, sondern einen RSOP Report, also die Group Policy Results ganz unten in der GPMC, siehe Resultant set of policy overview for GPMC: Group Policy .

Du mußt das hier aber auch nicht posten - Du sollst im Grunde nur prüfen, von welcher Policy die Einstellungen geschrieben werden. Dies findest Du rechts neben der entsprechenden Einstellung in diesem besagten GPMC Report.

 

Die gegenüberstellung von den Einstellungen und den Results habe ich bereits gepostet. Hier ist sie nochmal mit den jetzigen Einstellungen:

 

Ja, Du kannst damit etwas kaputt machen. ;)

Also bitte nicht manuell anpassen.

ok, wäre ja vielelicht auch eine Möglichkeit gewesen.

 

Die Änderungen hast Du wie oben beschrieben auch in den Sicherheitseinstellungen vorgenommen, also etwa die Anmelderechte (log on locally) geändert o.ä.?

 

Nein nicht in den Sicherheitseinstellungen. Habe nur die Funktionalität der default domain policy getestet, ob die Änderungen übernommen werden.

Aber Audit Einstellungen greifen ebenso wenig. Es scheint, dass der ganze Block - Sicherheit betroffen ist. :mad:

 

Vielen Dank für die Hilfe und Anregungen bisher :)

[olc 18]

Hi,

 

Die gegenüberstellung von den Einstellungen und den Results habe ich bereits gepostet. Hier ist sie nochmal mit den jetzigen Einstellungen:

 

Ok, die Einstellungen kommen also zumindest laut RSOP direkt von der Default Domain Policy.

 

Nein nicht in den Sicherheitseinstellungen. Habe nur die Funktionalität der default domain policy getestet, ob die Änderungen übernommen werden.

Aber Audit Einstellungen greifen ebenso wenig. Es scheint, dass der ganze Block - Sicherheit betroffen ist. :mad:

 

Ok, das ist doch einmal ein Ansatz. Ich würde also (wie teilweise oben schon erwähnt) zwei Dinge probieren:

 

1. Eine neue Policy anlegen (etwa auch Domain Controller OU Ebene) und dort eine Sicherheitseinstellung vornehmen, etwa eine von Dir genannte Überwachungsrichtlinie - keine anderen Einstellungen. Dann solltest Du in der GPMC die Priorität dieser GPO auf 1 stellen, also höchste Priorität.

Greift diese Einstellung nach einem GPUPDATE /FORCE auf den DCs? Ggf. laß den Einstellungen ein wenig Zeit for dem GPUPDATE und RSOP, damit diese ggf. repliziert werden können.

 

2. Greifen diese Einstellungen nicht würde ich persönlich wie angesprochen die lokale Sicherheitsdatenbank + Logs löschen, die scecli.dll neu registrieren und die DCs nacheinander neu starten.

Ggf. solltest Du vorher prüfen, ob in der lokalen Sicherheitsrichtlinie Einstellungen vorgenommen wurden, da diese beim Löschen der *.sdb + *.edb Dateien verloren gehen. Die anderen Einstellungen sollten durch die GPOs wieder angewendet werden.

Es macht vielleicht Sinn einen DC nach dem anderen zu machen um zu prüfen, ob nach den Aktionen überhaupt noch Sicherheitseinstellungen geschrieben werden. Wenn gar keine Einstellungen mehr ankommen, dann solltest Du die anderen DCs vielleicht nicht anfassen.

 

Abwegungsfrage. ;)

 

Viele Grüße

olc

[Disceptator 10]

So werden dann jetzt weekend mal die db löschen + secedit.dll neu registrieren. Mal lesen was da alles so passieren kann und wie man Probleme von vorneherein ausschliessen kann.

Testen wir mal zuert mit einem Dc dem wir alle FSMO Rollen übertragen.

+ Test wie olc es vorgeschlagen hat.

Die beiden anderen dc bleiben für die zeit aus.

 

Getestet die Einstellungen für die Sicherheitsoption:

Änderungen in anderen Sicherheitseinstellungen (Ereignissprotokoll) wurden auf den clients übernommen (aber nicht aktiv) auf dem DCs sind witerhin die alten werte zu sehen, die wir nicht in der Lage sind zu ändern (NcHead Werte).

[Disceptator 10]

Es kamen paar Sachen dazwischen.

 

Hab das wie von olc beschrieben gemacht - keine Wirkung.

 

Hab es noch etwas weiter getestet - Alle FSMO Rollen auf einem Server (sie waren davor verteilt) um dort die Richtlinienänderung durchzuführen.

 

Nach der Replikation griff die Richtlinie... Und zwar so wie es von uns gewünscht wurde.

 

Warum das aber vorher nicht funktioniert hat ist mir ein Rätsel.

[olc 18]

Hi,

 

die Erklärung findest Du in dem oben geposteten Link zum Verhalten der Password Policy und dem Domain NC Head: Wenn der PDC diese Daten nicht aktualisiert, läufst Du in das Problem. Aber an diesem Punkt waren wir doch meines Erachtens schon bzw. wir haben das Thema schon angesprochen gehabt. ;)

 

Von daher wäre also zu prüfen, welches Problem der PDC hatte, wenn auch das Löschen der lokalen Sicherheitsdatenbank als auch die Neuregistrierung der entsprechenden DLLs nichts brachte. Unter Umständen war das SYSVOL, auf das der DC zugegriffen hat (muß nicht zwangsweise sein eigenens sein), nicht aktuell? Obwohl - ich glaube auch das hattest Du geprüft oder?

 

Na ja, wie auch immer. Wenn Du dazu spontan nichts mehr finden kannst, dann bleibt es wohl ein "Mysterium". ;)

 

Danke für Deine Rückmeldung und Gruß

olc