I wonder if the setting really means ‘administrative token’ rather than just ‘admin’. Thinking back, the machines I’m referring to have UAC turned off, so admins are running with their elevated token, which may be why SRPs behaved like that.
I can’t say one way or the other whether those same policies were working as expected with UAC/limited tokens. Matthew Topper From: [email protected] [mailto:[email protected]] On Behalf Of Richard Stovall Sent: Wednesday, March 4, 2015 11:47 AM To: [email protected] Subject: Re: [NTSysADM] Software Restriction Policy in Win7-64 broken? Interesting. I see the behavior you describe, but only if I right click and run as admin. On Wed, Mar 4, 2015 at 11:38 AM, Matthew Topper <[email protected]<mailto:[email protected]>> wrote: I can't shed much light on the specifics, but on my 64 bit Win7 machines, this worked as expected. With a default of restricted, users (admins included) were not able to run anything that had not been whitelisted. Matthew Topper -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Klaus Hartnegg Sent: Wednesday, March 4, 2015 11:31 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Software Restriction Policy in Win7-64 broken? Software Restriction Policy (SRP) in Win7-64 behaves different than in Win7-32 or WinXP-32 (I'm using SRP in whitelisting mode, default level is restricted). SRP allows to choose whether it should affect everybody, or everybody except admins. In 32bit this does have the expected effect. But in 64bit administrator always are allowed to run executables everywhere, regardless of SRP settings. Is SRP broken in 64bit Windows? Also there is an option whether SRP should affect all except DLLs, or really all software. In Win7-64 with DLLs specifically excluded from SRP, every user gets on the first login the error message that MSOE.DLL cannot be loaded. Why? SRP is told to not not restrict DLLs, and that DLL is in a directory that is specifically allowed. I did find a solution to the second problem: remove these registry keys: HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{44BBA840-CC51-11CF-AAFA-00AA00B6015C} HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components\{44BBA840-CC51-11CF-AAFA-00AA00B6015C} But the first issue makes me wonder whether SRP can be trusted any more, or maybe we must switch to AppLocker? Klaus
