basicchannel Posted September 6, 2013 Posted September 6, 2013 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
FN-GM Posted September 6, 2013 Posted September 6, 2013 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 1
Valyyn Posted September 6, 2013 Posted September 6, 2013 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.
basicchannel Posted September 6, 2013 Author Posted September 6, 2013 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!!!!!!
Arthur Posted September 6, 2013 Posted September 6, 2013 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? 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.
basicchannel Posted September 6, 2013 Author Posted September 6, 2013 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? 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.
FN-GM Posted September 6, 2013 Posted September 6, 2013 We redirected to a local drive but didnt work either. The icons are from the user profile not the redirected folder.
spc-rocket Posted September 6, 2013 Posted September 6, 2013 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.
spc-rocket Posted September 9, 2013 Posted September 9, 2013 I don't think that is possible, otherwise you may have issues that are being reported on.
basicchannel Posted September 12, 2013 Author Posted September 12, 2013 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?
sted Posted September 12, 2013 Posted September 12, 2013 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 1
basicchannel Posted September 12, 2013 Author Posted September 12, 2013 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
basicchannel Posted September 12, 2013 Author Posted September 12, 2013 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.
spc-rocket Posted September 12, 2013 Posted September 12, 2013 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?
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now