user217
Goto Top

AD mit Schuss?

Guten Morgen zusammen,

ich vermute einen Fehler in der ntds.dit Datenbank weil ich im gpoinventory.exe rsop Ergebnisse bekomme in denen Uralte gpos bei den Clients verarbeitet werden welche es schon lange nicht mehr gibt (Stehen da vielleicht alle jemals verarbeiteten drin?).
Diese Annahme bestätigt sich auch in der Praxis da Einstellungen angewendet werden, deren gpo gar nicht mehr existiert.
Außerdem habe ich hidden gpos gefunden welche auf keinem weg zu löschen waren nur ein OU Struktur Umbau mit Objekt verschieben hat dann geholfen. (Resultate per adsisearcher)

Hier ein paar Fakten:
- gpo Anzahl ist im sysvol/adsiedit/gpo.mmc konsistent und repl funktioniert fehlerfrei.
- ntdsutil (integrity & semantic database analysis) fehlerfrei
- 7016 Ereignisse auf den clients von cse's die unauffindbar sind.
- bei allen client gpo tests wurde vor dem gpresult /r der lokale policy Ordner sowie die security config gelöscht als auch das Ereignisprotokoll. gpresult /r zeigt keine alten gpo's an, was korrekt wirkt.
- In den gelöschten Objekte der AD sind diese Objekte auch nicht mehr vorhanden weil die 180 Tage Tombstone Lifetime bereits um sind.

Nun meine Frage zu der offensichtlich defekten Datenbank:
1. könnte ein offline defrag helfen?
2. Wie stehen die Chancen beim Einsatz von ESEUTIL? (werden die Fehler anschließend auch wieder repliziert? müssen beiden offline genommen werden?)
3. Hat jemand gute Erfahrungen mit einem 3rd party tool das die db online repariert?
4. Wo könnten noch Protokolle rumliegen die interessant wären?

PS: die Events sind sehr sauber, es deutet nichts weiter auf Probleme hin. Server & Client

Content-Key: 8037015693

Url: https://administrator.de/contentid/8037015693

Printed on: May 22, 2024 at 01:05 o'clock

Member: emeriks
emeriks Aug 03, 2023 updated at 06:50:16 (UTC)
Goto Top
Hi,
so so, Hidden GPOs. face-wink

Wenn ein Client eine GPO verarbeitet, welche es nicht mehr geben soll, dann kann das doch nur am Client liegen. Wenn jemand einen Befehl ausführt von einem Offizier, welcher bereits tot oder außer Dienst ist, dann ist die Ursache bei den Oberbefehlshabern? Bzw. bei den Büros, in denen diese amtieren?

Wenn ein Client GPO anwendet, dann kommen die Daten dafür irgendwoher: Entweder vom SYSVOL oder der Client hat diese Daten zwischengespeichert. Das GPO-Objekt im AD allein reicht dafür nicht aus. Normalerweise werden aber beim Löschen von GPO-Objekten aus dem AD auch die zugehörigen Dateien im SYSVOL ebenfalls gelöscht.

  1. Bist Du sicher, dass diese GPO nicht mehr existieren?
  2. Meinst Du stattdessen vielleicht, dass diese GPO Deiner Meinung nach nicht mehr angewendet werden dürften (aber noch existieren)?
  3. Es gibt einige Richtlinien aus den GPO, welche auch dann noch gelten, wenn die GPO nicht mehr gilt.
  4. Auch Einstellungen (bzw. deren Ergebnisse) aus den GPO gelten weiter, wenn eine GPO nicht mehr angewendet wird, es sei denn, man hat bei den einzelnen Einstellungen explizit angegeben, dass diese entfernt werden sollen, sobald es die GPO nicht mehr gilt.

Das "Aufräumen" oder "Reparieren" der ntds.dit würde dahingehend überhaupt nichts bringen.

E.
Member: user217
user217 Aug 03, 2023 at 07:45:12 (UTC)
Goto Top
Hi emeriks,

hidden GPO's, genau die..

Ich bin ganz deiner Meinung, GPO's werden vom Client gezogen und lokal ausgeführt, wenn die nicht da sind wird auch nix vom Server gezogen und ausgeführt. Soweit mein Kenntnisstand.

Ich bin der überzeugung das folgender Befehl alle Lokalen Settings löscht: (Bitte um Korrektur falls das falsch ist)
RD /S /Q "%WinDir%\System32\GroupPolicy" + Reboot  
gpupdate /force
gpresult /H c:\gpresult.html

1. Definitiv (sysvol, gpo Backup, gpoinventory, adsiedit haben alle die identische Anzahl)
2. Nein, leider nicht.
3. Aber doch nicht wenn man den lokalen gpo speicher gelöscht hat oder werden die noch irgendwo anders abgelegt?
4. Die lokalen gpos wurden doch gelöscht und am Server liegt nix.

Die ntds.dit habe ich auf allen dc's geprüft, sind "Clean" und "Konsistent". Lediglich auf einem DC konnte die Domäne bei einer Abfrage für die Usergruppe nicht gleich aufgelöst werden. Sonst alles nach Vorgabe.

Datenbankdienste stoppen
	net stop ntds /force
Status der Datenbank abfragen
	ESENTUTL /MH C:\Windows\NTDS\NTDS.DIT
Konsistenz der Datenbank abfragen
	ESENTUTL /K C:\Windows\NTDS\NTDS.DIT
