[English]Hinweis für Administratoren im Windows-Umfeld, die noch auf Software Restriction Policies (SRP) setzen. Dieses Sicherheitsfeature ist bereits seit 2020 abgekündigt (deprecated), wird in Windows 10 bisher aber noch unterstützt. Aber mit Windows 11 Version 22H2 ist definitiv Schluss mit der Verwendung der Software Restriction Policies (es gibt mehrere Bestätigungen, dass dieses Feature nicht mehr zuverlässig funktioniert) – stattdessen sollte App-Locker eingesetzt werden.
Anzeige
Software Restriction Policies (SRP) abgekündigt
Software Restriction Policies (SRP) sind ein Mechanismus, mit dem Administratoren in Windows über Richtlinien festlegen konnten, welches Software im Betriebssystem ausgeführt werden darf. Die Software Restriction Policies sind bereits seit Windows Server 2003 verfügbar und stehen aktuell (laut dieser Microsoft Seite) noch unter folgenden Server-Varianten zur Verfügung:
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
Zudem werden Software Restriction Policies in Windows-Clients (Windows 7, Windows 8.1, Windows 10, Windows 11 21H1) unterstützt. Hier im Blog wurde ja gelegentlich (auch von Stefan Kanthak) auf die Verwendung von Software Restriction Policies zur Härtung des Systems hingewiesen (zum Beispiel hier). Das von Stefan Kanthak entwickelte und auf dieser Webseite von Schneegans propagierte SAVER ließ sich zur Absicherung gegen Schadprogramme (auch Ransomware) einsetzen.
Allerdings hatte Microsoft die Software Restriction Policies (SRP) bereits im Juni 2020 abgekündigt (siehe meinen Blog-Beitrag Windows 10 Version 2004: Veraltete/entfernte Features). Microsoft schrieb bereits zur Windows 10 Version 1803:
Software Restriction Policies in Group Policy: Instead of using the Software Restriction Policies through Group Policy, you can use AppLocker or Windows Defender Application Control to control which apps users can access and what code can run in the kernel.
Auch der am 2. November 2022 letztmalig aktualisierte Microsoft-Beitrag Deprecated features for Windows client führt die Software Restriction Policies als deprecated auf. Bisher wurden die Software Restriction Policies (SRP) aber noch in Windows 10 sowie in Windows 11 Version 21H1 unterstützt. Aber durch die Abkündigung sollten Administratoren längst gewarnt sein, dass diese Sicherheitsfunktion irgendwann versagt.
Anzeige
SRP in Windows 11 22H2 ohne Funktion
Ich bin gerade auf Twitter über nachfolgenden Tweet von Will Dormann darauf gestoßen, dass Microsoft nun die Software Restriction Policies (SRP) geschlachtet hat.
Will Dormann schreibt, dass die Liste der Sicherheits-/Verteidigungsmaßnahmen in Windows, die scheinbar nichts bewirken inzwischen recht lang sei. Neu hinzugekommen sind die Software Restriction Policies (SRP), die ab Windows 11 22H2 nichts mehr zu bewirken scheinen. Er schließt mit dem Satz: Hoffentlich verlässt sich niemand auf diese Funktion!
Ich gehe davon aus, dass die Blog-Leserschaft längst Bescheid weiß und sich von Software Restriction Policies verabschiedet hat. Falls nicht, denkt beim Einsatz von Windows 11 an diese Falle. Mal schauen, wann das Feature bei Windows 10 gekippt wird.
Ergänzung: Wegen der Diskussion hier im Blog und einem Kommentar von Mark Heitbrink in einer Facebook Administratorengruppe habe ich bei Will Dormann nachgefragt (ich habe kein Win 11 22H2). Die Antwort kann auf Twitter hier nachgesehen werden.
Er hat ein System, wo das Ganze funktioniert – bei anderen Systemen funktioniert SRP nicht.
Ergänzung: Auf administrator.de gibt es diesen Thread von Nov. 2022, wo das Problem unter Windows 10 22H2 Probleme macht – da wird alles von SRP geblockt.
Ergänzung 2: Die Software Restriction Policies (SRP) lassen sich auch in Windows 11 22H2 weiterhin verwenden. Man muss lediglich einen Eintrag in der Registrierung, der von Microsoft die SRP-Ausführung (fälschlich) verhindert, löschen. Die Details lassen sich im Blog-Beitrag Software Restriction Policies (auch SAFER) weiterhin unter Windows 11 22H2 möglich … nachlesen.
Anzeige
Wird per LINUX gelöst.
Fake News :-)
sie funktionieren hier immer noch und sind weiterhin der erste kleine Schritte gegen Ransomware.
ausführbare Dateien in meinem Userprofil werden erfolgreich geblockt, wie in der Blocklist von SRP definiert
Mag sein – aber Will Dormann testet normalerweise schon sehr genau. Möglicherweise kommt was mit Moments 2. Der Beef des Artikels ist aber, Administratoren darauf hinzuweisen, dass sie unter einem Damokoles-Schwert sitzen, wenn sie weiter auf SRP setzen.
Wie "fake" diese News sin, sollte man auf 2 Wege testen: clean install von 22H2 und Upgrade Install von 22H2 (z.B. von 1709, wo es ja offiziell noch supportet war). Das kann Unterschiede machen. Ich verlinke gleich weiter unten noch eine Anleitung zu Applocker für Win10/11 Pro.
Ich sehe es eher so, dass wer weiter auf Windows setzt, unter einem Damokles-Schwert sitzt.
@Chris: Wieder so ein überflüssiger Kommentar, der nichts zur Diskussion beiträgt, aber einen überheblichen Unterton hat.
Es gibt viele Gründe, warum Leute bei Windows sind oder bleiben müssen. Das hat aber mit dem Thema hier nichts zu tun.
@Günther: Danke nochmals für den Hinweis. Ergänzt ganz gut den Artikel in der c't zur Sicherheitssituation unter Windows.
AMEN!
M$FT dokumentiert SRP unter https://learn.microsoft.com/en-us/windows/deployment/planning/windows-10-deprecated-features weiterhin nur als "deprecated" und unter https://learn.microsoft.com/en-us/windows/deployment/planning/windows-10-removed-features NICHT als "removed", d.h. SRP funktionieren weiterhin.
Im ersten Artikel stehen (schon seit Jahren) die folgenden Sätze: "This article provides details about the features and functionalities that are no longer being developed in Windows client." sowie "The features in this article are no longer being actively developed, and might be removed in a future update.", d.h. es findet keine WEITERENTWICKLUNG statt, aber sie werden (noch) NICHT entsorgt.
Also: VIEL LÄRM UM NICHTS!
Naja, es geht bei der Abkündigung ja um Windows 11 22H2. Bei Windows 10 ist es weiterhin da. Wäre aber trotzdem mal interessant, zu testen obes unter 22H2 wirklich nicht geht. Wäre doof, denn so kann man auch Privat-PCs gut absichern.
Test und Verwunderung:
Neuinstallation, Standard ISO, keine Volumen CD, Installation Professional Edition in Workgroup und in AD. SRP Richtlinien "Alle Dateien, Alle Benutzer und Zertifikate", Regelwerk: %userprofile%\*.exe, %userprofile%\*\*.exe = nicht erlaubt. sowohl in AD als auch LGPO.
Schock: Dateien werden NICHT geblockt.
Mein erster Blick war auf meine vorhandene Installation die auf 22H2 aktualisiert wurde. Da ist SRP immer noch aktiv.
Da biste baff …
Mark, danke für den zusätzlichen Test.
Moin Mark.
Glaub mir, wenn ich ein wenig in meinem Gedächtnis und meinen Threads bei Administrator.de krame, kann ich dir mindestens drei weitere Features nennen, die bei Upgrades laufen und bei Neuinstallationen nicht. Baff war ich beim ersten Mal auch, beim zweiten Mal verärgert und beim dritten Mal nur noch bestätigt in meiner Meinung, dass MS schlecht testet.
Danke für die Bestätigung.
Ursache der ganzen, VÖLLIG UNNÖTIGEN Aufregung ist die übliche grenzenlose Schlamperei in Redmond: VOLLIDIOTEN haben in den Installationen, die M$FT in die \sources\install.wim/esd schaufelt und dann in ISO/UDF-Dateien verpackt, AppLocker aktiviert. DUMMERWEISE wurden die dabei erstellten Registry-Einträge beim "Generalisieren" der Installationen vor dem Ziehen der Abbilder NICHT vollständig entsorgt.
Ssiehe dazu https://www.microsoftpressstore.com/articles/article.aspx?p=2228450&seqNum=11, insbesondere dass DLL-Regeln standardmässig NICHT genutzt werden: der Praktikant, den sie in Redmond die Generalisierung haben frickeln lassen, hat's dummerweise wörtlich genommen, daher werden die Registry-Schlüssel [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp\DLL] und Registry-Einträge unter [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp] NICHT entsorgt.
Die mit solchen VERSAUTEN Installationsabildern aufgesetzten Systemen verhalten sich dann wie dokumentiert: die (kaputten) AppLocker-Einträge aktiveren dieses, allerdings funktionslos, und deaktivieren SAFER!
ABHILFE: Löschen der o.g. Registry-Schlüssel/Einträge.
PS: Rechnungsstellung an Herrn Satya Nadella, ggf. mit ein paar Megatonnen beschwert!
Der Knackpunkt für mich ist: SRP funktioniert auch ohne Windows Enterprise. App Locker nicht.
So ist es bei mir auch. Ich nutze noch ein nicht W11 kompatibles Laptop mit W10 pro und auf diesem ist SRP eine meiner wichtigsten Säulen zur Absicherung. Dieser WDAC traue ich lange nicht so wie Safer (Konfiguration von Stefan Kanthak).
Mit dieser Neuerung überlege ich mir einen Wechsel auf W11 ganz genau.
Das ist der neue Trend, weil man mit Security im Moment gut Geld verdienen kann. Windows gibt es quasi umsonst (Home), willst Du es aber einigermaßen sicher haben, dann geht das nur noch gegen den Einwurf von Münzen.
Man nennt es auch On-Top-Security. Es muss immer noch etwas zustätzliches installiert werden, damit es sicher wird. Dieses Zusätzliche lässt man sich gut bezahlen. Ist vermutlich viel luktrativer als für Security by design und default zu sorgen.
Gruß Singlethreaded
Also ich kann damit leben, wenn gewisse Features nur gegen "Münzeinwurf" zusätzlich erhältlich sind. Aber gerade bei der Sicherheit will ich keine Kompromisse eingehen müssen.
Dann sollen sie von mir aus SRP oder Applocker nur ab Pro noch funktionsfähig halten, aber generell abschaffen?! Und was für On-Top-Security ist das? Was bietet Microsoft da an? Drittanbieter Tools kämen bei mir nicht in Frage.
Und umsonst ist Windows im Normalfall ja auch nicht. Mein Laptop läuft offiziell mit W11 nicht, daher müsste dann ein neues her, bei dem man die Lizenz ja mitbezahlt.
Es geht da nicht um Home oder Pro, es geht um die Enterprise-Variante, und die bekommen nur Firmen ab einer bestimmten Größe.
Das Problem ist, gerade die großen Firmen haben auch die Spezis um sowas zu konfigurieren, und die haben noch andere Möglichkeiten, Application-Control in diversen Antiviren-Enterprise-Produkten.
Aber die kleinen Firmen, die Enterprise nicht bekommen können, und die Home-User, die haben ohne SRP garnichts mehr, wenn sie es denn je benutzt haben.
Fast zumindest
"Richtlinien, die über GP bereitgestellt werden, werden nur in Enterprise- und Server-Editionen unterstützt.
Richtlinien, die über MDM bereitgestellt werden, werden in allen Editionen unterstützt."
https://learn.microsoft.com/de-de/windows/security/threat-protection/windows-defender-application-control/feature-availability
Würde vermuten, dass per GPO direkt gesetzte Registry-Schlüssel demnach auch funktionieren müssten.
Ja, man kann SRP komplett per Regkey in GPOs steuern, ist etwas mühsam einzurichten, aber geht.
Hier noch ein kleiner Tipp zum Thema Applocker
4sysops Posts Forums Community Sitemap About Login Enable AppLocker on Windows 10 Pro and Windows 11 Pro with PowerShell
Du kommst mir zuvor, das wollte ich auch gerade verlinken.
Nochmal ganz deutlich: das ist der einzige Weg, wie es per GPO auch auf Win10/Win11 pro deployed werden kann!
Wow Danke, ist zwar viel Bastelei, aber scheint wohl doch eine Möglichkeit zu geben es unter Windoes Pro zu nutzen, ob das aber wirklich Business tauglich ist, ist fraglich.
Der quasi Nachfolger WDAC soll ja auch mit Windows Pro gehen, auch wenn das dort angeblich auch wieder Recht umständlich gelöst ist.
@Michael
"Wow Danke, ist zwar viel Bastelei, aber scheint wohl doch eine Möglichkeit zu geben es unter Windoes Pro zu nutzen, ob das aber wirklich Business tauglich ist, ist fraglich."
Viel Bastelei? Sorry, hast Du das nur überflogen oder schon versucht? Die "Bastelei" beschränkt sich auf das domänenweite Verteilen eines Tasks, der mein Skript startet, dafür brauchst Du einmalig pro Domäne eine Minute. Abgesehen davon arbeitet es vollkommen gleich zu Enterprise.
Hab mir das mal angeschaut. Sehr interessant für Domänen, in denen es auch oder nur Pro Lizenzen gibt. Für den normalen Heimuser leider untauglich.
"Für den normalen Heimuser leider untauglich." – du irrst. Du kannst es genau so auf Win10 Pro ohne Domäne benutzen, wie mit Domäne. Du etablierst diesen Task und fertig. In der Domäne nimmt man einen immediate Task, der durch den GPO-Background Refresh immer neu erstellt und sogleich abgefeuert wird. Um das ohne Dom. nachzubauen, musst du den Tasktrigger eben an das Event ketten, welches geloggt wird, wenn die veränderten Applockerrichtlinien eingelesen werden. Nicht schwer. Ich werde meinen Artikel demnächst darum ergänzen.
Ergänzung: schnell nachgesehen: Eventlog ProviderName: Microsoft-Windows-GroupPolicy, Event 4004 (Starting manual processing of policy…) – das wird stets geloggt, wenn du bei Applocker was veränderst. Somit muss man bloß davon das Skript triggern lassen.
Also ich finde das ganze höchst suspekt!!!
Windows 11 22h2 ist doch eben gerade genau das Windows welches dieses neue "Smart App Control" (SAC) mitbringt. Und intern scheint genau dieses Feature über SRP realisiert zu sein, zumindest greifen, wenn das nicht aus ist, alle Prozesse auf "\Device\SrpDevice" zu.
Ich vermute ja mal, dass MSFT-Leute Richtung "Eier beim Setup abgeben und SAC aktivieren" pushen will. Daher wird die Möglichkeit, eigene SRP Richtlinien zu definieren, kastriert. Mit SAC darf nur laufen, was die MSFT-Cloud erlaubt.
Ich habe das mal in einer jungfräulichen VM getestet, und wenn SAC an ist ist es nicht möglich, irgendwas unsigniertes auszuführen, auch nichts selbst signiertes. Auch wen man das verwendete Zertifikat in die entsprechenden vertrauenswürdigen root cert listen importiert, stellt sich SAC quer.
Ich sehe es auch nicht ein, wieso ein Sicherheitsfeature kein Benutzer overwrite hat. Es ist in keinster weise zu rechtfertigen, wieso der Eigentümer des PC's nicht bei jeder beanstandenswürdigen Datei nicht die Möglichkeit haben sollte, auf "trotzdem ausführen" zu drücken.
Ich denke das MSFT da ganz brachial in Richtung Apple-fiziertem PC geht, auf dem man nur noch das ausführen darf was MSFT erlaubt.
Noch ist SAC (Smart App Control) optional, aber dann auch gleich so gemacht, dass man es nur ein für alle mal ausschalten kann.
Für mich riecht das danach, dass man in Zukunft auf PC's, wo sich der Benutzer erdreistet hat, SAC zu deaktivieren, kein netflix in voller Auflösung, keine blue rays und kompetitive online shooter erst recht nicht mehr benutzen wird können. Banking Apps und weiß der kuckuk was noch natürlich auch nicht.
Es gibt einfach keinen berechtigten Grund, wieso man SAC nicht nach Gusto jederzeit ein und wieder aus schalten können sollte, ok reboot mag sein.
Aber dieser Ansatz das man es wen es ein mal aus war nicht wieder aktivieren kann, stinkt 100 Meilen gegen den Wind, dass es hier um nugging und Benutzer-Manipulation geht.
MSFT will hier eine neue Norm etablieren, bei der SAC bei dem größten Teil der Konsumenten aktiviert ist, und wer kein SAC an hat, wird wie ein Benutzer 2ter klasse behandelt, so wie das schon heute bei Leuten mit aktiviertem driver test signing oder Kernel Debugger der Fall ist.
DRM regt sich auf, man wird wie ein Verbrecher behandelt, Spiele Konten werden gesperrt, etc, pp….
Ich empfinde es als Frechheit, dass eine Funktion die seit Windows XP recht gut funktioniert und ich auf ~100 Computer konfiguriert habe nun durch ein Zwangsupdate (das wird kommen) entfernt wird. Dass sie keine Support, mehr bieten ist mir egal.
War schon bei Office so, dass GPOs (z.B. blockieren von Makros) bei neueren Version nur noch in den teuren Version verfügbar sind.
Als KMU wird Windows und Office immer unerschwinglicher und dennoch ist man oft davon abhängig.
Darf mir ein Hersteller durch ein gratis Update gekauft Funktionalität wegnehmen?
Wäre da eine Sammelklage der richtige Weg?
Meine Herren, piano.
->es ist nicht mal sichergestellt, dass etwas verändert wurde (siehe mein Kommentar und das von Mark Heitbrink)
->es wurde seit Jahren von Microsoft angekündigt und empfohlen, nun Applocker zu nutzen
->Applocker geht auch auf Win10/11 Pro! Es ist der direkte Nachfolger ("SRPV2"). Hier noch einmal der Link zu meinem Artikel auf 4sysops: https://4sysops.com/archives/enable-applocker-on-windows-10-pro-and-windows-11-pro-with-powershell/
Es muss sich doch etwas verändert haben?
Oder wie soll man den Tweet von Will Dorman sonst interpretieren?
Ich hatte das so verstanden, dass bei seinen Tests zumindest neu angelegte Policies nicht mehr funktionieren?!
Sehe ich das falsch?
Ralph, ich schrieb doch: "siehe mein Kommentar und Mark Heitbrinks". Mark hat das Problem versucht nachzustellen und konnte es nicht bestätigen.
Ich habe dem hinzugefügt, dass möglichweise ein Funktionsunterschied besteht zwischen Windows XX22H2 wenn upgegradet und wenn neu installiert.
Verständlich?
Ich fasse mal bei Will Dormann nach – aktuell habe ich kein Win 11.
Ich bin über das selbe Problem Mitte Oktober gestolpert und konnte herausfinden, dass die SRP unter Win11 22H2 Pro bei mir nicht funktioniert haben: Richtlinien für Softwareeinschränkungen werden nicht angewendet
@Mark Heitbrink: Können wir uns bzgl. deiner und meiner Installation austauschen? Bei mir war es eine Neuinstallation in einer VM.
Beachte meine Ergänzung zur Antwort von Will Dormann. Warum einzelne Maschinen scheitern, die SRP aber bei anderen Maschinen funktioniert, liegt für mich noch im Dunkeln. Vielleicht kannst Du was mit Mark herausfinden.
Ein Tipp für jetzt-noch-umsteiger, also von SRP auf Applocker, natürlich nur, wenn man eine Enterprise-Lizenz hat. Man kann beides nämlich gleichzeitig konfigurieren, und je nachdem ob der Client Pro oder Enterprise Lizenz hat, benutzt er das jeweils verfügbare Regelwerk. Die mühsam erstellten SRP-Regeln kann man übrigens vielfach 1:1 in Applocker herüber kopieren, mit den erforderlichen Anpassungen funktionieren die Pfadregeln weiterhin problemlos. Ich habe das bei uns so gemacht, dass es ein Basis-Regelset für SRP gibt, und ein ausführliches für Applocker. Dann ist ein Client, der mit Pro Lizenz ins AD aufgenommen wurde, schonmal basisgeschützt, und schaltet automatisch auf Applocker um, wenn er eine Enterprise-Lizenz zugewiesen bekommen hat.
Ich habe derzeit nur eine Testinstinstallation von Windows 11 22H2. Dort funktionieren die SRP bei mir problemlos.
Auf dem PC ist eine saubere Neuinstallation, die ich am 14.10.2022 gemacht habe. Der Rechner ist in einer Server-2022-Domände und die SRP sind per Gruppenrichtlinien konfiguriert.
Ich denke, das ist ein seltsamer Bug, der unter gewissen Umständen auftritt und unter anderen nicht.
Ich hab 2x von der ISO aus dem Media Creation Tool auf einer Vmware WS installiert -> leider beide Male erfolglos. Domäne ist bei mir eine 2016, aber daran sollte es ja eigentlich nicht scheitern. Ist deine Installation direkt auf Hardware? Hast du Win 11 Pro oder Enterprise lizenziert?
Windows 11 Pro direkt auf Hardware. Mir ist gerade eingefallen, dass ich noch ein Notebook habe, auf dem es auch drauf ist. Die SRP funktionieren dort ebenfalls. Wundert mich aber nicht, weil das in der gleichen Umgebung identisch installiert wurde.
Enterprise oder Professional? Aus welchem Pool kommt die ISO? Volumen Lizenz?
VL habe ich noch nicht getestet …
Vorhin nochmal die aktuelle Win 11-iso direkt von der Windows-Homepage heruntergeladen.
– Frisch auf einer VM installiert
– Die dann installiert Build ist die 22621.525.
– Der Domäne beigetreten -> SRP funktioniert nicht
– Alle Online-Updates von MS geladen (am WSUS vorbei) und installiert: 22621.819 -> SRP funktioniert nicht
Die Richtlinien sind in beiden Fällen gezogen und werden über rsop.msc korrekt angezeigt. Die genau gleichen GPOs funktionieren auf einem 21H2 mit dem selben Benutzer und mit dem PC (auch VM) in der selben OE einwandfrei.
Enterprise oder Professional?
Professional
Von SRP hatte ich zwar schon vor vielen Jahren gelesen, mich allerdings bisher nie intensiver damit befasst. Mit Applocker wurde ich als Benutzerin schon mit mühsamen Einschränkungen beschenkt.
AppLocker als direkte Nachfolgelösung von SRP und Windows Defender Application Control sind primär für grosse Firmen ausgelegt. Aber wie 1ST1 erwähnt wurde, können diese Firmen in der Regel auch andere Möglichkeiten nutzen, während KMU und Private aussen vor bleiben.
Ich habe mir nun sowohl Stefan Kanthaks NTX_SAFER.INF und die ergänzenden Informationen von Schneegans, als auch die von Andreas F verlinkte Lösung für AppLocker genauer angeschaut. Beide Varianten helfen definitiv, Windows sicherer zu machen. Aber bei beiden gibt es Besonderheiten zu beachten, die im Umkehrschluss leicht zu Schwierigkeiten und unerwünschten Fehlern führen können. Dass sich manche Apps ins Benutzerverzeichnis installieren, ist nur ein Aspekt davon. Vermutlich verzichte ich darauf, eine der Varianten zu testen.
Zur Kritik von DavidXanatos bezogen auf die "Smart App Control" (SAC):
Meines Erachtens ist diese Lösung gar nicht so schlecht. Aber ich denke auch, dass es nicht eine "einmal für immer" Option sein soll, sondern dass man – als Administrator – die Funktion vorübergehend auch ausschalten können muss, so wie es z.B. bei der Firewall ist.
Der Haken bei SRP, um den es mir beim Blog-Beitrag ging: Ein Administrator muss sich darauf verlassen können, dass diese Sicherheitseinstellung auch zukünftig greift. Bei Windows-as-a-service ist das aber nicht mehr gegeben, weil a) Microsoft SRP als deprecated eingestuft hat und b) wir jetzt durch Will Dormann sowie einige der Kommentare hier festgestellt haben, dass SRP plötzlich nicht mehr funktioniert.
Warum es auf manchen Maschinen läuft, auf anderen nicht, liegt derzeit im Nebel. Da das Feature als "deprecated" eingestuft ist, wird Microsoft auch keine "Fehlersuche" mehr machen. Wie auch immer, in meinen Augen ist SRP damit gestorben, da nicht mehr zuverlässig nutzbar – man müsste nach jedem Update jeden Client checken, ob SRP noch tut – imho nicht wirklich praktikabel. Aber vielleicht sehe ich es zu kritisch.
Das musste ich natürlich sofort auch mal testen: saubere Neuinstallation von
Win 11 22H2 – Version: 22621.819
NTX_SAFER.INF installiert. Hier leider auch ohne Wirkung.
Hallo,
ich habe mir selbst ein SRP-Installations-Kit zusammengestellt. Es basiert
auf verschiedene Skripte (BAT, VBS, REG) und importiert die SRP-Regeln
direkt in die Registry, ähnlich wie es die Setup-Skripte von Stefan Kanthak
machen, aber in einer etwas abgeänderten Form mit nur den unbedingt
notwendigen Registry-Einträgen (z.B. ohne "LastModified" RegValue).
Übrigens haben die Skripte von St. Kanthak diverse Fehler enthalten,
die ich bei genauer Durchsicht feststellte und an St. Kantkak per E-Mail
mitteilte. Ob er die Setup-Skripte bereits berichtigte weiß ich nicht, ich
jedenfalls habe die heruntergeladenen Skripte selbst korrigiert, und bekam
die von mir festgestellten Fehler von Hrn. Kanthak auch per Mail bestätigt.
Vielleicht liegt das Nicht-Funktionieren der SRPs mit bestimmten Windows 11 Versionen an einer fehlerhaften Implementierung des SRP-Regelwerks, weil,
wie bereits eine Posterin bemerkte diverse Kleinigkeiten dazu führen können,
dass die Regeln nicht funktionieren. Ich selbst konnte dies noch nicht testen
weil ich kein Windows 11 Version 22H2 besitze. Ich bin aber gerne dazu
bereit meinen selbst zusammengestellten SRP-Installations-Kit gepackt in
Zip-Dateien, interessierten Usern per E-Mail zu übermitteln. Die Skripte sind
überwiegend selbsterklärend bzw. mit kurzen Kommentaren versehen, und sollten für Kommandozeilenkundige User verständlich sein, beantworte aber auch gerne Fragen bezüglich deren Anwendung. Meine Mail-Adresse lautet: adventurer67@gmx.at. Liebe Grüße Helmut
Hallo, wollte mal meine Beobachtung teilen:
Domaincontroller Server 2022, Clients mit Windows 10 Pro 22H2 (ja richtig gelesen, Pro, nicht Enterprise…)
Über GPOs Applocker eingerichtet -> funktioniert auf dem Client, ohne Gebastel an Registry etc. Executables werden richtig geblockt, im Eventlog alles korrekt mitgelogged…
Konnte es selbst nicht glauben evtl. hat MS hier etwas mit einem kürzlichen Update geändert?
@Dominik
Mit Build 22H2 funktioniert Applocker auch auf Pro (getestet: Win10 und 11). Es ist mit GPOs zentral managebar entgegen dem, was MS behauptet unter https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-to-use-applocker
"You can only manage AppLocker with Group Policy on devices running Windows 10 and Windows 11 Enterprise, Windows 10 and Windows 11 Education, and Windows Server 2016."
Mit anderen Worten: Ups, jetzt haben wir es aus Versehen freigeschaltet.
Moin,
das habe ich auch festgestellt. Es muss nicht mal Win 10 Pro 22H2 sein. Es genügt scheinbar ein Win 10 / 11 Pro ab dem Oktober 22 Patchday. Ich habe es zumindest erfolgreich mit aktuell gepatchten Win 10 Pro 21H1, 21H2 und 22H2 sowie Win 11 22H2 getestet.
Die spannende Frage: Bleibt es dabei oder wird der "Bug" korrigiert?
Moin,
ggfs. noch eine Ergänzung zu Applocker: https://support.microsoft.com/de-de/topic/kb5024351-entfernen-von-windows-editionspr%C3%BCfungen-f%C3%BCr-applocker-e3a763c9-6a3e-4d9c-8623-0ffe69046470
Microsoft hat die Editionsprüfung auf Enterprise bzw. Education mit den Updates vom 30.09.2022 abgeschafft. Der Artikel zu den Anforderungen für die Verwendung von Applocker wurden ebenfalls entsprechend aktualisiert: https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-to-use-applocker
HTH
Jan