DC mit Server 2022: Audit Konfig. in "Local Security Policy" bleibt nicht gespeichert?

[andrew 15]

Moin togehter

 

Jetzt ist es an der Zeit, dass ich mich an die "grosse Masse" wende, denn in meinen Augen läuft hier etwas gewaltig schief :-(

 

Um was geht's?

Ziel: Ich möchte, dass meine Firewall, Sophos XG beim Surfen den Webfilter anwendet. Damit die Sophos XG FW weiss, für welchen Benutzer Sie welche Einstellung betreffend Webfilter anwenden soll, muss diese in der Lage sein, mit meinem Domain Controller (Server 2022) zu kommunizieren (AD auslesen, damit Sie weiss, welcher User in welcher AD Gruppe ist und demzufolge dann gemäss Konfiguration entsprechend handeln kann). 

 

Damit dies funktioniert, funktioniert die Sache im Groben so, dass man auf dem Domaincontroller ein Stück Software (Sophos STAS) installieren muss (oder auf einem Memberserver) und diese dann z.B. auf dem Domain Controller die Logon/ Logoff Audit Einträge der Ereignisanzeige des DCs ausliest, der FW weiterleitet und diese dann auf Grund dessen weiss, dass dieser AD User, welcher auf der Webseite xy am Surfen ist, ob das erlaubt ist oder nicht.

 

Weil ich festgestellt habe, dass in dieser Sophos STAS Software, welche auf dem DC läuft, mir keine Live User anzeigt, habe ich in einem nächsten Schritt auf dem DC geprüft, ob überhaupt irgendwelche Audit Login/ Logoff Informationen vorhanden sind und musste feststellen, dass ich in der Ereignisanzeige unter Securty keine Event ID 4768 finde, generell eigentlich nichts in der Hinsicht. Nur 1 Event von der Health irgendwas Mailbox des Exchange.

 

Wie auch immer, ich habe es auf zwei Arten versucht, dem DC mit Server 2022 beizubringen, dass er die Audit Login und Logoff Event IDs loggen soll, indem ich folgendes versuchte:

1. Default Domain Controller Policy (ist auf OU Domain Controllers verlinkt, in dieser ist mein DC Computer Objekt, soweit so gut). Dann habe ich die Einstellung "Audit account logon events" unter Computer Configuration\Policies\Windows Settings\Security Settings\Local Policy\Audit Policy sowohl für "success" wie auch für "failure" aktiviert.

 

nach einem gupdate /force

 

War die Einstellung in dieser GPO immer noch vorhanden, Aber: Als ich dann die "local security policy" auf dem DC starte und überprüft habe, ob dort die Einstellung auch vorhanden ist, stellte ich fest: NEIN! Man sah zwar, dass die Policy von "einer" übergeordneten GPO eine Einstellung erhielt, weil man konnte hier keine Änderungen vornehmen, da die Kästzchen zum Ankreuzen ausegraut sind, jedoch war die Einstellung dieser lokalen security GPO auf "no auditing"

 

2. Ich dachte mir, ok, dann erstelle ich die Audit Account login Einstellung halt direkt in der "local security Policy" des DCs, wenn diese die übergeordnete Einstellung nicht übernehmen will Und: auch da, musste ich mit Schrecken feststellen, sobald ich die Einstellung für erfolgreiche und fehlgeschlagene Events angekreuzt hatte, wieder ein gpupdate /force ausführte, die local security Policy wieder erneut öffnete (es ist ja eine MMC, da kann man die Ansicht ja nicht einfach aktualisieren), war die Einstellung wieder weg, sprich, es war wieder die Default Einstellung "no auditing" eingestellt. 

 

Was zum Geier ist mit meinem DC los, warum lässt der DC nicht zu, dass ich erfolgreiche Login und fehlgeschlagene Logins in der GPO speichern kann bzw. nach dem Speichern verwirfft er diese Einstellung wieder? 

 

So muss ich dies zumindest verstehen, wenn nach einem gpupdate /force die soeben, vorgenommen Einstellung in der "local security policy" wieder weg ist.

 

Und, dies würde dann auch Sinn ergeben, weil die besagte Sophos STAS Software auf dem DC mir nie "Live Uers anzeigt" und es würde auch Sinn ergeben, weil nach wie vor nie in der Ereignisanzeige unter Security die Event ID 4768 auftaucht, Kunstück, wenn der DC meine Einstellung(en) nie akzeptiert, was soll das?

 

Noch als Ergänzung:

Ich hatte meinen alten DC mit Server 2016 abgelöst, demoted und voilà. Die AD Migration (DC Migration) von 2016 auf Server 2022 verlief ohne Fehler, alles funktioniert soweit, alle Objekte, alle GPOs, alles ist da, alles im Netlogon Share ist wieer da bzw. noch immer da, keine Fehlermeldung, nichts.

 

Aber diese Sache hier, dass mein DC Einstellungen in der Local security policy einfach nicht speichern will, finde ich jetzt schon heftig und passt mir security technisch gar nicht bvzw. mahct mir gerade extrem nachdenklich, was da security technisch los ist?

 

Jemand schon mal sowas erlebt?

Ich meine, Logins zu auditieren, ist eingentlich eines der ersten Dinge, welche man aktivieren sollte, wenn man  Security mässig die IT-Infrastruktur "überwachen" will bzw. eben, für mein Vorhaben, wie ich eingangs erklärt habe.

 

cheers

André

[NorbertFe 1.800]

vor 55 Minuten schrieb andrew:

Aber diese Sache hier, dass mein DC Einstellungen in der Local security policy einfach nicht speichern will, finde ich jetzt schon heftig und passt mir security technisch gar nicht bvzw. mahct mir gerade extrem nachdenklich, was da security technisch los ist?

 

Was gibt dir denn eigentlich ein rsop oder ein gpresult aus? Da sollte im Report ja drin stehen, ob die Richtlinie zieht oder nicht.

[andrew 15]

Hallo Norbert

 

Danke für die schnelle Antwort. Das war wirklich ein guter Denkanstoss.

1. Konfiguration in der Policy "local security policy" vorgenommen, danach gpupdate /force.

2. rsop.msc mit Admin Rechten ausgeführt, Resultat: Beim Eintrag "Audit Account Logon Events" steht: "not defined"

3. In der GPO "Default Domain Controller Policy" den Eintrag vorgenommen (siehe anbei den Screenshot).

4. rsop.msc mit Admin Rechten ausgeführt. Resultat siehe anbei den Screenshot.

 

Frage

Wo finde ich noch Infos, wenn das besagte File (nach Ausführung von rsop.msc) NICHT wie es sein sollte, hier finde? %windir%\security\LOGs\winlogon.log (siehe Screenshot)

Aus irgendeinem Grund kann der DC Server 2022 anscheinend diese Einstellung nicht anwenden, das würde eben in diesem LOG stehen, nur warum ist das nicht dort?

[NilsK 2.785]

Moin,

 

Zu dem konkreten Problem kann ich nichts beitragen, aber mir kommt die Beschreibung der Funktion sehr abenteuerlich vor. Bist du sicher, dass das so funktionieren soll? Mit ist völlig schleierhaft, warum eine Firewall die Login-Events auslesen soll, wenn sie eigentlich Gruppenmitgliedschaften prüfen soll. Das könnte sie auch völlig ohne Kontakt zum DC tun, wie alle anderen Rechner das auch tun.

 

Gruß, Nils

[cj_berlin 1.137]

vor 20 Minuten schrieb NilsK:

Zu dem konkreten Problem kann ich nichts beitragen, aber mir kommt die Beschreibung der Funktion sehr abenteuerlich vor. Bist du sicher, dass das so funktionieren soll? Mit ist völlig schleierhaft, warum eine Firewall die Login-Events auslesen soll, wenn sie eigentlich Gruppenmitgliedschaften prüfen soll. Das könnte sie auch völlig ohne Kontakt zum DC tun, wie alle anderen Rechner das auch tun.

Nö, das ist normal üblich. Eine herkömmliche Firewall kriegt ja keine Informationen zum Benutzer, der die Kommunikation auslöst, sondern nur die Quell-IP. Und um diese einem Benutzer zuzuordnen, überwacht sie Event 4624 auf sämtlichen DCs und nimmt die Zuordnung entsprechend vor. Gibt lustige Nebeneffekte, wenn man von einem Client RDP-Verbindungen mit anderen Accounts aufbaut und NLA aktiviert ist.

bearbeitet 4. September 2022 von cj_berlin

[andrew 15]

Hoi Nils

 

Tja, Sophos bzw. die Produktlinie XG von der Sicherheitsfirma Sophos hat zwecks Benutzer Authentifizierung 2 Lösungen bereit. 

Eine, von beiden Lösungen, die Variante, dass man auf einem DC die Sophos STAS Software installiert, bin ich nun am neu Installieren und versuche, die Sache wieder zum Laufen zu bringen.

 

Ich betone wieder, weil ich genau diese Lösung vor Jahren schon genau auf diese Art und Weise erfolgreich am Laufen hatte.

Nun, da ich gerade meine IT-Infrastruktur etwas auf Vordermann bringe Und: meine letzte Aktion, den alten DC mit Server 2016 auf Server 2022 zu migrieren anscheinend "schuld" an der Situation ist, suche ich natürlich nach der Ursache und wurde auch fündig, wie man im Screenshot oben sehr gut sehen kann.

 

Das heisst, ich habe das Gefühl, dass ich kurz davor bin, die Wahrheit zu erfahren, warum und wieso mein neue DC mit OS 2022 einfach diese Einstellung nicht setzen will (siehe oben im Screenshot, die Fehlermeldung) und genau das ist schleierhaft oder nicht? Oder findest Du das normal und oder hast Du diesen Fehler schon mal erlebt?

 

Nils, da hier ist der offizielle Sophos Support Artikel, wie und warum man eine Software mit dem Namen Sophos STAS installiert.

Der Links ist hier

Und da ist noch eine grafische Erklärung, ;) der Link ist hier

 

