Restrict "system root c:\" access letting users to delete, rename files on their desktop

[Sasa]

I assigned the "File system" permissions in an Active Directory GPO on
the %systemroot% folder this way: Everyone ALLOW ALL, School personell
group JUST READ, students group DENY ALL.

The problem is the students and teachers cannot delete, rename or copy
files on their own desktop (other groups can) even if it doesn't
inherit the "C:\" permissions. I checked the profiles and the
permissions are correctly assigned to each user's profile directory in
"Documents and Settings".
The error message that pops up when a user tries to delete a file from
the desktop is:"Cannot access C:\ Access denied".

I tried to restrict "C:\" with other group policies, hide device,
disable search button in explorer, disable "Run" in Start menu... but
there are thousands of different ways to access it anyway like the
shortcut properties button "Find target" which could point you
directly in "C:\" or the "explore" option in the right mouse button
menu of the start button which doesn't hide "C:\" at all.

The only possibility is to use the NTFS permissions on the system
root.

I want to prevent users from installing programs in "C:\" or creating
directorys or files and even browsing the C:\ content letting them to
use their desktops like they want. Is there a way?

Thank you.

 

[Sasa]

I didn't know it was such a big deal.

 

[Guest]

yeah having the same problem, but with user access to history folder in their
C\documents and settings folder... its weird that this was not a problem in
system policy..

Do your users have a home drive? if so, you could use folder redirection to
redirect the desktop to a directory on their home drive. this way they would
have control over adding in shortcuts etc, but wouldnt be stored on the C
drive - not sure if this is what your after, but worth a go

E

 

[Andrew Mitchell]

(e-mail address removed) (Sasa) said

I assigned the "File system" permissions in an Active Directory GPO on
the %systemroot% folder this way: Everyone ALLOW ALL, School personell
group JUST READ, students group DENY ALL.

The problem is the students and teachers cannot delete, rename or copy
files on their own desktop (other groups can) even if it doesn't
inherit the "C:\" permissions. I checked the profiles and the
permissions are correctly assigned to each user's profile directory in
"Documents and Settings".
The error message that pops up when a user tries to delete a file from
the desktop is:"Cannot access C:\ Access denied".

Try using filemon from www.sysinternals to see what file access is occuring
that is triggering the restriction.
You may find that deleting a file is actually moving it to the Deleted Items
folder and that the restriction is being applied here, not to the desktop.

 

[Guest]

Check what access they have to their Temp and Recycler folders. (Note that
Temp for one user may not be the same as for another, depending on how things
are set up). Make sure that they can read/write/change.

You usually shouldn't play with the permisstions on %systemroot% (usually
C:\WINNT or C:\WINDOWS depending on the OS version) - the default permissions
are generally sufficient, and there are different permissions set on some of
the subfolders that would be changed by allowing inheritance from the top
level. Unless you really understand what the permissions mean and the
possible side effects, it is best to leave them alone.

Permissions on %systemdrive% (and probably the root of most drives) should
probably not be "deny all" to anyone - they usually need at least some access
in order to traverse to allowed folders. The way to keep things secure here
is to put things into folders, and set permissions on the folders - don't keep
files in the root directory. It is okay, and often desirable, to limit
many/most users from being able to write to the root directory.

You can usually at least allow "list folder contents" (unless you really care
if they can see the filenames there) - this allows for traversing the folder
to get elsewhere.

|[email protected] (Sasa) said
|
|> I assigned the "File system" permissions in an Active Directory GPO on
|> the %systemroot% folder this way: Everyone ALLOW ALL, School personell
|> group JUST READ, students group DENY ALL.
|>
|> The problem is the students and teachers cannot delete, rename or copy
|> files on their own desktop (other groups can) even if it doesn't
|> inherit the "C:\" permissions. I checked the profiles and the
|> permissions are correctly assigned to each user's profile directory in
|> "Documents and Settings".
|> The error message that pops up when a user tries to delete a file from
|> the desktop is:"Cannot access C:\ Access denied".
|>
|
|Try using filemon from www.sysinternals to see what file access is occuring
|that is triggering the restriction.
|You may find that deleting a file is actually moving it to the Deleted Items
|folder and that the restriction is being applied here, not to the desktop.
|

 

[Sasa]

Thanks to both of you, but my problem remains unresolved!
The only solution that would work is a PCI card called Radix protector
that restores the hard disk state saved from the administrator every
time the users reboot the machine.
This solution isn't cheap 50-70$ per card and I admin 200 PCs. Beside
the price I'm too lazy to open 200 machines to install the cards.

Norton Ghost will do the job!

I can't still realize I'm the only person that has this annoying
problem.

Do admins usually let users fill the systemroot with junk?

 

[Ryan Hanisco]

You can also use a program called deepfreeze... It works very well and is
easy to configure and deploy.

There are other things you can do to prevent access... Use the pre-built
security policy templates and GPOs. (I used to work in school districts so
I've dealt with this quite a bit.) DeepFreeze is the easiest though.

 

[Guest]

hi.
if you still interested for this subject, reply here.

regards,
cezar haraga

 

[Guest]

hi.
if you interested for this subject, reply here.

regards