press-it
Goto Top

Ü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? face-smile
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?

Content-Key: 666516

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

Ausgedruckt am: 28.03.2024 um 20:03 Uhr

Mitglied: DerWoWusste
DerWoWusste 07.05.2021 um 14:47:24 Uhr
Goto Top
Hi.

Nutze NTFS-Überwachung. Das protokolliert, welcher Benutzer/Prozess das geändert hat.
https://www.windowspro.de/wolfgang-sommergut/ntfs-auditing-zugriff-auf-d ...
Mitglied: Press-IT
Press-IT 07.05.2021 um 14:57:39 Uhr
Goto Top
Übrigens sehen die Berechtigungen dann so aus:
screenshot2021-05-07_14_53_49-clipboard
screenshot2021-05-07_14_49_56-clipboard
Mitglied: DerWoWusste
Lösung DerWoWusste 07.05.2021 um 17:28:09 Uhr
Goto Top
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.
Mitglied: mayho33
mayho33 08.05.2021 um 21:00:52 Uhr
Goto Top
Zitat von @Press-IT:

Übrigens sehen die Berechtigungen dann so aus

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?
Mitglied: Press-IT
Press-IT 10.05.2021 um 10:58:36 Uhr
Goto Top
@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. face-smile
Mitglied: mayho33
mayho33 10.05.2021 um 12:12:09 Uhr
Goto Top
Zitat von @Press-IT:

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!
Mitglied: Press-IT
Press-IT 11.05.2021 aktualisiert um 11:54:54 Uhr
Goto Top
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.
Mitglied: DerWoWusste
Lösung DerWoWusste 11.05.2021 um 11:49:03 Uhr
Goto Top
Dort bist Du richtig und du kannst "jeder" nutzen. Teste es.
Mitglied: Press-IT
Press-IT 11.05.2021 um 15:07:43 Uhr
Goto Top
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!
Mitglied: Press-IT
Press-IT 17.05.2021 um 17:33:58 Uhr
Goto Top
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.
Mitglied: DerWoWusste
DerWoWusste 17.05.2021 um 18:03:17 Uhr
Goto Top
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 face-smile