Deny execution from %TEMP% (etc) directories.

[ADMaster]

What OS are you running, do you have enterprise / education or are you running pro?

If you are on ent/edu consider moving to applocker, its the successor to SRP and a bit more flexible.

Here is an article on what variables are allowed in path rules for applicker.

https://technet.microsoft.com/en-us/library/ee460944%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

 

There is specific ones to cover all the removable storage so you don't have to list them out.

I know appdata is not a supported one, but it is on my SRP policy. I cannot find a similar article for SRP, but wanted to put this out there if you make the move to applocker.

 

Something you can check on your SRP, is exe still listed in the designated file types? If not add it back.

[mavhc]

Are you rebooting the client computer after gpupdate?

[Garacesh]

What OS are you running, do you have enterprise / education or are you running pro?

W10 Enterprise LTSB 2016

 

Something you can check on your SRP, is exe still listed in the designated file types? If not add it back.

Definitely still is.

 

Are you rebooting the client computer after gpupdate?

Of course.

[jthompson]

I think you need to positively confirm whether or not the policy is being applied. The command I posted earlier will let you check that on your test machine. It would also tell you if another policy is taking precedence over it (unlikely if you've not used SRP before, but it's worth checking).

[Garacesh]

I think you need to positively confirm whether or not the policy is being applied. The command I posted earlier will let you check that on your test machine. It would also tell you if another policy is taking precedence over it (unlikely if you've not used SRP before, but it's worth checking).

 

Could've sworn I replied to this one.

Your command brings up an empty results sheet, but gpresult /scope:computer does say the policy is applying, and if I drill down to /Software restriction Policies/Additional Rules I can see that the policies are there.

 

Can't run gpresult /user:$TestAccount because user does not have RSoP data.

[jthompson]

Ah okay. I should point out that we're Win7 here still. Behind the times.

 

Seems a bit odd.

 

Maybe, just for troubleshooting, apply a whitelist SRP (that is, default level is disallowed), and don't have any path rules at all for D:\. Apply that to your test computer and see if the app on USB gets blocked. At least you'd then know that the computer is able to accept an SRP. If that works, try creating a fresh SRP (default unrestricted or basic) with just a disallow rule for D:\.

[ollyyllo]

Try the disallow rule without the trailing backslash i.e. D: Edited November 30, 2017 by ollyyllo

[mavhc]

https://technet.microsoft.com/en-us/library/cc786941(v=ws.10).aspx has info about specific vs general path rules and Rules Precedence

[Garacesh]

Maybe, just for troubleshooting, apply a whitelist SRP (that is, default level is disallowed), and don't have any path rules at all for D:\. Apply that to your test computer and see if the app on USB gets blocked. At least you'd then know that the computer is able to accept an SRP. If that works, try creating a fresh SRP (default unrestricted or basic) with just a disallow rule for D:\.

 

Still nothing :/

Tried as both user and computer policies.

 

Default security level:

• Disallowed
  

Enforcement:

• All software files except libraries (such as DLLs)
  
• All users except local administrators
  
• Ignore certificate rules
  

Path rules:

• HKLM\Software\Microsoft\etc\etc [unrestricted] (Default rule)
  
• HKLM\Software\Microsoft\etc\etc [unrestricted] (Default rule)
  
• %OSDRIVE%\Python33\ [basic User]
  
• %Programfiles% [basic User]
  
• %ProgramFiles(x86)% [basic User]
  
• %SystemDirectory% [basic User]
  

 

I can still run OpenHardwareMonitor off my USB stick.

So it looks like SRP just.. doesn't work. At all.

Edited November 30, 2017 by Garacesh

[Steve21]

I take it you don't have any applocker rules setup? As they'll take precedence over SRP

 

Steve

[Garacesh]

I take it you don't have any applocker rules setup? As they'll take precedence over SRP

You're kidding me, right..?

You can't use both?

 

Because that makes sense. Thanks Microsoft

 

Yes we have an AppLocker policy in place to disable all the default W10 bloatware and bits that'll just cause hassle. (Microsoft.XboxIdentityProvider, Microsoft.WindowsAlarms, microsoft.windowscommunicationsapps etc)

Edited November 30, 2017 by Garacesh

[Steve21]

I don't know how it works in terms of whether it takes precedence per setting or in total block wise, but yep they interfere, never tried both at the same time

 