Nils, erlaube mir jedoch folgende Bemerkung bzw. Wunsch: Mir wäre es lieber, wenn Du nun nicht die Lösung vom Sicherheitshersteller Sophos in Bezug "wie AD Benutzer/ Gruppen" in einem Netzwerk authentifizieren, hinterfragst, sondern: dass Du z.B. zu meinem Problem, bei welchem Du schon mitgeteilt hast, dass Du nichts beitragen könntest, trotzdem kurz Stellung nimmst: Könnte es sein, dass mein AD irgendwie, einmal kompromittiert wurde oder kompromittiert worden sein könnte und jetzt zwar die AD Migration vom Server 2016 auf den neuen Server 2022 ohne Probleme lief, aber da irgendwie ein Bock drin ist oder wäre? Wo, würde ja, wie oben im Bild zu sehen, eigentlich in dieser besagten winlogon.log Datei stehen.

 

Doch warum ist die auch nicht dort, wie Du im Screenshot sehen kannst?

Das macht mich sehr nachdenklich, da ich ein sehr sicherheitsbedachter Mensch bin und mich das gerade sehr stresst

 

Nils, Du weisst doch sicher, so wie ich Dich kenne, wo in der Ereignisanzeige ich zu meinem Problem noch weitere Informationen finde. Oder gibt es nicht sonst noch irgendeine LOG Datei, welche mir da mehr Details liefert?

 

 

 

 

 

 

