Lastly, In this archived reddit post ELI5: Windows Defender Application Control VS AppLocker? this tool is recommended: AaronLocker For pre-1909 builds, cmdlets are only available on Enterprise but policies are effective on all SKUs. Cmdlets are available on all SKUs on 1909+ builds.I revisited my troubleshooting notes here is one bit could be relevant to your problem. For blocking and auditing of Windows Installer and script files, use Applications and Services Logs > Microsoft > Windows > AppLocker > MSI and Script.For blocking and auditing of executable files, use Applications and Services Logs > Microsoft > Windows > Code Integrity > Operational.To verify the specific software being blocked or audited, see the following local client event logs: To monitor the processing of a Windows Defender Application Control policy, use the following log file on client PCs: Use the information in the Monitor compliance settings article to help you monitor that the deployed policy has been applied to all PCs correctly. Some events are also available in %WINDIR%\CCM\Logs\DeviceGuardHandler.log file. While in audit mode, any exception to the deployed WDAC policy will be logged in the Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational event log Use the system as you normally would, and monitor code integrity events in the event log. | where ActionType = 'AppControlCodeIntegrityPolicyBlocked'Īpp Control logs are available in Event Viewer under “Code Integrity” section. | where ActionType startswith 'AppControl' | where InitiatingProcessFileName startswith "wu" Raw events when blocked process name starts with wu (for windows update) | where ActionType startswith 'AppControl' | where DeviceName = 'mymachine' | where ActionType startswith 'AppControl' Raw events for all machines (max 10,000 events) ![]() | summarize Machines=dcount(ComputerName) by ActionType It is really easy to see app locker logs in (if you got EMS E5 subscription and MDATP) ![]() I spent a few days looking at why Windows update persistently failing on some machines only to find that it is blocked by AppLocker. Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/a3b2cbe1/MSI/Policy Looking at the configuration policy device status on Intune, MDMDiagnostics report, and the policy files buried under C:\Windows\System32\AppLocker\MDM, I know the MSI setting is actually getting to the machine. But even if it was a bad configuration that allowed people to run msi's from anywhere, it should still log an event in MSI and Script that the msi was allowed to run, right? Just to make sure it isn't a bad configuration from AaronLocker I changed the MSI policy to be only the simple default rule where only administrators can install anywhere. I have two devices I'm testing with - one with our normal security baseline stuff, and another with nothing configured besides bitlocker. ![]() They do not block anything when enabled, and raise zero events in the Event Viewer (until they call a Windows exe) whether enabled or in audit. I followed the information here for how to get the policies into Intune (custom config policy, OMA-URI for each file type, split up XML by rule collection, unique group identifier, etc.): I used AaronLocker to build out all of my baseline policies that I want to deploy in audit mode to collect event logs. ![]() I also can't find anything where someone is having a similar issue. I'm completely out of ideas on what's going on with this, and it doesn't seem that there are any troubleshooting tools that exist when using the CSP instead of group policy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |