4
Änderungen an der lokalen Überwachungsrichtlinie überleben ein gpupdate nicht
Moin Kollegen.
Ich stolpere gerade über etwas äußerst Seltsames. Wer mit NTFS-Dateiüberwachung arbeitet, sollte nun genau mitlesen und, wenn er mag, dies einmal reproduzieren.
->Wenn ich auf einem Domänenclient in secpol.msc die herkömmliche ("non-advanced") lokale Überwachungsrichtlinie ändere, dann bleiben die Änderungen exakt bis zum nächsten GPO-Refresh aktiv - danach werden sie verworfen!
Dies tritt bei allen Domänen-PCs auf, auf denen ich auf die Schnelle getestet habe (Win8.1/Win10/Server 2016).
Es tritt bei keinem non-Domainclient auf
gpresult /h zeigt jedoch keine Domänenpolicy an, die das beeinflussen würde (das wäre die einzige logische Erklärung).
Nun noch der Knaller: bei einem Rechner, bei dem "Audit object access" schon vor Jahren aktiviert worden war, läuft das munter weiter - obwohl er die selben GPOs. wie die anderen bekommt.
Dies betrifft das advanced auditing nicht - hier wird alles beibehalten nach gpupdate.
...sehr merkwürdig. Ist das bei jemandem von Euch auch so?
Ich stolpere gerade über etwas äußerst Seltsames. Wer mit NTFS-Dateiüberwachung arbeitet, sollte nun genau mitlesen und, wenn er mag, dies einmal reproduzieren.
->Wenn ich auf einem Domänenclient in secpol.msc die herkömmliche ("non-advanced") lokale Überwachungsrichtlinie ändere, dann bleiben die Änderungen exakt bis zum nächsten GPO-Refresh aktiv - danach werden sie verworfen!
Dies tritt bei allen Domänen-PCs auf, auf denen ich auf die Schnelle getestet habe (Win8.1/Win10/Server 2016).
Es tritt bei keinem non-Domainclient auf
gpresult /h zeigt jedoch keine Domänenpolicy an, die das beeinflussen würde (das wäre die einzige logische Erklärung).
Nun noch der Knaller: bei einem Rechner, bei dem "Audit object access" schon vor Jahren aktiviert worden war, läuft das munter weiter - obwohl er die selben GPOs. wie die anderen bekommt.
Dies betrifft das advanced auditing nicht - hier wird alles beibehalten nach gpupdate.
...sehr merkwürdig. Ist das bei jemandem von Euch auch so?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 361447
Url: https://administrator.de/contentid/361447
Printed on: April 18, 2024 at 19:04 o'clock
4 Comments
Latest comment
Hi,
bei mir bleibt das erhalten. Eben getestet.
Win 10 Pro 1709 - Domain Member
E.
bei mir bleibt das erhalten. Eben getestet.
Win 10 Pro 1709 - Domain Member
E.
Aha... ich schätze mal, meine Testdomäne @home wird mir heute Abend das Selbe liefern... was mag da bloß defekt sein?
Sonst gibt es hier keine Auffälligkeiten bzgl. GPOs.
Danke
Sonst gibt es hier keine Auffälligkeiten bzgl. GPOs.
Danke
So, ich konnte es aufklären und überall nachvollziehen, auch in einer jungfräulichen Domäne (Server 2016 v1607 als DC, win10 v1709 als Client).
Setzt man eine GPO ein, die "Advanced audit policy configuration" benutzt, also z.B. "audit removable storage", dann wird davon alles in der lokalen non-advanced audit policy schlicht überschrieben.
Vermutlich ist das sogar so gedacht und ich wusste es nur nicht besser.
Setzt man eine GPO ein, die "Advanced audit policy configuration" benutzt, also z.B. "audit removable storage", dann wird davon alles in der lokalen non-advanced audit policy schlicht überschrieben.
Vermutlich ist das sogar so gedacht und ich wusste es nur nicht besser.
Alles klar... siehe https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
Important
Using both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
Using both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
