6
Überwachung eines Reg-Schlüssels
Hallo,
unter "Überwachung" eines Reg-Schlüssels (im Falle z. B. HKCU\Control Panel\Keyboard\) wurde die relevanten Überwachungseinträge hinzugefügt und zwar nur mit der Zugriffsberechtigung "Wert festlegen", da nur diese für das Projekt relevant ist (d. h. für alle diejenigen Gruppen/Konten, welche unter "Berechtigungen" standardmäßig eh vorhanden sind und die Zugriffsberechtigung zum Ändern/Festlegen von Werte haben).
Unter aktiver Benutzersitzung werden die Änderungen in der Ereignisanzeige wie gewünscht protokolliert, wenn diese z. B. mittels regedit.exe geändert werden (etwa manuell im Windows Registrierungseditor oder per Reg-Datei). Allerdings bei Benutzerneuanmeldung bzw. Systemneustart sind keine Protokolle zu verzeichnen, obwohl Werte in diesem Schlüssel durch irgendeinen Prozess umgeändert werden.
Bei nächster Benutzersitzung ist der Wert also wieder zurück geändert ohne eine Spur in der Ereignisanzeige.
Wird die NumLock-Taste mittels VBS umgestellt (CreateObject("WScript.Shell").SendKeys "{NUMLOCK}"), so ändert sich der Wert InitialKeyboardIndicators unter [HKEY_CURRENT_USER\Control Panel\Keyboard] erst bei Benutzerneuanmeldung bzw. Systemneustart, weswegen die Überwachung aktuell scheitert.
Woran liegt dieser Umstand?
Braucht der jeweilige Registrierungsschlüssel sonst was noch für Überwachungseinträge, damit alles im System berücksichtigt werden kann, oder reicht es "logischerweise" doch völlig aus, wenn die Überwachungseinträge den Berechtigungseinträgen entsprechen, da ja nur diese die Zugriffsberechtigung zum Ändern haben?
Bzw. wäre etwa noch eine Richtlinie zu setzen, welche ein erweitertes Protokollieren (und außerhalb aktiver Benutzersitzung) ermöglicht, und welche?
(Abgesehen vom Zustand der NumLock-Taste aus diesem Szenario hier, dass dieser auch durch das Geräte-BIOS gesteuert werden könnte, hat die Überwachung von Reg-Schlüsseln mit dem BIOS natürlich nichts zu tun. Es geht hier also um allgemeine Überwachung von Reg-Schlüssels generell und um allgemeines Problemverhalten verbunden damit und konkret die Änderungen auch außerhalb von Benutzersitzungen nachverfolgen zu können).
Danke für eure Tipps
unter "Überwachung" eines Reg-Schlüssels (im Falle z. B. HKCU\Control Panel\Keyboard\) wurde die relevanten Überwachungseinträge hinzugefügt und zwar nur mit der Zugriffsberechtigung "Wert festlegen", da nur diese für das Projekt relevant ist (d. h. für alle diejenigen Gruppen/Konten, welche unter "Berechtigungen" standardmäßig eh vorhanden sind und die Zugriffsberechtigung zum Ändern/Festlegen von Werte haben).
Unter aktiver Benutzersitzung werden die Änderungen in der Ereignisanzeige wie gewünscht protokolliert, wenn diese z. B. mittels regedit.exe geändert werden (etwa manuell im Windows Registrierungseditor oder per Reg-Datei). Allerdings bei Benutzerneuanmeldung bzw. Systemneustart sind keine Protokolle zu verzeichnen, obwohl Werte in diesem Schlüssel durch irgendeinen Prozess umgeändert werden.
Bei nächster Benutzersitzung ist der Wert also wieder zurück geändert ohne eine Spur in der Ereignisanzeige.
Wird die NumLock-Taste mittels VBS umgestellt (CreateObject("WScript.Shell").SendKeys "{NUMLOCK}"), so ändert sich der Wert InitialKeyboardIndicators unter [HKEY_CURRENT_USER\Control Panel\Keyboard] erst bei Benutzerneuanmeldung bzw. Systemneustart, weswegen die Überwachung aktuell scheitert.
Woran liegt dieser Umstand?
Braucht der jeweilige Registrierungsschlüssel sonst was noch für Überwachungseinträge, damit alles im System berücksichtigt werden kann, oder reicht es "logischerweise" doch völlig aus, wenn die Überwachungseinträge den Berechtigungseinträgen entsprechen, da ja nur diese die Zugriffsberechtigung zum Ändern haben?
Bzw. wäre etwa noch eine Richtlinie zu setzen, welche ein erweitertes Protokollieren (und außerhalb aktiver Benutzersitzung) ermöglicht, und welche?
(Abgesehen vom Zustand der NumLock-Taste aus diesem Szenario hier, dass dieser auch durch das Geräte-BIOS gesteuert werden könnte, hat die Überwachung von Reg-Schlüsseln mit dem BIOS natürlich nichts zu tun. Es geht hier also um allgemeine Überwachung von Reg-Schlüssels generell und um allgemeines Problemverhalten verbunden damit und konkret die Änderungen auch außerhalb von Benutzersitzungen nachverfolgen zu können).
Danke für eure Tipps
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: 71710944528
Url: https://administrator.de/contentid/71710944528
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
6 Kommentare
Neuester Kommentar
Hi,
HKCU ist nur geladen, wenn der Benutzer angemeldet ist.
Versuche mal HKU\S-1-5-.... statt HKCU.
Weiterhin beachte, dass Änderungen im Anmeldescreen dann im Kontext von LocalSystem landen müssten. Das vermute ich jedenfalls.
Ich würde diese Art der Überwachung erstmal mit einem Schlüssel aus HKLM testen. Abmelden, Anmelden, booten. Ob es dann weiterhin funktioniert. Erst wenn das damit funktioniert, würde ich mit HKU weiter testen.
E.
HKCU ist nur geladen, wenn der Benutzer angemeldet ist.
Versuche mal HKU\S-1-5-.... statt HKCU.
Weiterhin beachte, dass Änderungen im Anmeldescreen dann im Kontext von LocalSystem landen müssten. Das vermute ich jedenfalls.
Ich würde diese Art der Überwachung erstmal mit einem Schlüssel aus HKLM testen. Abmelden, Anmelden, booten. Ob es dann weiterhin funktioniert. Erst wenn das damit funktioniert, würde ich mit HKU weiter testen.
E.
ah, ja klar. Mit HKCU war es die klassische Blockade im Kopf.
Natürlich müsste es so funktionieren! Ich werde es gleich versuchen über HKU zu umgehen.
An der Stelle ist gleich zu erwähnen, dass Überwachung von Änderung, welche mittels VBS erfolgt, generell nicht funktioniert. Da hilft selbst Process Monitor nicht weiter. Die Umstellung von Num-Lock erfolgt ohne in die Registrierung zu schreiben, jedoch wird die Änderung beim Neuanmelden bzw. Systemneustart dennoch übernommen.
Offensichtlich irgendein Zusammenspiel zw. BIOS und OS.
Schauen wir mal was ich bei der Überwachung vom relevanten Schlüssel nun so alles erfahren werden.
Danke dir.
Ich markiere es hier schon mal als gelöst, da es sich meinerseits grundlegend um einen Fehler handelt, und zu arg groben sogar, den du auf jeden Fall korrekt erkannt hast.
Und speziell wegen der Num-Lock-Taste können wir immer noch weiter schauen, was da noch so machbar wäre.
Natürlich müsste es so funktionieren! Ich werde es gleich versuchen über HKU zu umgehen.
An der Stelle ist gleich zu erwähnen, dass Überwachung von Änderung, welche mittels VBS erfolgt, generell nicht funktioniert. Da hilft selbst Process Monitor nicht weiter. Die Umstellung von Num-Lock erfolgt ohne in die Registrierung zu schreiben, jedoch wird die Änderung beim Neuanmelden bzw. Systemneustart dennoch übernommen.
Offensichtlich irgendein Zusammenspiel zw. BIOS und OS.
Schauen wir mal was ich bei der Überwachung vom relevanten Schlüssel nun so alles erfahren werden.
Danke dir.
Ich markiere es hier schon mal als gelöst, da es sich meinerseits grundlegend um einen Fehler handelt, und zu arg groben sogar, den du auf jeden Fall korrekt erkannt hast.
Und speziell wegen der Num-Lock-Taste können wir immer noch weiter schauen, was da noch so machbar wäre.
Nach Erweiterung der Überwachungseinträge wie folgt, werden weiterhin keine Ereignisse beim An- und Abmelden bzw. Systemneustart protokolliert:
Ein manueller Eingriff im Registrierungsschlüssel, also während laufender Benutzersitzung, löst gleich das erwartete Ereignis aus, dass die entsprechenden Änderungen durchgeführt wurden.
Hm ...
NT-Autorität\SYSTEM lässt sich nicht als Überwachungseintrag hinzufügen (deutsche Lokalisierung).
Unter HKLM zu überwachen bringt es speziell in meinem Falle aus diesem Grund nicht, da es für das Projekt keine Lösung ist.
Noch andere Ideen vielleicht?
Ein manueller Eingriff im Registrierungsschlüssel, also während laufender Benutzersitzung, löst gleich das erwartete Ereignis aus, dass die entsprechenden Änderungen durchgeführt wurden.
Hm ...
NT-Autorität\SYSTEM lässt sich nicht als Überwachungseintrag hinzufügen (deutsche Lokalisierung).
Unter HKLM zu überwachen bringt es speziell in meinem Falle aus diesem Grund nicht, da es für das Projekt keine Lösung ist.
Noch andere Ideen vielleicht?
Pragmatischer Ansatz:
Wofür brauchst Du diese Überwachung?
Man könnte auch ein Script im Hintergrund laufen lassen, welches diese Werte laufend überprüft und dann ggf. eine Aktion auslöst.
Wofür brauchst Du diese Überwachung?
Man könnte auch ein Script im Hintergrund laufen lassen, welches diese Werte laufend überprüft und dann ggf. eine Aktion auslöst.
Hi,
danke dir, dass du hier dabei bist - ist sonst nichts los. Aber du - bist einmalig
!
Die Lösung über Skript kenne ich. Allerdings sind die Nachteile im Vergleich ordentlich:
Speziell in meinem Falle ist es mir auf jeden Fall wichtiger die Ursache zu finden, warum die Standard-Überwachung außerhalb der Benutzersitzung scheitert, als zu versuchen mit alternativen Mitteln eine ähnliche Prozedur ablaufen zu lassen, weil das Potential der bereits am Bord bestehenden und für mich sehr ausgereiften Lösung viel höher ist. Hier ist auch ihre relativ einfache Handhabung und Verwaltung nicht zu unterschätzen.
Speziell aktuell geht es nicht darum bloß den Wert zu überwachen, sondern die Ursache (die Prozesskette, welche zur Änderung dieses Wertes führt) und das ist unter anderem der zweite entscheidendste Punkt dieses Beitrags. Der wichtigste Punkt ist nach wie vor warum die Überwachung außerhalb der Benutzersitzung nicht funktioniert.
Hierfür benötigte Dienste, welche beim Abmelden heruntergefahren werden? Oder muss hierfür noch irgendeine Richtlinie angepasst werden?
Also die Überwachung brauche ich, um herauszufinden welcher Prozess diese Änderung auslöst, auf jeden Fall die Prozesskette, um an die Ursache zu kommen und diese abstellen zu können.
Da es jedoch Wochen und Monate vergehen können, ist es keine einmalige Angelegenheit für eine Systemüberwachung mit einem Systemneustart oder ähnlichem, wo Programme wie Windows Performance Toolkit (WPT), Procmon ... ressourcenmäßig selbstverständlich im Verhältnis wären.
danke dir, dass du hier dabei bist - ist sonst nichts los. Aber du - bist einmalig
!Die Lösung über Skript kenne ich. Allerdings sind die Nachteile im Vergleich ordentlich:
- 1.) Das Skript läuft stets im Hintergrund und schluckt unnötig mehr Ressourcen, für etwas, was der Richtliniendienst von Windows sowieso im Hintergrund macht. Für so eine "Kleinigkeit", welche jedoch auf Dauer (über mehreren Monaten hinweg) überwacht werden soll, ist es eine enorme Verschwendung und zudem noch ein Ballast in der Prozessverwaltung, welche bei mir bei weitem nicht im Verhältnis steht.
- 2.) Ein Skript lässt sich zwar automatisch auch beim Herunterfahren und Starten vom OS sowie bei Benutzer-An- und Abmeldung ausführen (und mit sonst welchen angepassten Rechten), jedoch schafft ein simpel aufgebautes Skript nicht noch Ergebnisse über die Ursache zu liefern und zudem so ausführlich, wie die hierfür optimierte Registrierungs-Überwachungsrichtlinie. Da müsste ich sonst über WMIC rein und sonst was für eine komplexe Skriptstruktur aufbauen (Prozesse müssen ja auch berücksichtigt werden ...), und hier taucht die legitime Frage auf wieso so umständlich, wenn die Standard-Lösung vom OS im Vergleich viel einfacher und praktischer ist?
Speziell in meinem Falle ist es mir auf jeden Fall wichtiger die Ursache zu finden, warum die Standard-Überwachung außerhalb der Benutzersitzung scheitert, als zu versuchen mit alternativen Mitteln eine ähnliche Prozedur ablaufen zu lassen, weil das Potential der bereits am Bord bestehenden und für mich sehr ausgereiften Lösung viel höher ist. Hier ist auch ihre relativ einfache Handhabung und Verwaltung nicht zu unterschätzen.
Speziell aktuell geht es nicht darum bloß den Wert zu überwachen, sondern die Ursache (die Prozesskette, welche zur Änderung dieses Wertes führt) und das ist unter anderem der zweite entscheidendste Punkt dieses Beitrags. Der wichtigste Punkt ist nach wie vor warum die Überwachung außerhalb der Benutzersitzung nicht funktioniert.
Hierfür benötigte Dienste, welche beim Abmelden heruntergefahren werden? Oder muss hierfür noch irgendeine Richtlinie angepasst werden?
Also die Überwachung brauche ich, um herauszufinden welcher Prozess diese Änderung auslöst, auf jeden Fall die Prozesskette, um an die Ursache zu kommen und diese abstellen zu können.
Da es jedoch Wochen und Monate vergehen können, ist es keine einmalige Angelegenheit für eine Systemüberwachung mit einem Systemneustart oder ähnlichem, wo Programme wie Windows Performance Toolkit (WPT), Procmon ... ressourcenmäßig selbstverständlich im Verhältnis wären.
OK, wenn Du auch erfahren musst, welcher Prozess die Werte ändert, dann fällt das Script aus, ist klar.
