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.
Best Answer
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.