none
Applocker vs. Local Group Policy Processing vs. SCCM Defender Management RRS feed

  • Frage

  • Hallo zusammen,

    leider bin ich seit 4 Monaten mit dem Microsoft Support am Rummachen aber bisher ohne eine Lösung zu haben. Eventuell hat jemand hier eine Idee. Folgende Situation:

    wir haben Applocker im Einsatz, wird zentral via GPO konfiguriert, alles gut soweit

    irgendwann habe ich mitbekommen dass ein schlauer User (mit seinem zusätzlichem Adminkonto) lokale Applocker Richtlinien konfiguriert hatte, die auch noch funktioniert haben, Alarm!, Lösung gesucht und gefunden in der GPO "Turn off local group policy processing", dies aktiviert und schon wurden die lokal via gpedit.msc angelegten Applocker Regeln nicht mehr beachtet

    Soweit so gut, jetzt kommt die Krönung:

    wir haben von Symantec auf Defender umgestellt und konfigurieren diesen via SCCM damit wir ein halbwegs vernünftiges Management inkl. Berichtswesen im SCCM haben (Standard Defender on prem - kein Defender Endpoint Cloud Management).

    Leider wird die Konfiguration vom SCCM über lokale Richtlinien auf dem Client eingerichtet, dh. mit deaktiviertem Local GP processing funktioniert es nicht, die Regeln kommen einfach nicht an.

    Hat dafür jemand eine Lösung? Ich will auf jeden Fall vermeiden dass jemand die Applocker Regeln aufweichen kann aber ich hätte natürlich auch gerne die SCCM Defender Lösung.

    Ja ich kann den Defender auch rein via GPO einstellen aber ich möchte gerne SCCM dafür nutzen.

    Dienstag, 26. April 2022 14:37

Antworten

  • Neben Get-AppLockerPolicy gibt es ja auch Set-AppLockerPolicy. Wenn Du dafür eine XML, z.B. mit nut Standardregeln, vorgibst und kein -Merge angibst, überschreibt sie alles, was lokal gesetzt wurde, denn es gibt nur die eine LocalGPO.

    Warum die AppLocker-Regeln in der Registry des erstellenden Users Spuren hinterlassen, weiß ich nicht (vermutlich ist es eine Funktion des GP-Editors), aber bei mir werden sie anstandslos in den Maschinenzweig übertragen und dort mit den aus der GPO stammenden Regeln verschmolzen.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert Sascha Osdoba Freitag, 29. April 2022 16:52
    Mittwoch, 27. April 2022 16:59

