11
Überwachung von Änderungen der NTFS-Berechtigungen
Tach Forum!
Das ist mein erster Beitrag hier, wenn also etwas nicht den Standards entsprechen sollte nicht gleich draufhauen, ja?
Wir haben bei manchen Clients (alle W10 Pro 20H2) in einer AD-Umgebung seit kurzem das Problem, dass bei 3 Dateien unter halb von C:\Windows\assembly\GAC_MSIL\ die Berechtigungen so verändert werden, dass "Hostname\Benutzer" keine Leserechte mehr auf die Dateien haben. Dadurch fliegt in Outlook ein AddIn raus - was wir schon seit Jahren problemlos nutzen.
Das Recht wird nicht einfach nur verändert sondern der komplette Eintrag entfernt...
Normalerweise hätte ich Windows-Updates im Verdacht, aber wir können in den aktuellen Ereignisprotokollen keine Daten finden, die zeitlich dazu passen. Auch sonst konnten wir dem noch nicht auf die Spur kommen: Es sind nur wenige Clients mit dem Problem, und die auch nicht recht dicht nacheinander (wie es bei Updates zu erwarten wäre) sondern mittlerweile über 2 Wochen verteilt.
Daher war meine Idee, diese 3 Dateien zu überwachen, z.B. mit dem Process Monitor. Bisher habe ich das Tool noch nie selbst benutzt, aber die eigentliche "Kunst" besteht wohl darin, die Unmenge an Protokolldaten entsprechend einzudampfen und zu filtern. Daher meine Frage: Hat jemand Erfahrung mit dem Tool? Auf was muss man achten, was ich sinnvoll einzustellen? Kann ich beim Filtern auf den Ordnerpfad auch mehrere Pfade angeben und mit "Oder" verknüpfen, oder funktionieren die Filter immer per "Und"-Verknüpfung?
Übrigens liegen diese Dateien jeweils als einzige in einem Ordner - die Berechtigungen für den Ordner selbst passen aber noch! Es wird also tatsächlich nur die Berechtigung für die Dateien selbst geändert!
Wenn jemand ein anderes Tool kennt, das solche Änderungen überwachen kann: Immer raus damit! Mir fiel nur dieses als Erstes ein, aber von Solarwinds gibt es wohl auch etwas ähnliches. Inwieweit das mit den Überwachungsrichtlinien der GPO zu bewerkstelligen ist weiß ich nicht. Funktionieren die überhaupt für lokale Dateien, oder nur für SMB-Shares?
Das ist mein erster Beitrag hier, wenn also etwas nicht den Standards entsprechen sollte nicht gleich draufhauen, ja?
Wir haben bei manchen Clients (alle W10 Pro 20H2) in einer AD-Umgebung seit kurzem das Problem, dass bei 3 Dateien unter halb von C:\Windows\assembly\GAC_MSIL\ die Berechtigungen so verändert werden, dass "Hostname\Benutzer" keine Leserechte mehr auf die Dateien haben. Dadurch fliegt in Outlook ein AddIn raus - was wir schon seit Jahren problemlos nutzen.
Das Recht wird nicht einfach nur verändert sondern der komplette Eintrag entfernt...
Normalerweise hätte ich Windows-Updates im Verdacht, aber wir können in den aktuellen Ereignisprotokollen keine Daten finden, die zeitlich dazu passen. Auch sonst konnten wir dem noch nicht auf die Spur kommen: Es sind nur wenige Clients mit dem Problem, und die auch nicht recht dicht nacheinander (wie es bei Updates zu erwarten wäre) sondern mittlerweile über 2 Wochen verteilt.
Daher war meine Idee, diese 3 Dateien zu überwachen, z.B. mit dem Process Monitor. Bisher habe ich das Tool noch nie selbst benutzt, aber die eigentliche "Kunst" besteht wohl darin, die Unmenge an Protokolldaten entsprechend einzudampfen und zu filtern. Daher meine Frage: Hat jemand Erfahrung mit dem Tool? Auf was muss man achten, was ich sinnvoll einzustellen? Kann ich beim Filtern auf den Ordnerpfad auch mehrere Pfade angeben und mit "Oder" verknüpfen, oder funktionieren die Filter immer per "Und"-Verknüpfung?
Übrigens liegen diese Dateien jeweils als einzige in einem Ordner - die Berechtigungen für den Ordner selbst passen aber noch! Es wird also tatsächlich nur die Berechtigung für die Dateien selbst geändert!
Wenn jemand ein anderes Tool kennt, das solche Änderungen überwachen kann: Immer raus damit! Mir fiel nur dieses als Erstes ein, aber von Solarwinds gibt es wohl auch etwas ähnliches. Inwieweit das mit den Überwachungsrichtlinien der GPO zu bewerkstelligen ist weiß ich nicht. Funktionieren die überhaupt für lokale Dateien, oder nur für SMB-Shares?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666516
Url: https://administrator.de/forum/ueberwachung-von-aenderungen-der-ntfs-berechtigungen-666516.html
Ausgedruckt am: 21.04.2025 um 11:04 Uhr
11 Kommentare
Neuester Kommentar
Hi.
Nutze NTFS-Überwachung. Das protokolliert, welcher Benutzer/Prozess das geändert hat.
https://www.windowspro.de/wolfgang-sommergut/ntfs-auditing-zugriff-auf-d ...
Nutze NTFS-Überwachung. Das protokolliert, welcher Benutzer/Prozess das geändert hat.
https://www.windowspro.de/wolfgang-sommergut/ntfs-auditing-zugriff-auf-d ...
Übrigens sehen die Berechtigungen dann so aus:
Schau mal hier: https://www.msxfaq.de/konzepte/auditing/auditingwindows.htm da siehst Du unten bei den Beispiellogeinträgen, dass der Prozess auch zu sehen ist.
Also auf den ersten Blick schaut das für mich aber OK aus. Leserechte bestehen ja.
Wie genau schaut das mit dem Rausfliegen des AddIn aus? Wo gehen die Einträge verloren?
@mayho33
Die Screenshots zeigen den Zustand vorher, also wenn es noch funktioniert, und nachher, wenn das Addin rausgeflogen ist. Auf dem 2. Screenshot sind die Leserechte für den hostname\Benutzer eben nicht mehr vorhanden! (Die Screenshots stammen von verschiedenen Rechnern, daher einmal der Zugriff per c$-Freigabe)
Ich werde morgen mal den Ansatz von @DerWoWusste testen. Das scheint genau das zu sein, was ich haben wollte.
Die Screenshots zeigen den Zustand vorher, also wenn es noch funktioniert, und nachher, wenn das Addin rausgeflogen ist. Auf dem 2. Screenshot sind die Leserechte für den hostname\Benutzer eben nicht mehr vorhanden! (Die Screenshots stammen von verschiedenen Rechnern, daher einmal der Zugriff per c$-Freigabe)
Ich werde morgen mal den Ansatz von @DerWoWusste testen. Das scheint genau das zu sein, was ich haben wollte.
Die Screenshots zeigen den Zustand vorher, also wenn es noch funktioniert, und nachher, wenn das Addin rausgeflogen ist. Auf dem 2. Screenshot sind die Leserechte für den hostname\Benutzer eben nicht mehr vorhanden!
Aha! Verstehe!
Ich scheitere gerade daran, die Überwachung in den Eigenschaften der NTFS-Objekte per GPO zu setzen. Auf jedem Client per Hand die Eigenschaften jeder zu überwachenden Datei zu bearbeiten kann ja nicht im Sinne des Erfinders sein.
Für Domäne\Benutzer könnte ich die Einstellung setzen, aber wie setze ich das für Hostname\Benutzer? Oder genügt Domäne/Benutzer?
Oder andersrum: Wenn ich dort JEDER setze, wird dann Hostname\Benutzer mit überwacht?
Bin ich im Bereich Computerkonfiguration - Richtlinien - Windows-Einstellungen - Sicherheitseinstellungen - Dateisystem überhaupt richtig? Dort kann ich Rechte setzen bzw. vererben, aber zunächst mal will ich ja sehen, was dort passiert ist, bevor ich mit der Vererbung einfach drüber bügele.
Für Domäne\Benutzer könnte ich die Einstellung setzen, aber wie setze ich das für Hostname\Benutzer? Oder genügt Domäne/Benutzer?
Oder andersrum: Wenn ich dort JEDER setze, wird dann Hostname\Benutzer mit überwacht?
Bin ich im Bereich Computerkonfiguration - Richtlinien - Windows-Einstellungen - Sicherheitseinstellungen - Dateisystem überhaupt richtig? Dort kann ich Rechte setzen bzw. vererben, aber zunächst mal will ich ja sehen, was dort passiert ist, bevor ich mit der Vererbung einfach drüber bügele.
Dort bist Du richtig und du kannst "jeder" nutzen. Teste es.
1
Implementiert ist die Überwachung, funktioniert auch.
Jetzt müssen wir auf den Fehler warten - und darauf hoffen, dass das Eventlog aussagekräftig genug sein wird...
Ich konnte nicht einschätzen, ob "Autorisierungsrichtlinienänderung überwachen" oder "Sensible Verwendung von Rechten überwachen" für uns zutrifft, daher habe ich für beide die Überwachung aktiviert.
Bis hierhin erstmal ein großes Dankeschön an @DerWoWusste!
Jetzt müssen wir auf den Fehler warten - und darauf hoffen, dass das Eventlog aussagekräftig genug sein wird...
Ich konnte nicht einschätzen, ob "Autorisierungsrichtlinienänderung überwachen" oder "Sensible Verwendung von Rechten überwachen" für uns zutrifft, daher habe ich für beide die Überwachung aktiviert.
Bis hierhin erstmal ein großes Dankeschön an @DerWoWusste!
Abschließende Anmerkung:
Ich hatte es ja schon befürchtet, aber das Ereignisprotokoll war leider nicht sehr aufschlussreich.
Wir konnten es dann über ein Supportticket beim Hersteller der AddIns klären: Es waren tatsächlich Updates von Microsoft, die dazu geführt haben. Sie haben uns einen Workaround zur Verfügung gestellt, der das Problem zwar nicht ursächlich behebt, aber kurzfristig und simpel umsetzbar ist wenn das Problem wieder auftreten sollte.
Etwas gelernt bzw. etwas mitgenommen habe ich dabei aber auf jeden Fall, denn sowas kann man sicher noch ein ander Mal gebrauchen!
Insofern Danke nochmal! Hier kann dann zugemacht werden.
Ich hatte es ja schon befürchtet, aber das Ereignisprotokoll war leider nicht sehr aufschlussreich.
Wir konnten es dann über ein Supportticket beim Hersteller der AddIns klären: Es waren tatsächlich Updates von Microsoft, die dazu geführt haben. Sie haben uns einen Workaround zur Verfügung gestellt, der das Problem zwar nicht ursächlich behebt, aber kurzfristig und simpel umsetzbar ist wenn das Problem wieder auftreten sollte.
Etwas gelernt bzw. etwas mitgenommen habe ich dabei aber auf jeden Fall, denn sowas kann man sicher noch ein ander Mal gebrauchen!
Insofern Danke nochmal! Hier kann dann zugemacht werden.
das Ereignisprotokoll war leider nicht sehr aufschlussreich
Das Problem trat erneut auf, aber...? Das Protokoll gab doch sicherlich wieder, wer die Rechte geändert hat.Sollte es das Systemkonto gewesen sein, hättest Du auch schon einen Workaround: dem Systemkonto per NTFS-Rechteverweigerung verbieten, die Rechte zu ändern.
Hier kann dann zugemacht werden
Du selbst machst zu. Es gibt da einen "gelöst"-Knopf 1
