Jump to content

Recommended Posts

Posted

Hi,

 

This is driving me nuts!!

 

I've enabled folder redirection in group policy and student desktops are directed to the desktop folder in the roaming student profile, so far so good. But students are able to save docs to the desktop despite them only having read NTFS and share permissions in the profile folder. I've also made sure that 'grant exclusive rights' isn't selected under the redirection options. So they shouldn't be able to save files or folders the the roaming desktop yet they can.

 

Does anyone have any ideas? Students have now discovered the hilarity of right clicking and creating hundreds of new docs on the desktop.

 

Thanks all

Posted

We found this. I use this VBS script as a login script to stop it.

 

'*================================================================== 
'* Titel         : DenyWrite.vbs 
'* Purpose         : Do Not allow users to save stuff on the desktop 
'* Author         : Kimmo Jernstrom 
'* Last Modified : 2005-05-21 
'*================================================================== 
Option Explicit 
DenyWrite GetSpecialFolderDesktop(),GetUserSAM() 


'*================================================================== 
'* Name            : GetSpecialFolderDesktop 
'* In           : - 
'* Out          : Path to Desktop 
'* Purpose        :  
'* Comment        :  
'*================================================================== 
Function GetSpecialFolderDesktop() 
   On Error Resume Next 
   Const DESKTOP = &H10& 
   Dim oShell, oFolder, oFolderItem 
   Set oShell         = CreateObject("Shell.Application") 
   Set oFolder     = oShell.Namespace(DESKTOP) 
   Set oFolderItem = oFolder.Self 
   If Err <> 0 Then 
       GetSpecialFolderDesktop = "N/A" 
   Else 
       GetSpecialFolderDesktop = Trim(oFolderItem.Path) 
   End If 
   'Kill objects 
   Set oFolderIten = Nothing 
   Set oFolder        = Nothing 
   Set oShell        = Nothing 
End Function 

'*================================================================== 
'* Name            : GetUserSAM 
'* In           : - 
'* Out          : UserSamAccountName 
'* Purpose        : To find out the sAMAccountName of a user 
'* Comment        : The environemnt variable %USERNAME% holds the 
'*                  sAMAccountName of the user, so no need to do an 
'*                  AD lookup... 
'*================================================================== 
Function GetUserSAM() 
   On Error Resume Next 
   Dim oWShell 
   Set oWShell = CreateObject("WScript.Shell") ' WScript Shell 
   GetUserSAM = oWShell.ExpandEnvironmentStrings("%USERNAME%") 
   Set oWShell = Nothing 
End Function 

'*================================================================== 
'* Name            : DenyWrite 
'* In           : FolderPath, Trustee 
'* Out          : - 
'* Purpose        : Stop users from creating icons on the desktop 
'* Comment        :  
'*================================================================== 
' 
Sub DenyWrite(sFolder, sTrustee) 
   On Error Resume Next 
   'Bail out 
   If sFolder = "N/A" Then 
       Exit Sub 
   End If 
    
   'Ace Type definitions 
   Const ADS_ACETYPE_ACCESS_ALLOWED    = 0 
   Const ADS_ACETYPE_ACCESS_DENIED        = &H1 

   'AccessMask constants for FILE ACEs 
   Const FILE_WRITE_DATA         = &H2    'file & pipe 
   Const FILE_ADD_FILE         = &H2   'directory 
   Const FILE_APPEND_DATA         = &H4   'file 
   Const FILE_ADD_SUBDIRECTORY = &H4   ' directory 
    
   'AceFlags values for files 
   Const OBJECT_INHERIT_ACE     = &H1 
   Const CONTAINER_INHERIT_ACE = &H2 
    
   'ADS_PATHTYPE_ENUM 
   Const ADS_PATH_FILE         = 1 
   Const ADS_PATH_FILESHARE     = 2 

   'ADS_SD_FORMAT_ENUM 
   Const ADS_SD_FORMAT_IID     = 1 
    
   'Variables 
   Dim oAce                  'variable for the new ACE 
   Dim oSD                   'variable for the Security Descriptor of the object 
   Dim oDacl               'variable for the DACL of the object 
   Dim oADsSecurityUtility    'As ADsSecurityUtility 

   ' Create an ADsSecurityUtlity object. 
   Set oADsSecurityUtility = CreateObject("ADsSecurityUtility") 
   ' Get the Security Descriptor for the given NTFS File path. 
   Set oSD = oADsSecurityUtility.GetSecurityDescriptor(sFolder, ADS_PATH_FILE, ADS_SD_FORMAT_IID) 
   ' Get the Discrectionary ACL for the key. 
   Set oDacl = oSD.DiscretionaryAcl 
   ' Create an ACE object. 
   Set oAce = CreateObject("AccessControlEntry") 
   ' Set the IADsAccessControlEntry::Trustee attribute. 
   oAce.Trustee = sTrustee 
   ' Set the IADsAccessControlEntry::AccessMask attribute. 
   oAce.AccessMask = FILE_WRITE_DATA + FILE_ADD_SUBDIRECTORY 
   ' Set the IADsAccessControlEntry::AceType attribute. 
   oAce.AceType = ADS_ACETYPE_ACCESS_DENIED  
   ' Set the IADsAccessControlEntry::AceFlags attribute. 
   oAce.AceFlags = OBJECT_INHERIT_ACE Or _ 
                       CONTAINER_INHERIT_ACE 
   ' Place the ACE on the DACL. 
   oDacl.AddACE oAce 
   ' Place the DACL back onto the SD. 
   oSD.DiscretionaryAcl = oDacl 
   ' Place the SD back onto the file. 
   oADsSecurityUtility.SetSecurityDescriptor sFolder, ADS_PATH_FILE, oSD, ADS_SD_FORMAT_IID 
   ' Cleanup. 
   Set oAce                 = Nothing 
   Set oDacl                 = Nothing 
   Set oSD                 = Nothing 
   Set oADsSecurityUtility = Nothing 