Alle Antworten

  •  ein schlauer User (mit seinem zusätzlichem Adminkonto) 

    Das ist der Fehler.

    Ansonsten kannst Du die lokale AppLocker-Policy in regelmäßigen Abständen mit PowerShell setzen (https://docs.microsoft.com/en-us/powershell/module/applocker/?view=windowsserver2022-ps) . Und hatte SCCM nicht auch die Möglichkeit, AppLocker-Policies zu konfigurieren? (kann gerade nicht nachschauen) Die wären dann ja auch wieder lokal und würden die Eigeninitiative des User überschreiben.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 26. April 2022 14:50
  • Danke für deine Antwort.

    Wir sind ein Forschungsbetrieb und nicht mit einem normalen Unternehmen mit beschränkten Anwendungsset vergleichbar daher ist es betrieblich unabdingbar dass gewisse User neben ihrem Standardaccount auch einen Adminaccount haben. Nicht schön und es wurde schon kräftig aufgeräumt aber betrieblich notwendig.

    Back to topic:

    die Speicherorte für die Applockerregeln sind ja unterschiedlich und daher "überschreiben" zentrale Richtlinien nicht die die der User manuell gesetzt hat daher ist die Art und Weise der Implementierung also GPO oder SCCM unerheblich, ja der SCCM kann auch Applockerregeln setzen, macht ja aber keinen Unterschied

    Ich könnte mit get-applockerpolicies -local und dem Schreiben der XML Konfig natürlich prüfen wo evtl. an einem Client etwas eingestellt ist aber das ist halt eher nervig. Oder aber lokal vorhandene Applockerregeln nullen aber das scheint mir so auf den ersten Blick nicht direkt von MS vorgesehen zu sein

    Dienstag, 26. April 2022 17:53
  • Nicht schön und es wurde schon kräftig aufgeräumt aber betrieblich notwendig.

    Wenn ich jedesmal 5 Euro kriegen könnte, wenn ich das höre, wäre ich schon lange Millionär. Aber besser noch: Jedesmal, wenn einer von euch das sagt, legt vorsorglich 5 Euro in BTC an. Dann habt ihr am Ende nämlich BTC, wenn es ans Zahlen von Ransom geht, schon am Start ;-) 

    Ich konnte leider immer noch nicht nachschauen, was genau SCCM mit AppLocker macht - kann sein, dass nur WDAC gemanagt wird und nicht AppLocker. Wenn da aber überhaupt eine Verwaltung dafür vorgesehen ist, dann wird sie ja auch nur über LocalGPO erfolgen und damit das, was die User machen, überschreiben.

    ABER.

    Wenn Du gewissen Usern schon erlaubst, eigenständig Software zu installieren, ist es denn nicht wichtig und notwendig, dass sie dafür auch AppLocker-Ausnahmen definieren können? Denn sonst würde deren selbst installierte Software ja gegen die zentralen AppLocker-Richtlinien knallen, und Du hättest wieder Tickets...

    Wenn eure zentrale AppLocker-Policy allerdings eh alles zulässt, was in %ProgramFiles% ist, spricht überhaupt nichts dagegen, per Remediation Action oder gar per Scheduled Task die lokale GPO zu nullen...


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 27. April 2022 08:26
  • Also ich will da kein Nebenschauplatz aufmachen weil das hier ja nicht das eigentliche Thema ist aber ja es geht leider nicht anders - zuvor war hier die Mentalität 'jeder bekommt auf Zuruf Adminrechte' und das haben wir erfolgreich angepackt. Aber ja, es muss weiterhin geforscht werden können und dafür müssen manche Anwender nachts um 3 Uhr auch Software installieren können oder 2 neue USB2LAN Adapter inkl. IP Konfiguration machen können oder sonstigen Kram der eben Adminrechte erfordert.

    Seit Windows 10 und Applocker hatten wir bisher nicht einmal Ransomware, vor allem dank Applocker und Office Makro Einschränkungen.

    Den Adminusern ist es erlaubt Software zu installieren und dies sollen sie nach %ProgramFiles% machen und nirgendwo andershin (weil dann die Ausführung mit dem Standarduser nicht gestattet wird).

    Änderungen von Sicherheitsrichtlinien sind Ihnen schriftlich verboten aber ja ich weiß ist Theorie :) daher mag ich GPOs weil dann bestimmte Dinge eben auch als Admin nicht machbar sind. Und Tickets bzgl. Regeln zum Applocker weil Software XYZ nicht funktioniert, werden idR sehr schnell und mit Prio abgearbeitet.

    Das Hauptproblem ist doch aber dass zentrale und lokale Applockerregeln gemergt werden anstatt nur die zentralen Regeln zu nutzen wenn denn welche konfiguriert sind.

    Habe mir eine lokale Applockerregel erstellt und dann die Registry durchsucht, die Regel ist nur unter:

    Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{592D31C5-400F-4917-A3BD-65A0D2BEC355}Machine\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe\189ced46-6ba2-4a19-bf76-0368a5958f02

    Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{9A5C9F12-C796-442D-9FFD-DBB397FC2E7F}Machine\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe\189ced46-6ba2-4a19-bf76-0368a5958f02

    zu sehen (HKCU ist hier mein Adminuser)


    Die zentralen Regeln sehe ich unter:

    Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2

    und da gibt es keinen Eintrag zu dieser von mir lokal angelegten Regel.

    Wieso wird also die lokal unter meinem Adminuser angelegte Applockerregel von meinem Standarduser überhaupt beachtet? Irgendwoher muss er diese ja auslesen können und Registry kann es nicht sein, da mein Standarduser doch keinen Zugriff auf HKCU des Adminusers hat


    Wie kann ich die selbst angelegten Applockerregeln nullen?


    Mit Get-Applocker -local kann ich mir diese in eine Datei schreiben lassen, das kann ich als Task einrichten und die Ausgabe auf einem Share abspeichern lassen und dann auswerten aber Aufwand :)

    SCCM stellt WDAC zur Verfügung, könnte man mal testen ob das vom Handling anders funktioniert.

    Mittwoch, 27. April 2022 15:55
  • Neben Get-AppLockerPolicy gibt es ja auch Set-AppLockerPolicy. Wenn Du dafür eine XML, z.B. mit nut Standardregeln, vorgibst und kein -Merge angibst, überschreibt sie alles, was lokal gesetzt wurde, denn es gibt nur die eine LocalGPO.

    Warum die AppLocker-Regeln in der Registry des erstellenden Users Spuren hinterlassen, weiß ich nicht (vermutlich ist es eine Funktion des GP-Editors), aber bei mir werden sie anstandslos in den Maschinenzweig übertragen und dort mit den aus der GPO stammenden Regeln verschmolzen.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert Sascha Osdoba Freitag, 29. April 2022 16:52
    Mittwoch, 27. April 2022 16:59
  • Habe gestern nochmal mit dem MS Support gesprochen, es gibt dafür wohl aktuell keine Lösung. Ich soll es denen mal ausführlich dokumentieren - keine Ahnung was daran insgesamt nicht verständlich ist - und dann soll an die Produktentwicklung weitergegeben werden. Keine Ahnung ob ich das glauben kann aber Versuch macht kluch.

    Als Workaround habe ich jetzt per SCCM den Export der Local Applocker GPO XML per Get-AppLockerPolicy auf ein zentrales Logshare gescriptet und dann schau ich mal nach ob ich weitere betroffene Geräte habe und dann einen Scheduled Task per GPO erstellt der via Set-AppLockerPolicy dann die lokale wieder nullt.

    Danke für die Unterstützung

    • Als Antwort markiert Sascha Osdoba Freitag, 29. April 2022 16:52
    • Tag als Antwort aufgehoben Sascha Osdoba Freitag, 29. April 2022 16:52
    Freitag, 29. April 2022 16:52
  • Frei nach Gertrude Stein: Ein Administrator ist ein Administrator ist ein Administrator.

    Was willst du gegen Gott machen? Die Antwort lautet: DEINE! GPO Applocker Richtlinie wird immer gewinnen, da sie später läuft. Du must also in deiner AD das Gegenteil von dem definieren, was der User einstellt.
    Ansonsten wird es immer ein Merge und eine Addition der Werte, was in dem Konzept der Gruppenrichtlinien Infrastruktur explizit so gewünscht ist.

    Dienstag, 31. Mai 2022 20:12
  • Ja aber :)

    wenn man es mal durchdenkt wäre es für MS ziemlich einfach eine zusätzliche Richtlinie einzubauen die besagt, verarbeite keine lokalen Applockerrichtlinien (und es nur auf Applocker einschränkt) so wie es eben auch die Einstellung gibt keine lokalen GPOs zu verarbeiten oder keine lokalen Firewalleinstellungen. Also machbar ist das mit Sicherheit, es müsste halt nur jemand an das Szenario denken und dann machen.

    Donnerstag, 2. Juni 2022 06:04
  • Also machbar ist das mit Sicherheit, es müsste halt nur jemand an das Szenario denken und dann machen.

    Es gab mal das Konzept der "Power User", das allerdings nicht sehr lange gelebt hat, unter anderem auch weil es nicht wirklich durchdacht war. Seit dieses beerdigt wurde, ist die Haltung von Microsoft hier sehr eindeutig: User ist User (und kann nichts) und Admin ist Admin (und kann alles). Und da braucht es auch keine Sonderlocken für jedes einzelne Subsystem.

    Aber hey, Feedback geben --> Feedback-Hub. Wenn genug Leute das haben wollen, wird jemand das auch umsetzen.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Donnerstag, 2. Juni 2022 06:51
  • Ein Administrator kann Applocker immer umgehen, egal was Du vorgibst. Googel mal: bypass applocker

    Sind sehr interessante Seiten dabei :)


    • Bearbeitet -harry Dienstag, 9. August 2022 13:23
    Dienstag, 9. August 2022 13:22
  • https://github.com/api0cradle/UltimateAppLockerByPassList

    das finde ich gut, ein paar der Workarounds sind ja Standard wie zB beschreibbare Ordner im %windir% oder aber auch PowershellV2 die ja aber relativ easy angegangen werden können und bei uns auch sind. Aber manches davon kannte ich noch nicht, daher danke für den Tipp.

    Und ja, 100% Sicherheit gibt es nie aber deswegen ist Applocker ja an sich nicht schlecht sondern trotzdem empfehlenswert - zumindest mMn.

    Dienstag, 9. August 2022 13:30