[NilsK 2.785]

Moin,

 

Nun mal langsam. Ich wollte niemandem zu nahe treten, sondern nur meine Vermutung äußern, dass hier evtl. in der falschen Richtung gesucht wird. Da ich mit Firewalls nicht viel zu tun habe, habe ich darauf auch hingewiesen. Anscheinend war meine Vermutung nicht korrekt, dann ist sie ja auch hinfällig.

 

Zu dem eigentlichen Problem kann ich trotzdem nichts beitragen. Dass das AD kompromittiert sei, halte ich momentan für unwahrscheinlich.

 

Gruß, Nils

 

 

 

[andrew 15]

Ich mache ja langsam, ich bin ein Berner (in der Schweiz ist die Hauptstadt Bern) und die sind ja eigentlich bekannt, dass Sie langsam sind oder anders gesagt, halt eher gemütlich unterwegs sind

 

Wenn du jetzt wie ich vor diesem Problem stehen würdest, wo würdest du noch nach möglichen Informationen suchen, um mehr über das vorliegende Problem zu erfahren?

Oder muss ich jetzt gleich mein ganzen AD über Bord werfen und auf grüner Wiese von vorne anfangen?

 

Als ich über dieses Problem im Internet nach Lösungsvorschlägen gesucht habe, fand ich doch tatsächlich auch eine Person, welche wie ich auch die Einstellung "Audit account logon events" unter Computer Configuration\Policies\Windows Settings\Security Settings\Local Policy\Audit Policy sowohl für "success" als auch für "failure" aktivierte, aber der DC diese Einstellung nicht speicherte.

 

