I think I have figured it out. If I drop a machine with a AppLocker policy, it seems to work. If the PC never has had anything related to applocker, it crash and burns. I have a vary basic AppLocker for testing and when this policy is applied, SCCM can start merging the policies. Without this group policy, it locks everything.
Security Settings <about:blank> hide Application Control Policies <about:blank> hide Appx Rules <about:blank> hide Action User Name Rule Type Exceptions Allow Everyone Signed by Microsoft Corporation Publisher No Dll Rules <about:blank> hide No rules of type 'Dll Rules' are defined. Executable Rules <about:blank> hide Action User Name Rule Type Exceptions Allow Everyone Signed by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US Publisher No Allow Everyone (Default Rule) All files located in the Program Files folder Path No Allow Everyone (Default Rule) All files located in the Windows folder Path No Allow BUILTIN\Administrators (Default Rule) All files Path No Windows Installer Rules <about:blank> hide No rules of type 'Windows Installer Rules' are defined. Script Rules <about:blank> hide No rules of type 'Script Rules' are defined. From: [email protected] [mailto:[email protected]] On Behalf Of John Aubrey Sent: Friday, February 2, 2018 8:15 AM To: [email protected] Subject: [mssms] RE: Defender Application Control This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing <http://aka.ms/LearnAboutSpoofing> Feedback <http://aka.ms/SafetyTipsFeedback> Interesting. I was playing with App Locker a little as well. Is the Application Identity service running? Maybe I enabled something that kicked off App Control to start working. I’m going to try and get it on a few more system today and early next week. From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Gannon, Todd Sent: Thursday, February 1, 2018 10:05 PM To: [email protected] <mailto:[email protected]> Subject: [mssms] RE: Defender Application Control Hi – I am having similar issues with wdac. Using SCCM 1710 with the rollup, and W10 1709 Enterprise. The documentation says that for ISG to work, devices must be running WD SmartScreen for it to be trusted. It doesn’t say that it has to be set to warn or block specifically. Anyhow I didn’t have that configured via gp(default set to warn) – after configuring it to block it didn’t make too much of a difference. Still bricked the OS on reboot. I will continue testing. From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of John Aubrey Sent: Friday, 2 February 2018 4:27 AM To: [email protected] <mailto:[email protected]> Subject: [mssms] RE: Defender Application Control I may have got it to work. I had Defender Smartscreen in audit only mode, and it was killing the system as soon as it picked up the policy. It seems it tried to scan the PC to create CI/Policies, failed, and FUBARED the PC. I moved Defender Smartscreen to Block mode, and it appears to be working. It’s gone through Program Files and is now scanning C:\Windows. It’s much further than it was before, so I think it’s working as intended. 1) Windows 10 1709 Enterprise, SCCM 1710 2) No app locker ever implemented, some basic SRP. 3) Machine wouldn’t boot if I tried to reboot. I’ll let you know how it goes. From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Aaron Czechowski Sent: Thursday, February 1, 2018 2:14 PM To: [email protected] <mailto:[email protected]> Subject: [mssms] RE: Defender Application Control Dune is our resident expert on this, but he’s not on the list. I’ll proxy for him. 😊 First question: Windows client build and SCCM version Second question: did they have any applocker rules/policy set up before targeting WDAC? If yes to the second, they should try booting the machine from USB, decrypting the OS drive if necessary, deleting %WINDIR%\System32\Applocker\*.applocker and restart the machine. If machine restart is healthy then the problem is applocker, if not then the problem is code integrity. If that is the case I would want to see their %WINDIR%\CCM\logs\DeviceGuardHandler.log From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of John Aubrey Sent: Thursday, 1 February, 2018 10:17 To: [email protected] <mailto:[email protected]> Subject: [mssms] RE: Defender Application Control Agreed. I was assuming that Microsoft’s Intelligent Security Graph would be smart enough to allow Microsoft’s EXE that are required to run windows to run by default. From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Heaton, Joseph@Wildlife Sent: Thursday, February 1, 2018 11:21 AM To: [email protected] <mailto:[email protected]> Subject: [mssms] RE: Defender Application Control Well, if it blocks notepad, it has no way to read the text file. From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of John Aubrey Sent: Thursday, February 1, 2018 5:22 AM To: [email protected] <mailto:[email protected]> Subject: [mssms] Defender Application Control Has anyone used Defender Application Control policy in SCCM yet? I have a basic policy with the “Authorize software that is trusted by the Intelligent Security Graph” option enabled. Once my test PC checks in, notepad doesn’t work and if I reboot, the system is bricked and won’t boot. Says it can’t access a txt file that is used for event logs. I would have thought the Intelligent Security Graph option would at least let Windows boot….
smime.p7s
Description: S/MIME cryptographic signature
