Überwachungsrichtlinie funktioniert nicht
Moin liebe Community,
ich habe ein blödes Problem mit der Überwachungsrichtlinie in der DefDomPol. Ich setzte dort die Einstellungen, sie werden aber auf den Clients/Servern nicht angewendet. Habe auch schon eine neue Policy gebaut, dort nur die Ü-Richtlinie gesetzt und in der DefDomPol auf "Nicht konfiguriert", gleiches Ergebnis.
Man kann an den Bildern sehen, wie sich die Einstellungen an der lokalen Sicherheitsrichtlinie verändern, trotzdem steht unter Sicherheitseinstellung "Keine Überwachung". Irgendetwas blockiert das Setzen der Einstellungen. Hat jemand einen coolen Tipp?
Bin ratlos☹
ich habe ein blödes Problem mit der Überwachungsrichtlinie in der DefDomPol. Ich setzte dort die Einstellungen, sie werden aber auf den Clients/Servern nicht angewendet. Habe auch schon eine neue Policy gebaut, dort nur die Ü-Richtlinie gesetzt und in der DefDomPol auf "Nicht konfiguriert", gleiches Ergebnis.
Man kann an den Bildern sehen, wie sich die Einstellungen an der lokalen Sicherheitsrichtlinie verändern, trotzdem steht unter Sicherheitseinstellung "Keine Überwachung". Irgendetwas blockiert das Setzen der Einstellungen. Hat jemand einen coolen Tipp?
Bin ratlos☹
Please also mark the comments that contributed to the solution of the article
Content-ID: 42485283593
Url: https://administrator.de/contentid/42485283593
Printed on: September 1, 2024 at 12:09 o'clock
30 Comments
Latest comment
Es sind die LOKALEN Sicherheitsrichtlinien. Also alles LOKAL was mit CLIENT bzw. dem LOKALEN Server zu tun hat
Moin. Das ist eine Fehldeutung. Viele der Richtlinien dort gelten auch für Domänenlogins, nur eben die nicht, welche direkt mit dem Anmeldeserver zu tun haben (der auditiert die fehlgeschlagenen Logins, und prüft Kennwörter bei Änderung gegen die KW-Richtlinien).
Moin @odo-pls,
ja, dieses Problem hat mir auch schon den einen oder anderen "Spass" beschert. 😭
Du hast bei dir wahrscheinlich noch irgend eine GPO, in der das folgende Konfiguriert ist.
Wenn diese Einstellungen auf einem DC gesetzt sind, die eigentlich für mein Verständnis dasselbe bewirken sollten wie auch die von deinem Screenshot, dann funktioniert die Anmeldeüberwachung auf den DC's überhaupt nicht mehr. 😬
Oder du hast eine GPO mit den folgenden Einstellungen.
Mit ...
(CMD als Administrator)
... siehst du übrigens am schnellsten, welche GPO's auf dem entsprechenden DC angewandt werden.
Gruss Alex
Man kann an den Bildern sehen, wie sich die Einstellungen an der lokalen Sicherheitsrichtlinie verändern, trotzdem steht unter Sicherheitseinstellung "Keine Überwachung". Irgendetwas blockiert das Setzen der Einstellungen. Hat jemand einen coolen Tipp?
Bin ratlos☹
Bin ratlos☹
ja, dieses Problem hat mir auch schon den einen oder anderen "Spass" beschert. 😭
Du hast bei dir wahrscheinlich noch irgend eine GPO, in der das folgende Konfiguriert ist.
Wenn diese Einstellungen auf einem DC gesetzt sind, die eigentlich für mein Verständnis dasselbe bewirken sollten wie auch die von deinem Screenshot, dann funktioniert die Anmeldeüberwachung auf den DC's überhaupt nicht mehr. 😬
Oder du hast eine GPO mit den folgenden Einstellungen.
Mit ...
(CMD als Administrator)
gpresult /r
Gruss Alex
Moin @DerWoWusste,
das ist so leider nicht ganz richtig.
Gruss Alex
Du erwartest, dass dort steht, wie sie konfiguriert ist - dem ist aber nicht so und das ist normal.
das ist so leider nicht ganz richtig.
Gruss Alex
@alex
Hier nicht
Aber hier habe ich auch nicht zuvor lokal etwas eingestellt, sondern nur die Domänen-GPO erlassen, vielleicht erklärt es das?
Hier nicht
Aber hier habe ich auch nicht zuvor lokal etwas eingestellt, sondern nur die Domänen-GPO erlassen, vielleicht erklärt es das?
Moin @DerWoWusste,
bist du dir den auch sicher, dass die entsprechenden Anmeldeevents (4624, 4634, 4647, 4625, 4768, 4771 ) auf diesem Server überhaupt sauber geschrieben werden?
Ich hatte genau dieses Phänomen schon mehrfach auf diversen DC's gesehen und musste dabei leider immer wieder auch feststellen, dass die entsprechenden Events überhaupt nicht geschrieben wurden. 😭
Ich sag nur ... Sophos STAS ... da braucht man das nämlich auch. 🙃
Gruss Alex
Hier nicht
Aber hier habe ich auch nicht zuvor lokal etwas eingestellt, sondern nur die Domänen-GPO erlassen, vielleicht erklärt es das?
Aber hier habe ich auch nicht zuvor lokal etwas eingestellt, sondern nur die Domänen-GPO erlassen, vielleicht erklärt es das?
bist du dir den auch sicher, dass die entsprechenden Anmeldeevents (4624, 4634, 4647, 4625, 4768, 4771 ) auf diesem Server überhaupt sauber geschrieben werden?
Ich hatte genau dieses Phänomen schon mehrfach auf diversen DC's gesehen und musste dabei leider immer wieder auch feststellen, dass die entsprechenden Events überhaupt nicht geschrieben wurden. 😭
Ich sag nur ... Sophos STAS ... da braucht man das nämlich auch. 🙃
Gruss Alex
Es ist weithin bekannt, dass MS nur die advanced auditing policies empfiehlt und dass diese auch funktionieren.
Merkwürdigkeiten bei der Verwendung der anderen, klassischen, sind bekannt. Unter anderem, dass deren Status sich zwar lokal in secpol.msc erahnen lässt (das icon vor der Policyeinstellung ändert sich, wenn es eine Domänen-GPO ist, die den Ausschlag gibt), aber das muss nicht heißen, dass es auch funktioniert, da gebe ich Alex Recht.
Ergo: @odo-pls nimm die advanced audit policy. Und ob eine Policy angewendet wird, immer mit gpresult /h ablesen, nicht im lokalen Gruppenrichtlinieneditor.
Merkwürdigkeiten bei der Verwendung der anderen, klassischen, sind bekannt. Unter anderem, dass deren Status sich zwar lokal in secpol.msc erahnen lässt (das icon vor der Policyeinstellung ändert sich, wenn es eine Domänen-GPO ist, die den Ausschlag gibt), aber das muss nicht heißen, dass es auch funktioniert, da gebe ich Alex Recht.
Ergo: @odo-pls nimm die advanced audit policy. Und ob eine Policy angewendet wird, immer mit gpresult /h ablesen, nicht im lokalen Gruppenrichtlinieneditor.
Moin @DerWoWusste,
ich habe bei einem Kunden aktuell genau das Problem was ich oben beschrieben habe.
Sprich, wenn ich bei diesem das Logen der Logins darüber aktiviere ...
(Ja, die Optionen sind auf den Screenshots nicht richtig gesetzt, dieser soll auch nur der Orientierung dienen.)
... läuft es ohne Probleme.
Wenn ich das aber über ...
... mache, logt der DC die Logins nicht mehr. 😭🤢🤮
Gruss Alex
Es ist weithin bekannt, dass MS nur die advanced auditing policies empfiehlt und dass diese auch funktionieren.
Merkwürdigkeiten bei der Verwendung der anderen, klassischen, sind bekannt. Unter anderem, dass deren Status sich zwar lokal in secpol.msc erahnen lässt (das icon vor der Policyeinstellung ändert sich, wenn es eine Domänen-GPO ist, die den Ausschlag gibt), aber das muss nicht heißen, dass es auch funktioniert, da gebe ich Alex Recht.
Ergo: @odo-pls nimm die advanced audit policy. Und ob eine Policy angewendet wird, immer mit gpresult /h ablesen, nicht im lokalen Gruppenrichtlinieneditor.
Merkwürdigkeiten bei der Verwendung der anderen, klassischen, sind bekannt. Unter anderem, dass deren Status sich zwar lokal in secpol.msc erahnen lässt (das icon vor der Policyeinstellung ändert sich, wenn es eine Domänen-GPO ist, die den Ausschlag gibt), aber das muss nicht heißen, dass es auch funktioniert, da gebe ich Alex Recht.
Ergo: @odo-pls nimm die advanced audit policy. Und ob eine Policy angewendet wird, immer mit gpresult /h ablesen, nicht im lokalen Gruppenrichtlinieneditor.
ich habe bei einem Kunden aktuell genau das Problem was ich oben beschrieben habe.
Sprich, wenn ich bei diesem das Logen der Logins darüber aktiviere ...
(Ja, die Optionen sind auf den Screenshots nicht richtig gesetzt, dieser soll auch nur der Orientierung dienen.)
... läuft es ohne Probleme.
Wenn ich das aber über ...
... mache, logt der DC die Logins nicht mehr. 😭🤢🤮
Gruss Alex
Alles wurde gesagt:
Die DCs authentifizieren die Domänenkonten, nicht die Clients.
Stelle an den DCs die klassischen Richtlinien ab und verwende innerhalb einer GPO, die auf die OU der DCs verlinkt ist die advanced audit policies (machen wir so und es läuft auf DCs 2016/2019/2022!) - beachte dort, dass es mehrere Policies zu den Anmeldungen gibt und lies die Beschreibungen.
Teste mittels gpresult /h an allen DCs, ob dies wirkt.
Mache einen Test mit absichtlichen Fehllogons.
Die DCs authentifizieren die Domänenkonten, nicht die Clients.
Stelle an den DCs die klassischen Richtlinien ab und verwende innerhalb einer GPO, die auf die OU der DCs verlinkt ist die advanced audit policies (machen wir so und es läuft auf DCs 2016/2019/2022!) - beachte dort, dass es mehrere Policies zu den Anmeldungen gibt und lies die Beschreibungen.
Teste mittels gpresult /h an allen DCs, ob dies wirkt.
Mache einen Test mit absichtlichen Fehllogons.
Du kannst alles im Testsystem nachvollziehen. Nimm advanced audit Policies im Testsystem und es läuft. Dann steigst Du Produktivsystem darauf um - fertig.
Noch ein Hinweis von Microsoft:
Vielleicht ist der eine oder andere Teilnehmer dieses threads ja Opfer der unexpected results, da er beides gemischt hat.
Noch ein Hinweis von Microsoft:
Whether you apply advanced audit policies by using group policy or by using logon scripts, don't use both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Security Settings\Advanced Audit Policy Configuration. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the Audit: Force audit policy subcategory settings to override audit policy category settings policy setting under Local Policies\Security Options. This setting prevents conflicts between similar settings by forcing basic security auditing to be ignored.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the Audit: Force audit policy subcategory settings to override audit policy category settings policy setting under Local Policies\Security Options. This setting prevents conflicts between similar settings by forcing basic security auditing to be ignored.
Vielleicht ist der eine oder andere Teilnehmer dieses threads ja Opfer der unexpected results, da er beides gemischt hat.