Jedoch war dort leider nichts weiter darüber berichtet, wie das Problem schlussendlich gelöst wurde bzw. ob es überhaupt gelöst werden konnte?

Tja, darum bin ich nun hier, in der Hoffnung, dass ich mit euer Hilfe das lösen kann  

 

 

bearbeitet 4. September 2022 von andrew

[andrew 15]

Hi all

 

Ich beziehe mich nun auf mein Bild, welches ich ein paar Zeilen weiter oben gepostet hatte. 

Dort sieht man ja, dass nach dem Ausführen des Befehls rsop.msc ein Fehler generiert wurde und dazu ein Hilfetext erscheint, man müsse im Pfad %windir%\Security\LOGs\ 

die Datei winlogon.log öffnen (mehr Details).

 

Ich stellte die Frage, warum am besagten Ort keine winlogon.log Datei vorhanden sei?

Nun habe ich herausgefunden, dass man zuerst im Registry einen Wert verändern muss, damit das Login aktiv wird und eben diese LOG Datei generiert wird (die LOG Datei wird generiert, sobald eine Änderung in einer GPO vorgenommen wird.

 

Der Wert ist ein DWORD Eintrag und hat Default mässig den Wert 0. Damit das Loggen aktiv wird, muss man den Wert auf 2 ändern (gibt hierfür einen MS Support Artikel).

Pfad zum DWORD mit dem Namen ExtensionDebugLevel ist hier Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}

 

In dieser winlogon.log Datei steht nun angeblich? Warum und wieso mein Server 2022 DC die GPO Einstellung (siehe dazu am besten wieder mein Bild oben im Beitrag) NICHT anwenden will/ kann (da Fehler)

 

Anbei der Auszug der winlogon.log Datei

 

Inhalte gelöscht, zukünftig als Anhang beifügen.

 

winlogon.txt

[zahni 521]

Auf einem DC konfiguriert man nichts in der lokalen Richtlinie,.

Entweder Default Domain Policy (für Kennwortrichtlinien die 1. Adresse) oder in der Default Domain Controllers Policy.

[BOfH_666 568]

vor 34 Minuten schrieb andrew:

Anbei der Auszug der winlogon.log Datei

 

