Software Restriction Policies is wrongly applied to Administrator

I have Windows 7 64-bit and have configured SRP so that "Disallowed" is the default security level and only software in C:\Program Files, C:\Program Files (x86), and C:\Windows can execute.

The problem is that even though it is configured for "All users except local administrators", it is still affecting my admin account. When I try to run any executable file in the C:\Users\admin\Downloads directory, I get a popup saying "This program is blocked by group policy."

If I set "Unrestricted" to be the default security level, then I can run executables in C:\Users\admin\Downloads, but obviously it needs to be set to "Disallowed" or else there's no point in using SRP.

Any idea why it is affecting my admin account even though it is set to "All users except local administrators"?

 

I'm not sure exactly how SRP works under Windows 7, but I think it's because UAC is likely enabled, so it is applying a user "token" to your admin account, meaning you are running as a "Protected Administrator" with only user privileges, but of course with the ability to self elevate when needed.

You will probably need to add an additional rule to SRP as:

C:\Users\admin\Downloads

 

It's working properly. "Not applied to local administrators" means it doesn't restrict users or processes that are elevated through UAC. Your admin account normally runs limited, so it runs into the brick wall execution denial.

In order to actually install stuff as admin with SRP enabled, you have to right-click the installer and select "Run as admin."

 

That's true, good point Of course in the case (probably rare) where the file doesn't need elevated privileges to run, then an SRP rule for that directory is required, otherwise the policy will block it. I believe the single user Chrome installer is a valid example of this. Even with the additional SRP rule in place, UAC should trigger if the file needs to be elevated, which is almost always the case for binary installers.

 

Thanks for the explanation, guys.

If I go that route, I would also need to add C:\Users\admin\AppData\Local\Temp, since many installers extract files and try to execute them from the temp dir.

One problem is that I had downloaded a .REG file, and I couldn't merge it into my registry. Right-clicking on it, there's no "Merge as admin" option. MSI installers also don't have a "Run as admin" option, but I did find a .REG file you can use to add it to the context menu.

 

For MSI files, you can open a cmd terminal as admin and run the MSI file from there. Not sure about REG files though.

 

That's true. This is something that really bothers me about programs like Chrome that use this unprotected path for a number of their executables

*EDIT* just remembered that offline installer for Chrome is a nice option to get around the user directory issue.

You could try to restrict things somewhat with specific paths and files using a limited wildcard approach, but that is a PITA to configure