Solved

applying group policy to computers

Posted on 2013-11-13
14
542 Views
Last Modified: 2013-11-14
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
Comment
Question by:uscost
  • 7
  • 5
  • 2
14 Comments
 
LVL 14

Expert Comment

by:BlueCompute
ID: 39646570
Try just putting %appdata% in as the path?
0
 
LVL 1

Author Comment

by:uscost
ID: 39646573
but i want to limit executables from running there though.
0
 
LVL 5

Expert Comment

by:Dontmilkthis
ID: 39646585
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
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
LVL 14

Expert Comment

by:BlueCompute
ID: 39646589
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
 
LVL 1

Author Comment

by:uscost
ID: 39646617
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
 
LVL 5

Expert Comment

by:Dontmilkthis
ID: 39646672
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
 
LVL 1

Author Comment

by:uscost
ID: 39646682
where are you seeing that? I see nothing like that.
0
 
LVL 5

Expert Comment

by:Dontmilkthis
ID: 39646691
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
 
LVL 1

Author Comment

by:uscost
ID: 39646711
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
 
LVL 5

Accepted Solution

by:
Dontmilkthis earned 500 total points
ID: 39646717
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
 
LVL 1

Author Comment

by:uscost
ID: 39646732
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
 
LVL 1

Author Comment

by:uscost
ID: 39646736
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
 
LVL 5

Expert Comment

by:Dontmilkthis
ID: 39646792
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
 
LVL 1

Author Comment

by:uscost
ID: 39647583
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

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this article, we will see the basic design consideration while designing a Multi-tenant web application in a simple manner. Though, many frameworks are available in the market to develop a multi - tenant application, but do they provide data, cod…
This article outlines the process to identify and resolve account lockout in an Active Directory environment.
With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

685 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question