Nur mal 'n Tipp zur besseren Lesbarkeit solcher Auszüge hier im Forum: wenn Du das als Code formatierst - in diesem Fall einfach ohne Syntaxhervorhebung, weil es ja nicht wirklich Code ist - dann ist es für die, die es wollen, leichter zu "Konsumieren/Kopieren/Einfügen" usw. und es gibt keine ungewollten Zeilenumbrüche und so ...  und für die, die es nicht wollen, aber vielleicht trotzdem mitlesen, stört es nicht so extrem und man muss nicht so viel scrollen.

 

Danke schon mal im Voraus.  

 

[andrew 15]

Hallo Zahni

Danke für den Input. Ich habe dies nachträglich auch gelernt (da hatte ich die Überschrift für diesen Post schon getätigt resp. den Post).

Wie kann ich die Überschrift/ Titel dieses Posts hier noch ändern?

 

Wenn Du das Bild angeschaut hast, siehst Du, dass ich schlussendlich tatsächlich etwas gelernt hatte in der Hinsicht und darum die besagte Einstellung in der "Default Domain Controller Policy" vorgenommen (man sieht ja auch den Fehler dazu)

 

Ciao Bofh

Danke für den Input. Sorry wegen des "Code" bzw. dem langen LOG Auszug.

Ist gut, habe soeben in der "Werkzeugliste" nach dem entsprechenden Symbol gesucht (Code) und gefunden. Werde diesen Buton in Zukunft für solche Dinge benutzen

 

Willst Du/ kannst Du sonst noch etwas zum Inhalt der LOG Datei selber beitragen (was will mir die LOG Datei zusammengefasst, in 1 Satz mitteilen?)

[cj_berlin 1.137]

Ohne das jetzt geprüft zu haben: Du hast das Logging für Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A} (Security) hochgedreht, Dein Problem liegt aber im Bereich "Audit". Das wäre die GUID {F3CCC681-B74C-4060-9F26-CD84525DCA2A} ...

bearbeitet 5. September 2022 von cj_berlin

[andrew 15]

Saludos CJ

 

Hey, Du bist aber aufmerksam, super cool, thx. Ach so, ja, dann muss ich das Losging schleunigst anpassen, danke vielmals.

Mache ich jetzt gleich

Da im Pfad Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{f3ccc681-b74c-4060-9f26-cd84525dca2a} der DWORD Wert ExtensionDebugLevel NICHT vorhanden war, habe ich Ihn erstellt und wie vorhin auch mit dem Wert 2 versehen. DC neu gestartet und die Einstellung wie oben im Bild zu sehen, erneut in der "Default Domain Controller Policy" festgelegt, danach ein gpupdate /force ausgeführt.

 

Jedoch wurde dann nicht wie vorhin eine Log-Datei mit Namen winlogon.log im Pfad %windir%\Security\LOGs erstellt?

Wenn ich dann google bemühe und sage, such mal nach {f3ccc681-b74c-4060-9f26-cd84525dca2a} und ExtensionDebugLevel suche, finde ich irgendwie nichts Brauchbares.

 

Nur div. Webseiten, welche von Malware bzw. Trojaner was schreiben?!

Kann es sein, dass hier Microsoft wieder für jede GUID eine andere Möglichkeit vorsieht, um diese zu loggen (hier wäre es der Audit Bereich der GPO)?

[zahni 521]

Zitat

Damit dies funktioniert, funktioniert die Sache im Groben so, dass man auf dem Domaincontroller ein Stück Software (Sophos STAS) installieren muss (oder auf einem Memberserver) und diese dann z.B. auf dem Domain Controller die Logon/ Logoff Audit Einträge der Ereignisanzeige des DCs ausliest, der FW weiterleitet und diese dann auf Grund dessen weiss, dass dieser AD User, welcher auf der Webseite xy am Surfen ist, ob das erlaubt ist oder nicht.

Wenn das wirklich so ist, was ich nicht glaube, halt ich das für groben Unfug.

Proxies verwenden meist NTLM oder besser Kerberos zur Benutzeranmeldung. Da wird nicht aus dem Eventlog gelesen, sondern vom Windows höchstens geschrieben.