Berechtigungen prüfen (SYSTEM" und "BUILDIN\Administrators" hier Vollzugriff (vererbt))  
	cacls c:\windows\ntds\
	cacls c:\windows\ntds\ntds.dit
	cacls c:\windows\ntds\*.*
Member: emeriks
emeriks Aug 03, 2023 updated at 08:24:30 (UTC)
Goto Top
Ich bin mir jetzt nicht sicher, ob wir von der selben Sache reden.

Am Rande: Das Tool gpoinventory.exe stammt aus einer Zeit gleich nach der letzten Sintflut. Auch wenn die aktuelle Release angeblich von 2023 ist. Es sieht immer noch so aus.

Punkt 4: Von lokalen GPO hatte ich gar nichts geschrieben?
Man muss unterscheiden zwischen
  • GPO (eine Gruppe von Richtlinien, später kamen die Einstellungen dazu)
  • Richtlinine (Bestandteil einer GPO)
  • Einstellung (Bestandteil einer GPO)

Das Löschen von irgendwelchen Dateien auf dem Client ändert doch nichts an den durch die GPO bereits bewirkten Werte in der Registry. Diese sind die eigentlich interessanten Punkte.

Also wenn Du da auf dem Client
  1. "%WinDir%\System32\GroupPolicy" löschst
  2. alle durch GPO bewirkten Werte aus der Registry löschst
  3. GPOs anwendest
sind dann durch die ehemals vorhandenen GPO bewirkten Werte wieder in der Registry?
  • Wenn ja: Überprüfe erst einmal, ob diese nicht doch durch andere GPO bewirkt werden.
  • Wenn nein: Dann ist doch alles gut?
Member: user217
user217 Aug 03, 2023 at 11:02:57 (UTC)
Goto Top
Zitat von @emeriks:
  1. alle durch GPO bewirkten Werte aus der Registry löschst


Ich denke es könnte daran mangeln.
Gibt es eine Möglichkeit alte gpos und deren gesetzte Änderungen in der Registry zu finden und zu löschen?
Oder gibt es evtl. scripts/toolz dafür?

Antworten wie "client neu installieren" würde ich nicht lustig finden..
Member: emeriks
emeriks Aug 03, 2023 at 11:12:41 (UTC)
Goto Top
Was HKCU betrifft, so könnte es reichen, mit einem neuen Benutzerprofil zu testen. Meinetwegen sogar mit einem neuen Benutzer, falls es Sinn macht.
Was HKLM betrifft, ist das nicht so einfach.
Die Werte einiger Richtlininen werden im HKLM\Software\Policies gespeichert.
Die anderer auch direkt irgendwo im HKLM\Software.
Einstellungen hingegen können überall im HKLM gelandet sein. Das hängt davon ab, was da konkret verteilt wurde.
Und dann nicht vergessen, dass die Einstellungen ja auch noch Ordner, Dateien, Drucker, Scheduled Task usw. verteilt haben könnten. Von daher wäre es schon keine schlechte Idee, wenigstens einen "nackten" Test-Client einzusetzen. Das könnte auch eine VM im selben Subnet sein.
Member: user217
user217 Aug 03, 2023 at 12:00:49 (UTC)
Goto Top
Übergibt die Automatik der gpo nicht irgendwo eine Eigenschaft welche im HKLM dadurch identifiziert und automatisiert werden könnte? woher hätte den sonst rsop die Information über uralt gpo's..
Oder reicht vielleicht ein regcleaner auch face-smile
Member: emeriks
emeriks Aug 03, 2023 at 12:15:20 (UTC)
Goto Top
Wenn Du mit den Standard-Tools von Windows RSOP am Client abfragst, dann werden dort nicht mehr existierende GPO als Quelle von Richtlinien oder Einstellungen genannt?

  • gpresult /h "%temp%\gpresult.html"
  • mmc.exe --> Snapin "Richtlinienergebnissatz"
Member: emeriks
emeriks Aug 03, 2023 at 12:17:34 (UTC)
Goto Top
In der Zeit, in der wir das hier diskutieren, hätte ich schon 12 Clients als VM aufgesetzt und getestet.
Member: user217
Solution user217 Aug 03, 2023 updated at 13:40:48 (UTC)
Goto Top
so, den ganzen Tag damit verschissen aber ich konnte es lösen und das Problem lag nicht am client!
Man kann mich für verrück erklären aber nach einem defrag der ntds.dit welche anschließend auf einem dc (vm ich sag immer dc muss auf blech) 20mb weniger hatte sind die komischen UR-alten gpos bei allen clients im rsop verschwunden hurra!

Und noch was, falls jemand mal so ein Problem haben sollte, es lohnt sich auch am client in den folgenden regkeys nachzusehen (löschen):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History

Lösung:

	wbadmin start backup -systemstate -backuptarget:\\smb\irgendeinordner -quiet
		net stop ntds /y
				ntdsutil
				activate instance ntds
				files
				Compact to c:\
				Integrity
				Quit
				Quit
			copy c:\ntds.dit c:\windows\NTDS\ntds.dit
			del c:\Windows\NTDS\*.log
		net start ntds


Danke an emeriks!

Wenn das nicht hilft, hiermit gehts auf die harte Tour.
Member: user217
user217 Aug 04, 2023 at 08:08:08 (UTC)
Goto Top
Man sollte anschließend dringend noch die beiden SYSVOL Verzeichnisse z.B. mit Beyond & Compare/robocopy händisch vergleichen. Besonders was die Berechtigungen angeht. Quasi DFSR manuell..
Member: Trommel
Trommel Aug 04, 2023 at 14:16:36 (UTC)
Goto Top
AD mit Schuss klingt nach einem guten Getränk für ITler face-wink

Schönes WE.

Trommel