Jump to content

Recommended Posts

Posted

We have an AppLocker group policy applied at the root of our workstations OU. Obviously all the sub-OUs below this inherit this policy, and this works great.

 

In this policy we block, amongst other things, cmd.exe and netsh.exe. This has been the case for several years, however we're now deploying the SmoothWall Unified Client so that our student laptops are filtered via the SmoothWall Cloud Filter when at home. Blocking cmd and netsh breaks this and it fails to connect to the cloud service. If I remove the block rules for cmd and netsh it works great.

 

Now I'm not all that happy about unblocking these executables; I appreciate that running under a limited account means that they shouldn't necessarily be a security risk - but my view is that they are a distraction to learning at an absolute minimum. However, that is an issue for SmoothWall to consider and address.

 

My question relates to AppLocker inheritance; I'd at least like to only have these executables allowed on those devices where we deploy the unified client rather than site wide. As with most security software, in AppLocker a deny rule overrides an allow, no matter where it exists in the inheritance hierarchy, so I can't simply leave them blocked at the root and then allow in a sub-OU.

 

The only way I can think around this is to split the policies at the root - one containing just the two block rules for cmd and netsh and then another with everything else. And then create an AD group containing the unified client workstations as members, and setting this group with deny permissions on the GPO. This is a bit clunky as it means I then have to maintain the AD group.

 

Is there a better way that I might be missing?

 

Thanks!

Posted

What we do is have a single GPO that just deals with AppLocker, that way no confusion or finding an AppLocker rule hidden somewhere. Then we use groups to apply the rules if it has to be filtered. You can't do it by device though.

 

Maybe you should look at restricting CMD use via GPO? We have it set so if a pupil opens CMD it just gives them a message that it has been disabled. That way if a program runs as SYSTEM it will be OK.

Posted
What we do is have a single GPO that just deals with AppLocker, that way no confusion or finding an AppLocker rule hidden somewhere. Then we use groups to apply the rules if it has to be filtered. You can't do it by device though.

 

Maybe you should look at restricting CMD use via GPO? We have it set so if a pupil opens CMD it just gives them a message that it has been disabled. That way if a program runs as SYSTEM it will be OK.

 

Yeah, that's exactly what we do currently, everything is in one policy that applies to our workstation root OU. This is the first time we've needed to block something site wide, but allow for certain computers.

 

The program is running it in the user context, which is the issue.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...