have you told the machine and server to gpupdate (forcefully)?
I know this has been asked before. However I think I have followed the advice in the other posts and it is still not working for me so what am I doing wrong?
Taking one file type as an example [solving the problem gives me the answer to other file types also]
Let us say that I want to prevent students running CMD from their home folders and from memory stick locations. And let us say that home folders are mapped to U:\ and memory sticks are created as E:\ and F:\
At the server in Group Policy [GPO created to control student user behaviour] In User Configuration I have created a Designated File Type in:
Policies\Windows Settings\Security Settings\Software Restriction Policies
File Type: CMD
In the same GPO I have placed a Path Rule under User Configuration:
Policies\Windows Settings\Security Settings\Software Restriction Policies\Additional Rules
Path Rule: U:\*.CMD: Disallowed
However I find that students can still run a test CMD file.
What am I missing?
Server: Windows Server 2008: Standard Edition: 64 Bit: Service Pack 2
Client: Windows XP Pro: SP3
have you told the machine and server to gpupdate (forcefully)?
Have you looked at it with the RSoP snapin to see what policies have applied and what errors, if any are generated?
It's also worth mentioning that even after you have done the above, it is still very easy to bypass these restrictions via process injection. I reckon a student could easily do this if they spent a few minutes on Google.
They might bring in a memory stick that has a batch file they have written at home, it may have a shortcut to a program that I do not want the students to run directly or it may have a portable executable. So as a start I am trying to prevent students from running:
*.EXE, *.BAT, *.ZIP, *.COM, *.CMD, *.LNK from U:\, E:\ and F:\ [these are areas connected to the school network they have read/write control over]
Or is this not the right approach?
Last edited by DaveP; 11th July 2010 at 11:55 AM. Reason: Add to post content.
An easy way to prevent all executables and scripts from being run from USB flash drives would be to create a couple of path rules like: "E:\*" and "F:\*". This should work no matter many sub-folders they use. I assume you're still using USBDLM so that removable drives do not get assigned other drive letters?
N.B. I've not tried it myself yet, but apparently restricted users can use %SystemRoot%\System32\runas.exe to bypass SRPs so you may want to block that too. e.g.
Code:runas /trustlevel:"Unrestricted" e:\schoolwork\game.exe
For files in user areas, you could use "File Server Resource Manager" on your server to block each extension you don't want to have in there.
Yet another approach might be to do the exact opposite and disallow everything by default because there will almost always be something you have missed (like WSH and HTA files). All you have to do then is explicitly allow just the programs and/or locations via hash or path rules. Details on how to do this can be found here and here (from step 3).
Yes I am using USBDLM but I can't experiment with that today because I am not on site. I can experiment with student home folders [U:\]
I have created a path file for U:\ [U:\*.CMD and U:\*.BAT] but I find that my students can still run these file types from this location.
Do I have the 'wrong end of the stick' on this setting?
Does U:\* work?
Not everything. By default it should be just the following designated file-types.
Code:Extension / Description . ADE Microsoft Access Project Extension . ADP Microsoft Access Project . BAS Visual Basic Class Module . BAT Batch File . CHM Compiled HTML Help File . CMD Microsoft Windows NT Command Script . COM Microsoft MS-DOS Application . CPL Control Panel Extension . CRT Security Certificate . EXE Application . HLP Windows Help File . HTA HTML Applications . INF Setup Information File . INS Internet Communication Settings . ISP Internet Communication Settings . JS Microsoft JScript File . JSE JScript Encoded Script File . LNK Shortcut . MDB Microsoft Access Application . MDE Microsoft Access MDE Database . MSC Microsoft Common Console Document . MSI Windows Installer Package . MSP Windows Installer Patch . MST Visual Test Source File . PCD Photo CD Image . PIF Shortcut to MS-DOS Program . REG Registration Entries . SCR Screen Saver . SCT Windows Script Component . SHS Shell Scrap Object . URL Internet Shortcut (Uniform Resource Locator) . VB VBScript File . VBE VBScript Encoded Script File . VBS VBScript Script File . WSC Windows Script Component . WSF Windows Script File . WSH Windows Scripting Host Settings File
This is what I have in that GPO:
I have run gpupdate /forceCode:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot% Security Level Unrestricted Description Date last modified 11/07/2010 10:56:35 %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir% Security Level Unrestricted Description Date last modified 11/07/2010 10:56:35 U:\* Security Level Disallowed Description Date last modified 11/07/2010 13:50:23 U:\*.BAT Security Level Disallowed Description Date last modified 11/07/2010 11:07:09 U:\*.CMD Security Level Disallowed Description Date last modified 11/07/2010 11:06:37
I have restarted the station
I have waited for some time [more than an hour] before logging on a s a typical student and I find that this user can still run CMD and BAT files from U:\
Using Group Policy Modelling Wizard at the Domain Controller to check if the policy is applied to this test student I find that the policy does indeed apply to this individual.
I must still be missing something but what?
I think you may need to make a few changes. What happens if you use these instead?
Code:%SystemRoot% Security Level: Unrestricted %ProgramFiles% Security Level: Unrestricted U:\* Security Level: Disallowed %SystemRoot%\System32\cmd.exe Security Level: Disallowed %SystemRoot%\System32\command.com Security Level: Disallowed
If that works you will probably want to add the following to your list too.
Code:E:\* Security Level: Disallowed F:\* Security Level: Disallowed %SystemRoot%\System32\cscript.exe Security Level: Disallowed %SystemRoot%\System32\wscript.com Security Level: Disallowed %SystemRoot%\System32\mstsc.exe Security Level: Disallowed %SystemRoot%\System32\mmc.exe Security Level: Disallowed %SystemRoot%\System32\msiexec.exe Security Level: Disallowed %SystemRoot%\System32\rundll32.exe Security Level: Disallowed %SystemRoot%\System32\task*.exe Security Level: Disallowed %SystemRoot%\System32\telnet.exe Security Level: Disallowed %SystemRoot%\regedit.exe Security Level: Disallowed
As you can see, using a white-list might be a better approach because there are far too many EXEs to block with a black-list.
How did you get on, Dave. Any luck?
Hi. I took the settings suggested in your previous post.
Still not working I am afraid.
Could be a job for the Summer Holiday?
There are currently 1 users browsing this thread. (0 members and 1 guests)