Okay-I got it working with the * for a pattern match. I was working on this last late on Friday, and I'm pretty sure I may have missed a folder in the path-this works:
c:\Users\*\AppData\Local\Microsoft\Onedrive\Onedrive.exe I'm pretty sure it is working correctly based on what I'm reading here? https://technet.microsoft.com/en-us/library/ee449492.aspx -For most people, the implicit deny rule takes precedence first, then there is no allow for users or any other group, so it's blocked. -For administrators, the implicit deny rule takes precedence first, then there IS an explicit allow rule to run all apps, so it's allowed. In order to block, I have to create an explicit deny rule. -Bonnie From: [email protected] [mailto:[email protected]] On Behalf Of Kennedy, Jim Sent: Tuesday, January 19, 2016 12:31 PM To: '[email protected]' <[email protected]> Subject: [NTSysADM] RE: Applocker Exe rules Filtering the GPO based on local admin group perhaps....some loopback going on? But it is machine based not user based GPO. You can also create rules that use the deny action. When applying rules, AppLocker first checks whether any explicit deny actions are specified in the rule list. If you have denied a file from running in a rule collection, the deny action will take precedence over any allow action, regardless of which Group Policy Object (GPO) the rule was originally applied in. Because AppLocker functions as an allowed list by default, if no rule explicitly allows or denies a file from running, AppLocker's default deny action will block the file. https://technet.microsoft.com/en-us/library/ee460955.aspx Also to my earlier point about block all then white list: The deny action is generally less secure than the allow action because a malicious user could modify the file to invalidate the rule. Deny actions can also be circumvented. From: Kennedy, Jim Sent: Tuesday, January 19, 2016 3:24 PM To: [email protected]<mailto:[email protected]> Subject: RE: Applocker Exe rules Something isn't right. If I have a specific deny on something even local admin's can't do it. It works like NTFS in that a deny trumps all. I have a specific deny on powershell. So even my desktop folks with local admin cannot run powershell. On my back burner to do list is to figure that out. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Miller Bonnie L. Sent: Tuesday, January 19, 2016 3:20 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: Applocker Exe rules So the recursion blocks it for most users (that is working), but if someone is on with an admin account we also need to block the app in this case. When adding the default rules for exes, it adds an "Allow BUILTIN\Administrators" All files", meaning if you're an admin, you otherwise get to run everything and anything. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Melvin Backus Sent: Tuesday, January 19, 2016 12:07 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: Applocker Exe rules Doesn't recursion from the profile directory catch that? %USERPROFILE% would be the level above. Unless of course you have legitimate things running from within the profile directory. -- There are 10 kinds of people in the world... those who understand binary and those who don't. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Miller Bonnie L. Sent: Tuesday, January 19, 2016 2:52 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Applocker Exe rules I'm working on policies for our Win10 deployment (Surface Pro 4's have been ordered, they only come with 10) and have an applocker question, specifically with executable rules. I can't use standard system variables in the paths, like we have done with Software Restriction Policies. Instead there are some special vars available, but I'm not finding anything for user folders/appdata. Has anyone found a way to define the following with any sort of variable? C:\users\username\appdata\something.exe Specifically, we have a program (onedrive.exe) that is in the user profile path by default, but needs to be blocked for all users, even administrators. With the default rules, the program is blocked for everyone who is a standard user but is allowed for admins. I know I can successfully block programs for admins as I have a similar rule already working that points to the groove.exe location in Program files and it can't be run, but everything I've tried for this one doesn't seem to work as I can't craft a working variable. Am I stuck with hashing this file and every new version? I realize there are options for not even installing some of the default apps that come with 10-we are looking at that as well, but we may want to allow the next gen sync client for some people later, if we ever get to one-to-one. I'm also thinking that we might have a need to use this sort of path to ALLOW an executable to run from a user profile path. Thanks for any and all ideas and suggestions! -Bonnie
