18.04.2017, aktualisiert um 13:44:29 Uhr

3827

Applocker-Bug in Win10-1703 - Workaround gesucht

Moin.

Vielleicht hat ja jemand Lust, dies zu verifizieren:

In win10 enterprise 1703 (15063.138) kann man keine Applockerregeln mehr anlegen, die an spezielle Konten gebunden sind. Sobald man auf den Button klickt, um Nutzer auszuwählen, crasht die mmc.
Eine Erstellung von Regeln über importieren (via GUI oder Powershell) gelingt immerhin weiterhin.
Das ist natürlich nicht nur ein lokales Problem - will man über RSAT Regeln domänenweit erstellen, crasht die mmc ebenso.

Bei den Vorversionen 10240, 1511 und 1607 geht es.
--

Zur Frage: hat zufällig jemand die Powershell-Syntax parat, um eine einzelne test.exe im Pfad c:\blablub freizuschalten für Nutzer testnutzer?
Ich versuche also das Selbe zu erreichen, wie über die GUI: die bestehenden Regeln sollen nicht überschrieben werden, sondern eine einzelne hinzugefügt werden.

Ich klopfe nebenbei mal im Technet an. Ihr könnt es dort ja upvoten, wenn Ihr auch an einer Lösung Interesse habt oder mich dabei unterstützen wollt.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 335383

Url: https://administrator.de/forum/applocker-bug-in-win10-1703-workaround-gesucht-335383.html

Ausgedruckt am: 08.04.2025 um 20:04 Uhr

31 Kommentare

Neuester Kommentar

Zitat von @DerWoWusste:
Zur Frage: hat zufällig jemand die Powershell-Syntax parat, um eine einzelne test.exe im Pfad c:\blablub freizuschalten für Nutzer testnutzer?

Get-AppLockerFileInformation -Path "C:\Pfad\datei.exe" | New-AppLockerPolicy -RuleType Path -User Musteruser  

Gruß

Hi elchapo.

Wenn ich noch

| Set-AppLockerPolicy

hinten anfüge, wird diese Regel erstellt, klar, aber ich will ja die alten Regeln nicht überschreiben, was aber passiert.

Zitat von @DerWoWusste:
klar, aber ich will ja die alten Regeln nicht überschreiben, was aber passiert.

Servus DWW,
du holst dir die existierenden Policies erst mal und mergst diese dann mit der neuen Policy:

$policies = Get-AppLockerPolicy -Local
$policies.Merge((Get-AppLockerFileInformation -Path "C:\Path\file.exe" | New-AppLockerPolicy -RuleType Path -User MaxMustermann))  
$policies | Set-AppLockerPolicy

Grüße Uwe

Hallo Uwe.

Klasse. Kostet dich vermutlich ein Lächeln

Vielen Dank, läuft.

Keine Ursache. Bug der GUI kann ich hier übrigens auch bestätigen, hab mal Fehlerbericht übermittelt vielleicht hilfts für die nächsten never ending Updates. Redmond hat einfach kein QM ... sowas sollte eigentlich bei automatisierten Test die heutzutage kein Hexenwerk mehr sind immer auffallen, aber anscheinend hat sich das bei denen noch nicht herum gesprochen ;-/

Ist weggepatcht in 15063.250!

Also hier existiert der Fehler nach dem Update auf 15063.250 (Enterprise) immer noch (clean install). Verursacht durch SrpUxSnapin.dll

bei Microsoft.ManagementConsole.Internal.SnapInMessagePumpProxy.OnThreadException(Object sender, ThreadExceptionEventArgs e)
   bei System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t)
   bei System.Windows.Forms.Control.WndProcException(Exception e)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
   bei Microsoft.Security.Srp.Ux.SrpUxRuleListView.CreateManualRule(RuleType ruleType)
   bei Microsoft.ManagementConsole.View.DoAction(Int32 actionId, Boolean selectionDependent, Int32 selectionId, IRequestStatus requestStatus)
   bei Microsoft.ManagementConsole.View.ProcessRequest(Request request)
   bei Microsoft.ManagementConsole.ViewMessageClient.ProcessRequest(Request request)
   bei Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request)
   bei Microsoft.ManagementConsole.Executive.RequestStatus.BeginRequest(IMessageClient messageClient, RequestInfo requestInfo)
   bei Microsoft.ManagementConsole.Executive.SnapInRequestOperation.ProcessRequest()
   bei Microsoft.ManagementConsole.Executive.Operation.OnThreadTransfer(SimpleOperationCallback callback)

@132895
Das muss man nicht verstehen... ich habe die selbe Version und Edition.
Edit: allerdings englisch!

Zitat von @DerWoWusste:
Edit: allerdings englisch!

Bei EN-US selbes Spiel, tüdet nieet ...wat solls. Ich häng das Senden des Fehlerberichts mal in eine Schleife, vielleicht geht MS dann der Speicher aus

.
Schöns Wochenende.

Ja, dir auch, danke.
Ich hab hier ein weiteres aktuelles englisches System genommen und dort stürzt es auch weiterhin ab. Sehr sonderbarer Fix.

Zur Info: Lüppt hier ebenfalls nicht.

Wenn ich jetzt ganz verrückt wäre, würde ich das durch den Debugger schicken und selber fixen, aber ich genieße lieber noch den Rest Sonne des Tages und überlass den Bockmist den Remondies

Grüße Uwe

in OS version 15063.540 wurde es heute gefixt!

