We have folder redirection for those things for our regular users (and there is no allow rule anyway), but for admins it could be an issue-I think that's what you meant. They are mostly limited to our department and a few school staff, so, I can see what the bosses want, but I don't see any reason they can't make a temp folder on the C: drive or just use the C:\windows\temp folder if they need to run something, it's just training. In most cases though, if something needs to run regularly, we'll have an exception-I expect there will be some, so the blanket might not work. Thanks for all the help-we have a good start to build on now, and I should be able to convert most of our SRPs for students later, as the first machines are going to staff. Off to go through user-based policies.
-Bonnie From: [email protected] [mailto:[email protected]] On Behalf Of Kennedy, Jim Sent: Wednesday, January 20, 2016 5:25 AM To: [email protected] Subject: [NTSysADM] RE: Applocker Exe rules That will kill downloads and desktop. But you raise an interesting point, I may try that also. The most common exception I think you will run into are the webinar runtimes, Citric, go to meeting and so on. So they will look like: %OSDRIVE%\USERS\*\APPDATA\LOCAL\TEMP\*\gotomeeting.exe Also the google updater. And it creates a new random folder name every so often, thus the second * %OSDRIVE%\USERS\*\APPDATA\LOCAL\TEMP\*\GOOGLEUPDATE.EXE From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Miller Bonnie L. Sent: Tuesday, January 19, 2016 4:55 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: Applocker Exe rules And BTW, I like this option also -added a rule for: c:\Users\*\Appdata\* If I have to craft exceptions later that rule might need adjusting, but it's a good place to start. Considering changing it to C:\Users\* also - any reason not to, other than exceptions? If an admin really needs to run something, they can put it somewhere else, but it should keep some malware from attempting to run. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kennedy, Jim Sent: Tuesday, January 19, 2016 12:18 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: Applocker Exe rules Melvin's question triggered a thought. >From a security standpoint Bonnie I respectfully suggest you block >c:\users\*\appdata\* Then whitelist on the exception tab for that rule what needs to be allowed to run. Otherwise you are missing a golden opportunity to kill darn near all the virus's and malware out there. Plus you are playing reverse wack a mole. Killing the bad stuff one path at a time. Consider trying it my way, set it to log. I bet the list to whitelist will be pretty short. Also, going back to your original question I believe you can block onedrive.exe all by itself. And kill it universally. Yea, they can rename it. But they can also move it on a path block too. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Melvin Backus Sent: Tuesday, January 19, 2016 3: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