End Sub

  • Thanks 1
Posted
Might be worth double-checking that they aren't a member of two groups (say, Authenticated Users) which have permission. You could either use the Effective Permissions tool from the security/advanced tab, or you could try setting an explicit Deny on the student group for write permission, as that Deny should override an Allow from another group.
Posted
Might be worth double-checking that they aren't a member of two groups (say, Authenticated Users) which have permission. You could either use the Effective Permissions tool from the security/advanced tab, or you could try setting an explicit Deny on the student group for write permission, as that Deny should override an Allow from another group.

 

I had already put a deny under create folders etc which makes the mind boggle even more.

@FN-GM Used your script in the end and it worked. Thank you so much!!!!!!

Posted

If you don't want any students to be able to save to their desktops, why not simply redirect it to a network share that has Read & Execute permissions? :confused:

 

http://i.imgur.com/Czy3amh.png

 

That's what we do and it works fine. You also do not need to mess around with any scripts then.

Posted
If you don't want any students to be able to save to their desktops, why not simply redirect it to a network share that has Read & Execute permissions? :confused:

 

http://i.imgur.com/Czy3amh.png

 

That's what we do and it works fine. You also do not need to mess around with any scripts then.

 

Already done it bruv and it didn't work.

Posted

Hiya,

 

Does the redirection actually working? i.e. is their desktop pointing to the folder where you applied the permissions or is it pointing to their userprofile? I think you may find that the desktop redirection has not happend and its gone back to the default setting of the desktop being in the userprofile. You can check by looking at the registry of the user (i.e. when the user is logged in)

 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop and see where desktop points.

 

You can also check this remotely by getting one the students to login and then from your station navigate to

 

HKEY_USERS\\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop

 

if the value of desktop is %userprofile%\desktop then its redirecting to their normal default desktop which they will have write access to and if its the other folder you specified then i'm not sure why its still letting them save stuff.

 

Ash.

Posted

Hi,

 

Problem 1: Suddenly that script isn't working any more despite working a few days ago. I've checked RSOP and it's definitely being applied.

 

Problem 2: What I've discovered is when a user creates a new doc in desktop, despite the student security group only having read access, the system automatically grants their individual usernames full access to the file/folder. Shouldn't the student security group with read-only permission override this?

Posted
try redirecting to a new share say desktops$ and ignoring ntfs permissions set share permissions to read only for their group and full for admins and leave everyone else off then there should be no way to write to it
  • Thanks 1
Posted
try redirecting to a new share say desktops$ and ignoring ntfs permissions set share permissions to read only for their group and full for admins and leave everyone else off then there should be no way to write to it

 

Cheers, I'll give that a go and let y'all know

Posted

Right people it looks like following advice from @sted it now does what is should do and take notice of the permissions assigned to it. All I can say is the last day or two has been a nightmare, but once again such a simple solution.

 

thanks all.

Posted

The problem here is that you may have the creator owner entry in the ACL which by default has a full control so if user can write to the location it will have full control to that file because that user has created the file if you know what i mean.

 

Ash.

 

Hi,

 

Problem 1: Suddenly that script isn't working any more despite working a few days ago. I've checked RSOP and it's definitely being applied.

 

Problem 2: What I've discovered is when a user creates a new doc in desktop, despite the student security group only having read access, the system automatically grants their individual usernames full access to the file/folder. Shouldn't the student security group with read-only permission override this?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...