Applocker sperrt Freigegebene Anwendungen
Moin zusammen
ich weiß, AppLocker zu implementieren setzt masochistische Neigungen voraus, aber das steht hier nicht zur Debatte
Gegeben: Windows Domäne unter 2012 R2. Windows 7 SP1 Clients mit Office 2010 SP1.
U.a. eine (default) Applocker Regel, die alle Office-Programme für "Jeder" zulässt.
Wir haben Sporadisch an einigen Arbeitsstationen das Problem, das direkt nach dem Anmelden oder auch mal nach ein paar Stunden bspw. Excel nicht gestartet werden kann.
Der Rechner bootet, bekommt alle Computer-Richtlinien. Nutzer meldet sich am Rechner an und bekommt Netzlaufwerke, Drucker, etc... Die Ereignisanzeige ist bis zu diesem Zeitpunkt unauffällig.
Allerdings startet Excel über die Desktopverknüpfung nicht mit der Meldung "Dieses Programm wurde von einer Gruppenrichtlinie gesperrt"
Ein "Ausführen als.." hat leider keine Wirkung. Die .exe direkt zu starten schlägt ebenso fehl wie der Aufruf aus einem "Elevated prompt". Allerdings starten zu dem Zeitpunkt *.exe Dateien aus einem anderen für Applocker freigegebenen Ordner, nur Office eben nicht.
Die Ereignisanzeige meldet "8004: Ausführung von %OSDRIVE%\PROGRA~2\MICROS~1\OFFICE14\WINWORD.EXE wurde verhindert."
Oft tritt das Problem ja auf, wenn potentiell unsichere Anhänge geöffnet werden, die das entsprechende Programm dann unter einem "reduced token" ausführen. Das ist bei uns nicht der Fall, da auch der direkte Aufruf der .exe ohne den Umweg über Outlook den Fehler provoziert bzw. Outlook zu diesem Zeitpunkt gar nicht läuft.
Im Prinzip habe ich das Problem, das hier beschrieben ist, aber der Patch scheint entweder in einem anderen Update aufzugehen und ist wirkungslos oder ist aus einem anderen Grund "nicht für Ihr System geeignet"...
Die Liste der Vertrauenswürdigen Speicherorte habe ich schon zusammen mit den Kollegen angepasst, ohne Wirkung.
Hat jemand Erfahrungen in dieser Richtung gemacht oder hat noch eine Idee wo ich ansetzen könnte?
Gruß
Rob
ich weiß, AppLocker zu implementieren setzt masochistische Neigungen voraus, aber das steht hier nicht zur Debatte
Gegeben: Windows Domäne unter 2012 R2. Windows 7 SP1 Clients mit Office 2010 SP1.
U.a. eine (default) Applocker Regel, die alle Office-Programme für "Jeder" zulässt.
Wir haben Sporadisch an einigen Arbeitsstationen das Problem, das direkt nach dem Anmelden oder auch mal nach ein paar Stunden bspw. Excel nicht gestartet werden kann.
Der Rechner bootet, bekommt alle Computer-Richtlinien. Nutzer meldet sich am Rechner an und bekommt Netzlaufwerke, Drucker, etc... Die Ereignisanzeige ist bis zu diesem Zeitpunkt unauffällig.
Allerdings startet Excel über die Desktopverknüpfung nicht mit der Meldung "Dieses Programm wurde von einer Gruppenrichtlinie gesperrt"
Ein "Ausführen als.." hat leider keine Wirkung. Die .exe direkt zu starten schlägt ebenso fehl wie der Aufruf aus einem "Elevated prompt". Allerdings starten zu dem Zeitpunkt *.exe Dateien aus einem anderen für Applocker freigegebenen Ordner, nur Office eben nicht.
Die Ereignisanzeige meldet "8004: Ausführung von %OSDRIVE%\PROGRA~2\MICROS~1\OFFICE14\WINWORD.EXE wurde verhindert."
Oft tritt das Problem ja auf, wenn potentiell unsichere Anhänge geöffnet werden, die das entsprechende Programm dann unter einem "reduced token" ausführen. Das ist bei uns nicht der Fall, da auch der direkte Aufruf der .exe ohne den Umweg über Outlook den Fehler provoziert bzw. Outlook zu diesem Zeitpunkt gar nicht läuft.
Im Prinzip habe ich das Problem, das hier beschrieben ist, aber der Patch scheint entweder in einem anderen Update aufzugehen und ist wirkungslos oder ist aus einem anderen Grund "nicht für Ihr System geeignet"...
Die Liste der Vertrauenswürdigen Speicherorte habe ich schon zusammen mit den Kollegen angepasst, ohne Wirkung.
Hat jemand Erfahrungen in dieser Richtung gemacht oder hat noch eine Idee wo ich ansetzen könnte?
Gruß
Rob
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 360426
Url: https://administrator.de/forum/applocker-sperrt-freigegebene-anwendungen-360426.html
Ausgedruckt am: 24.12.2024 um 17:12 Uhr
4 Kommentare
Neuester Kommentar