Also ich hab 1703 Build 15063.674 und bei mir tritt der Fehler immer noch auf.
RSAT: WindowsTH-RSAT_WS_1709-x64.msu

Irgendjemand eine Idee, wo der Fehler sein könnte?

Grüße
Patrick

Hi Badger.

Tritt hier mit dem selben Build nicht auf. Warum nutzt Du denn das neueste RSAT? Schon mit dem alten getestet?

Zitat von @DerWoWusste:
Tritt hier mit dem selben Build nicht auf.

merkwürdig...

Warum nutzt Du denn das neueste RSAT?

Hab einfach die neuste Version runtergeladen.

Schon mit dem alten getestet?

Nein, da sich die alte Version nicht mehr deinstallieren lässt (siehe auch hier ganz unten bei den Kommentaren).

Grüße
Patrick

Nein, da sich die alte Version nicht mehr deinstallieren lässt

Jou, das hatte ich auf einem Testsystem auch! Musste Eine Windows-Reparaturinstallation laufen lassen (inplace upgrade), danach war sie automatisch deinstalliert.

Zitat von @DerWoWusste:

Nein, da sich die alte Version nicht mehr deinstallieren lässt

Jou, das hatte ich auf einem Testsystem auch! Musste Eine Windows-Reparaturinstallation laufen lassen (inplace upgrade), danach war sie automatisch deinstalliert.

I'm sooo in love with Win 10 (RSAT geht nicht, Edge ging nicht, div. Usersettings sind einfach verstellt worden,...)!

Ich werd mal die Sicherung vor dem Update einspielen und nochmal von vorne anfangen.
Werde berichten, ob es mit der "alten" RSAT-Version klappt.

Eigentlich hat das ja nichts mit RSAT zu tun - öffne mal secpol.msc - auch da ist ja ein Zugang zu Applocker. Geht es dort?

So: Inplace Upgrade durchgeführt. Jetzt sind zumindest die RSAT wieder weg.

Welche Version hast du denn installiert von RSAT? Denn für 1703 gibt es keine eigenen und die "Alten" werden durch das Upgrade deinstalliert (steht auch hier so).

In secpol.msc genau das gleiche Phänomen mit dem Fehler - keine Verbesserung. Version 15063.674

Ich nutze die WindowsTH-RSAT_WS2016-x64.msu, da die von dir zuvor verwendete Version einen Fehler hat (kein DNS snapin enthalten).
Aber Dein Applocker-Fehler hat, wie gezeigt, damit gar nichts zu tun. Wenn Du nach dem Inplace-Update wieder alle Updates installiert hast, muss es weg sein - wenn es bei Dir nicht geht, kann es ja nur ein Fehler sein, der einen anderen Grund hat - hier ist es überall weg.

Danke für deine Hilfe.

So: die Benutzerauswahl geht in secpol.msc.

Nun aber gleich das nächste (ähnliche) Problem:
secpol.msc -> Anwendungssteuerungsrichtlinien -> AppLocker -> All-Paketregeln -> neue Regel erstellen -> Aktion zulassen, Benutzer Jeder -> Ein installiertes App-Paket als Referenz verwenden -> auswählen: CRASH!
Ist auch bereits in deinem Technet-Beitrag angeführt (Beitrag vom 09.08 vom Sebow).

Geht das bei dir oder kommt da auch der Fehler?

Patrick

Geht bei mir (Windows Defender als Paket gewählt).

Danke fürs testen.

Mehr wie Interessant.
Denn die letzten 8 Beitrage auf deinem Technet-Beitrag haben alle das gleiche Problem wie ich - aber alle zumindest 15063.540 installiert.

Irgendwo hakts da noch gewaltig...

Noch eine Frage: Welche .NET Version hast du installiert?

Grüße
Patrick

Die eingebaute von v1709. Ging/Geht aber auch mit 1703 und der eingebauten (aktuell gehalten per Windowsupdate).

Also irgendwie hab ich das Gefühl, dass dies ein Bug ist und keine Fehleinstellung bei mir: klick.

Gewöhn dich doch einfach daran direkt die Powershell anstatt die verka..te MMC zu benutzen

, problem solved.

Zu Deinem Link, Badger: das ist Win7.

Zitat von @DerWoWusste:

Zu Deinem Link, Badger: das ist Win7.

War mir bewusst. Aber man findest du Win 10 auch einige Themen.

Habs auf jeden Fall nun in einer Test VM probiert. Da klappt alles.
Keine Ahnung wo es hakt - aber es hakt. DISM und SFC finden auf jeden Fall keinerlei Fehler.
Auch ein Inplace-Upgrade ändert nichts. Also schon irgendwie mehr wie komisch das Ganze.
Denn zumindest ein Inplace-Upgrade sollte dich zumindest alles neu machen?! Zumindest war dies bis jetzt meine Auffassung. Aber scheinbar täusche ich mich?!

Zitat von @colinardo:

Gewöhn dich doch einfach daran direkt die Powershell anstatt die verka..te MMC zu benutzen

, problem solved.

Nachdem sich meine Lust nach einer Neuinstallation ziemlich in Grenzen hält, wirds wohl zu werden.

So: heute den nächsten Rechner upgedatet: selbes Spiel.

Mir scheint als tritt dies bei Rechnern auf, die per Inline-Upgrade auf die 1703 gebracht werden.
Nur bei einer Neuinstallation trat dieses Problem bei mir nicht auf.

Patrick