30
Ü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☹
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: 42485283593
Url: https://administrator.de/forum/ueberwachungsrichtlinie-funktioniert-nicht-42485283593.html
Ausgedruckt am: 21.12.2024 um 13:12 Uhr
30 Kommentare
Neuester Kommentar
Es ist ausgegraut, da die Domänenrichtlinie gilt. Kein Handlungsbedarf, alles in Ordnung.
Du erwartest, dass dort steht, wie sie konfiguriert ist - dem ist aber nicht so und das ist normal.
Du erwartest, dass dort steht, wie sie konfiguriert ist - dem ist aber nicht so und das ist normal.
Hi, danke für die Antwort. Ja genau, das erwarte ich eigentlich, denn das Ziel ist, die Events 4624 (erfolgreich angemeldet) und 4625 (fehlerhafte login) zu loggen. Und genau das passiert auf den Clients nicht, oder muss ich noch wo anders schauen?
Vermutlich erwartest Du, dass es bei Domänenlogons funktioniert. Diese werden aber nicht am Client authentifiziert, sondern am Domänencontroller und das Logging muss dort eingerichtet werden.
Deine Einstellung gilt für Logins mit lokalen nutzern.
Deine Einstellung gilt für Logins mit lokalen nutzern.
1
Es sind die LOKALEN Sicherheitsrichtlinien. Also alles LOKAL was mit CLIENT bzw. dem LOKALEN Server zu tun hat. Also Lokale Anmeldung via .\Benutzer oder PCNAME\Benutzer usw.....
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).
Leider kann ich das so nicht bestätigen. In einer neuer Testdomäne einfach die Ü-Richtlinie in der Default Domain Policy gesetzt, die Controller Policy unverändert gelassen und nur dem DC zugeordnet. Es funktioniert genau wie gewünscht. Fehlerhafte Anmeldungen sehe ich im Client. Fehlerhafte Anmeldungen am Server, nur leider nicht im Live System.
Gehe jetzt jede Einstellung durch...aua
Gehe jetzt jede Einstellung durch...aua
Prüfe an allen DCs mittels des Kommandos (auf einer elevated cmd):
ob die vermeintlich wirkenden Einstellungen schon greifen.
gpresult /h %temp%\resultat.html & %temp%\resultat.html
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 /rGruss 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
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?
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 ...
... läuft es ohne Probleme.
Wenn ich das aber über ...
Gruss Alex
Dann stell das im Bereich Kontoanmeldung ein und lies nach, was der Unterschied beider Logs ist.
Moin zusammen, ich sehe schon, so trivial ist die ganze Sache doch nicht. Ich fasse nochmal zusammen. In der DefDomPol die Ü-Richtlinie gesetzt, wird auf allen Clients/Servern scheinbar gepusht, unter secpol.msc egal bei welchem Client steht trotzdem die Sicherheitseinstellung auf "Keine Überwachung", daher werden auch keine Events 4624, 4625 aufgezeichnet.
Die DefContrlPol steht bei Ü-Richtlinie auf "Nicht konfiguriert" genau wie die erweiterte Ü-Richtlinie. In einer Testdomäne genau so gemacht, funktioniert sofort wie oben beschrieben. Der einzige Unterschied zur Testdomäne, beim Ausführen von gpresult /force bzw. gpreport sind Disk Quota Fehler, siehe Screenshot. Es muss doch einen Grund geben, warum die Ü-Richtlinie nicht sauber angewendet wird???
Die DefContrlPol steht bei Ü-Richtlinie auf "Nicht konfiguriert" genau wie die erweiterte Ü-Richtlinie. In einer Testdomäne genau so gemacht, funktioniert sofort wie oben beschrieben. Der einzige Unterschied zur Testdomäne, beim Ausführen von gpresult /force bzw. gpreport sind Disk Quota Fehler, siehe Screenshot. Es muss doch einen Grund geben, warum die Ü-Richtlinie nicht sauber angewendet wird???
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.
kann ich im Life System leider nicht machen, wie gesagt, im Testsystem geht sofort alles auch ohne die Advanced Audit Policies....
Und was kannst Du warum nicht machen?
Zentrale Policies abschalten, wenn es laut Testsystem nicht an den Policies liegt...
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.
2
ja, vielen Dank.....da habe ich auch schon dran rumgeschraubt, hat aber auch nichts gebracht. Daher steht die erweiterte Ü-Richtlinie komplett auf "Nicht konfiguriert" bei allen DC's
Habe neue Erkenntnisse gewonnen. Wenn ich einen nicht konfigurierten Client ins Testsystem hänge, zieht er sich sauber die DefDomPolicy und stellt meine Ü-Richtlinie sauber auf konfiguriert und die Sicherheitseinstellungen auf "Erfolgreich,Fehler"
Nehme ich aber einen Client aus meinem Live System und trete dieser neuen Testdomäne bei, werden die Einstellungen nicht übernommen....Ideen???
Nehme ich aber einen Client aus meinem Live System und trete dieser neuen Testdomäne bei, werden die Einstellungen nicht übernommen....Ideen???
Du musst das genauer beschreiben. Was betrachtest Du, um zu beurteilen, was er zieht?
Guten Morgen zusammen, es ist doch eigentlich alles gesagt. Ich muss die Logs der authentifizierten Domänenclients einsammeln. GPO's arbeiten soweit einwandfrei, bis auf das Disk Quota Problem, es ist nur eine Ü-Richtlinie in der Domäne aktiv. Im Testsystem funktioniert es sofort, siehe Screenshot. Wie auch schon Mystic sagte, es ist elementar, dass unter den Richtlinieneinstellungen Fehler/Erfolg stehen muss, ansonsten funktioniert das Logging nicht.
Du schaust weiterhin auf das, was die lokale Sicherheitsrichtlinie, so wie du sie in gpedit.msc bzw. secpol.msc siehst, anzeigt? Wenn ja, ist das nun das Selbe, wie das was gpresult /h dir anzeigt, oder nicht?
Fast, die gpresult sagt, dass die Ü-Richtlinie übernommen wurde, auch mit Feher und Erfolg, die Lokale steht auf nicht übernommen und lässt sich nicht editieren, weil die Policy drüber steht. Wie ganz oben schon beschrieben, irgendetwas verhindert das komplette Übernehmen der Einstellungen, daher sehe ich auch keine Ü-Logs auf den Clients. Habe keine FW in der Domäne, AV Software auch deinstalliert. Vielleicht fehlt irgendein Patch auf dem Livesystem Server.
So, letzter Kommentar von mir.
Nimm die klassischen Policies raus und die advanced Policies rein und es wird laufen. Wenn Du das nicht willst, dann eben nicht.
Nimm die klassischen Policies raus und die advanced Policies rein und es wird laufen. Wenn Du das nicht willst, dann eben nicht.
Im Testsystem habe ich die doch auch nicht drin und es funktioniert. Ok, wir lassen das hier, trotzdem Danke für Euren Support.
Mahlzeit zusammen, habe es hinbekommen, hier die Lösung.
In allen Policys die lokale Sicherheitsrichtlinie auf "Nicht definiert" stellen, auch in der Domain Controller Policy.
Eine neue Überwachungs-GPO unterhalb der Domain Controller Policy erstellen und unter Computerkonfiguration-> Sicherheitseinstellungen->Sicherheitsoptionen->"Überwachung Unterkategorieeinstellungen der Überwachung bla bla" auf "Aktiviert"
Dann die erweiterte Überwachungsrichtlinie so konfigurieren, wie es gebraucht wird. mit "gpupdate /force" alles schön pushen.
In allen Policys die lokale Sicherheitsrichtlinie auf "Nicht definiert" stellen, auch in der Domain Controller Policy.
Eine neue Überwachungs-GPO unterhalb der Domain Controller Policy erstellen und unter Computerkonfiguration-> Sicherheitseinstellungen->Sicherheitsoptionen->"Überwachung Unterkategorieeinstellungen der Überwachung bla bla" auf "Aktiviert"
Dann die erweiterte Überwachungsrichtlinie so konfigurieren, wie es gebraucht wird. mit "gpupdate /force" alles schön pushen.
Das hatte ich dir so geraten. Die Zusatzpolicy (roter Pfeil) überstimmt nur ggf. vorhandene klassische Policies; auch das war genau so schon erwähnt worden.
