9

Due to the workload generated by recent ransomware outbreaks (Cryptolocker/Cryptowall/etc.), I was recently tasked with implementing Software Restriction policies to block program execution from temporary directories. This is generally working well enough, but we have a problem when we need to install software, in that these Software Restriction policies prevent installers from accessing the machine temporary directories.

Our Active Directory hierarchy is basically organized along the lines of our physical sites, and our AD objects inherit about a couple dozen GPOs each from the domain root and their specific site OUs. As such, I don't have the option of either creating a blocked policy OU off the domain root (as not inheriting the site-specific Group Policy settings causes big problems with the machines, and the remote users are not skilled enough to resolve them), or relinking Group Policy Objects closer to the child OUs (as that would involve several hundred delinking and relinking operations, which I'm not willing to do), or creating a child OU at each with inheritance blocked (because I'd have several hundred linking operations to do in that case).

That said, I do need a way to temporarily stop the Software Restriction policy GPO from applying, so that we can install software from time to time. I tried to solve this initially by creating a child OU at each site, and linking an inverse Software Restriction policy, thinking that the higher precedence of the inverse policy would override the inherited one, but that didn't work at all - an RSOP showed that computers were getting complimentary disallow and unrestricted rules, and the disallow rules win in that scenario.

So, with all that in mind (can't relink all our GPOs, can't create a simple inheritance blocked OU, and a GPO with higher precedence doesn't seem to solve my problem), what can I do to [temporarily] block the application of inherited Software Restriction GPOs? Assume Windows 7 clients on a Server 2008 R2 FL domain/forest.

  • You should be using AppLocker rather than Software Restriction Policies (SRP). SRP runs on the user-side of the user/kernel boundary, and can be circumvented by unprivileged users (or the malware they're running) with DLL injection. – Evan Anderson Oct 21 '14 at 0:36
  • @EvanAnderson Not that I disagree, but we had some management-inflicted constraints that caused us to go the SRP route. Much like the reasons I couldn't just exclude machine administrators from the policy, they're embarrassing, non-technical, and not anything I want to go into without a higher blood alcohol content. – HopelessN00b Oct 21 '14 at 1:08
8

Add the specified machines to an Active Directory Security Group and add the Group to the GPO with a "Deny" for "Apply Policy" (Don't fall for doing a full deny as it will stop the GPO name from enumerating, making troubleshooting difficult). Then, add the machines to that Group as required.

5

Simply use the "Apply to All users except local administrators" setting in the Software Restriction Policies Enforcement... you don't let all your users run as Administrator... do you???

Software Restriction Policies

As an alternative, perhaps you could define the Software Restriction Policies in the User Configuration portion of the GPO, then use Security Filtering to allow that GPO to only apply to a particular security group of users.

  • 1
    you don't let all your users run as Administrator... do you??? Just the ones I have to, because they outrank/out-important me. (And the few non-technical users who have legitimate needs for admin rights.) – HopelessN00b Oct 20 '14 at 18:01
  • Yep... I knew there was a chance that this wouldn't totally meet your needs, but I thought I would mention it anyway, just for completeness' sake. – Ryan Ries Oct 20 '14 at 18:03
  • Plus, I guess it's worth pointing out that an administrative user will always be able to get around your software restriction policy anyway, if they're determined enough. – Ryan Ries Oct 20 '14 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.