Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 553
  • Last Modified:

applying group policy to computers

Users are getting virus on their computers.
Server is 2003.
One way I'm preventing this is by setting up a group policy:

Path: %AppData%\*.exe
Security Level: Disallowed
Description: Don't allow executables to run from %AppData%.

I have setup the gp and the group is link to the GP.

I ran gpupdate, rsop and it shows the gp. I attached the screenshot.

Also attached is the gp management screen.

I have test the gp by executing a standalone exec in C:\user\me\appdata
and I'm still able to open it.
Am I missing something?
rsop.JPG
group-policy-management.JPG
0
uscost
Asked:
uscost
  • 7
  • 5
  • 2
1 Solution
 
BlueComputeCommented:
Try just putting %appdata% in as the path?
0
 
uscostAuthor Commented:
but i want to limit executables from running there though.
0
 
DontmilkthisCommented:
A couple of levels higher in the hierarchy is the "Enforcement" policy.

If you're performing this test as a local admin, make sure this policy is set to "All Users" and not "All users except local administrators"
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
BlueComputeCommented:
Software restriction policy rules apply automatically to some types of executable files, regardless of their extension type. This includes the following types of files:

    Windows operating system executable files (.exe, .com, .dll)

    Windows scripting files (when processed by Windows Script Host, such as .vbs, and .wsh files)

    Command batch files (when processed by Windows CMD, such as .bat, .cmd)

    Installation packages when processed by Windows Installer (.msi)
So the /*.exe is redundant
0
 
uscostAuthor Commented:
ok i'll try that, but the policy is set to all authenticated users.

edit:

after editing the policy to remove .exe, ran gpupdate on my machine.
Test it again and was still able to open the .exe.
0
 
DontmilkthisCommented:
So what's the setting(s) in the Enforcement policy?

It's at the "Software Restriction Policies" level

In mine I see three options:
1) "Apply software restriction policies to the following:"
    a) All software files except libraries
    b) All software files
2) Apply software restriction policies to the following users:
    a) All users
    b) All users except local admins
3) When applying software restriction policies:
    a) Enforce certificate rules
    b) Ignore certificate rules

So my initial suggestion was to ensure that option 2a) was selected if you're testing as a local admin.

(just to be clear, i'm not talking about the security filtering on the group policy itself)
0
 
uscostAuthor Commented:
where are you seeing that? I see nothing like that.
0
 
DontmilkthisCommented:
The attached are two images of the Enforcement policy.

what domain functional level are you using out of interest?

and have you tested the policy running as a non-local administrator? just to see if the rule is actually correct?
software-restriction-enforcement.png
software-restriction-enforcement.png
0
 
uscostAuthor Commented:
oh ok, i saw those already and it was same settings.
2003 domain functional level btw.

Not sure what was change but all my shortcuts stop working so it was enforcing %appdata%

I didn't want that though, it was blocking everything.

I just wanted to block files that has .exe.

Not sure if I have the prefixes right: C:\Users\me\AppData\netscan.exe

Right now I have:

Path: %AppData%\*.exe
Security Level: Disallowed
Description: Don't allow executables to run from %AppData%.

Path if using Windows Vista/7/8: %LocalAppData%\*.exe
Security Level: Disallowed
Description: Don't allow executables to run from %AppData%.

Path: %AppData%\*\*.exe
Security Level: Disallowed
Description: Don't allow executables to run from immediate subfolders of %AppData%.
0
 
DontmilkthisCommented:
so if you echo both of these in a command window, you'll see they resolve to a subfolder of the real appdata directory, at least for me in windows 7

echo %appdata%
c:\users\me\appdata\roaming

echo %localappdata%
c:\users\me\appdata\local

so neither of these will match you example of c:\users\me\appdata\netscan.exe

I haven't testing this but i'd be curious if you could add a '..' to the path to move it up one level
eg - %appdata%\..\*.exe
0
 
uscostAuthor Commented:
yeah you are correct, i place the files in local and roaming after echoing it return those results.

Test the .exe and they were block. Now I just need to figure how to get to appdata.
I did try your example but that did not work.
0
 
uscostAuthor Commented:
apparently according to this article, this is not possible:

http://ss64.com/nt/syntax-variables.html

I guess they increase the security on win7, but had the feature in xp.

But thanks man for the help. You help me fix it.
0
 
DontmilkthisCommented:
No worries. glad to help.

good luck with the virus issues.

I guess it would be good to just mention this now, i'd be cautious of leaving this block in place for too long... I'm not 100% sure, but this might impact the ability for some application to update themselves.
0
 
uscostAuthor Commented:
yeah i thought about it, but i had users getting viruses that have wipe out all their work files, losing months of work.
I think this will benefit more. But you're still able to run the application manually from the shortcuts on desktop and start menu fine.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 7
  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now