Use SRP and AppLocker in the same domain

 

SRP and AppLocker use Group Policy for domain management. However, when policies are generated by SRP and AppLocker exist in the same domain, and they are applied through Group Policy, AppLocker policies take precedence over policies generated by SRP on computers that are running an operating system that supports AppLocker. For information about how inheritance in Group Policy applies to AppLocker policies and policies generated by SRP, see Understand AppLocker Rules and Enforcement Setting Inheritance in Group Policy.

 

Might be worth testing it, and just disabling the applocker policy on your test computer/user to see if it magically kicks in?

 

Steve

[Garacesh]

I don't know how it works in terms of whether it takes precedence per setting or in total block wise, but yep they interfere, never tried both at the same time

 

 

 

Might be worth testing it, and just disabling the applocker policy on your test computer/user to see if it magically kicks in?

 

Steve

 

Yep. Disable (well, untick 'Link Enabled', same difference) the AppLocker policy and I get our friendly neighbourhood error message.

 

"Your system administrator has blocked this program. For more information, contact your system administrator."

[Steve21]

Don't mix and match! Haha Well it's either re-do the SRP in Applocker orrrrrr ignore Applocker orrrr run and hide until after xmas!

 

Steve

[Garacesh]

Don't mix and match! Haha Well it's either re-do the SRP in Applocker orrrrrr ignore Applocker orrrr run and hide until after xmas!

 

Steve

 

I wouldn't even know where to begin on that >.<

AppLocker seems to concern itself with specific programs, which is no good because I want to stop everything running no matter what it is (can you do a wildcard rule..?)

 

Some tinkering will be required.

 

Sorry to have wasted your time so much, folks! Thanks for all the assistance.

[Steve21]

Yep can still do wildcards etc, Shouldn't be much difference for you the way you're trying to do it currently. The main difference will come when you change to whitelisting

 

https://docs.microsoft.com/en-us/windows/device-security/applocker/understanding-the-path-rule-condition-in-applocker

 

In a way it even just work using %HOT% and %REMOVABLE% the way you want to do it

 

Steve

[jthompson]

Sorry to have wasted your time so much, folks! Thanks for all the assistance.

 

On the contrary, I've got all this to come once we start with updating things for Win10. You've prob saved me similar pains.

[Garacesh]

I think I broke it

 

• C:\Python33\*
  
• C:\Python33\*\*
  
• C:\Program Files\*
  
• C:\Program Files\*\*
  
• C:\Program Files (x86)\*
  
• C:\Program Files (x86)\*\*
  
• C:\Windows\*
  
• C:\Windows\*\*
  
• \\server\software\share\*
  
• \\server\software\share\*\*
  
• C:\ProfileDirectory\*
  
• C:\ProfileDirectory\*\*
  

 

Now when I log in as a pupil I just get a black screen with a mouse pointer.

[Steve21]

If you have things like login scripts profiles etc, you'd need something like

 

\\Domain\SysVol\*

\\Domain\Netlogon\*

 

There shouldn't be a need to double up those paths either blah\* includes blah\*\*\*\*\*\*\*\*\*\ etc Or should do unless they changed it in 10

 

Steve

[Garacesh]

We don't use logon scripts. There's one or two startup scripts but none for logon. Everything's done via AD.

Pupil profile/start menu is copied to the machine (via startup script) which is what C:\ProfileDirectory\* is all about.

 

the \*\* was based off @DJ-1701's policy but if I don't need it then hey ho, good stuff.

Edited November 30, 2017 by Garacesh

[DJ-1701]

We don't use logon scripts. There's one or two startup scripts but none for logon. Everything's done via AD.

Pupil profile/start menu is copied to the machine (via startup script) which is what C:\ProfileDirectory\* is all about.

 

the \*\* was based off @DJ-1701's policy but if I don't need it then hey ho, good stuff.

 

Yep, I put my hand up there. I left those in... just in case.

[Garacesh]

Hurrduurrduurrr

 

The user account would read the contents of C:\ProfileDirectory and create a local profile based upon that data.

Of course, the local profile would be C:\Users\%Username%\, which was set as Disallowed since no allow rule existed.

 

 

Adding %UserProfile% to the list sorted it out.

 

Though I'm wary of this because I know some malware will try and write to the user profile location if it can't write to temp/appdata/etc. So I might have to drill down a bit more on this one.