- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
At this point, you may have noticed that we didn’t give our users very many permissions on the Users folder. First and foremost, we made sure that one user can’t see inside of another user’s folder. It’s also pretty obvious that we don’t want to give users the ability to do things like take ownership, delete files/folders, or change permissions, but a few of the other missing permissions take a little more explanation.
First off, you don’t want users to have Create files/write data permissions or they can save files into the root of the shared folder. Since we’re redirecting folders, we only want the users to be able to create folders in the root Users folder, but not individual files. Once the user creates a folder named %username%, the CREATOR OWNER permission will take over (since it is a sub-folder of Users) and will give the account full control over the %username% folder and everything inside of it.
Second, List folder/read data is also missing because we don’t want users to be able to enumerate folders in the share. Here’s what it will look like to the end user if they try to go to \\fileserver\Users:
User can't enumerate folders
However, if the user tries to go to \\fileserver\Users\%username%, he can see all of his folders:
User CAN see inside username folder
To the Administrator, you’ll still be able to see everything on the server:
Redirected folders on server
Why would you want to do it this way? The biggest reason is that we’re giving the user the ability to create folders in the Users share. That means that there is nothing to stop a user from creating a few hundred folders and then saving files into those folders inside of Users. By removing the ability to enumerate folders in the Users share, you eliminate the ability of the user to see what is in the folder. It doesn’t stop the user from being able to create other folders or copy data into them, but it makes is much more difficult to use should they decide to try.
The other big benefit you get is that users can’t see the other user account folders that are stored in the Users share. Can’t I do that with Access Based Enumeration? Yes… Access Based Enumeration will essentially hide any files/folders to a user that he/she doesn’t have permissions to see; but, it doesn’t solve the problem of the user being able to create new folders in your Users share. If you enable Access Based Enumeration and allow users to enumerate the contents of the share, they’ll just see their %username% folder and all of the other folders they’ve created there.
In the next post I will show you how to configure folder redirection in Group Policy.
Thank you for the excellent coverage about folder redirection. Looking forward to more about the topic.
Please, consider giving your recommendations regarding the servername part of the UNC path. What is recommended to use NETBIOS name or a FQDN, i.e. in an environment with Windows 7 only PCs and users traveling and connection via VPN to office servers.
Patrick – Thanks for the feedback! Unfortunately, I haven’t been able to find an official Microsoft Best Practice for this topic. For me, it usually depends on the scale of the deployment. On small deployments, I use the NetBIOS name to keep things simple and larger deployments I use FQDN. In your circumstance with remote users, your best bet is probably going to be using the FQDN to ensure that your remote users don’t have problem resolving the name of your file server when they are offsite.
Is it correct that the Administrator can see the Users folders, but not the contents inside? I can view all of the user folders, but still must take ownership to view the contents of the folder itself.
It sounds like you’re referring to the user folders in the C:\Users\%username%\ folders. If you use the configuration outlined in this series, any Administrator on your file server will be able to see inside the contents of your users’ redirected folders.
Great guide, but I have a question for you. If the CREATOR OWNER is given Full control, this means the end-user will be able to change the permissions on the folders/files they create under their %username% folder, allowing them to remove Admins from having any permissions to their files, that is if the user is savvy enough to know how to do it.
To have it locked down as much as possible, I removed the Full Control/Change Permissions/Take Control rights for the Creator Owner account instead of giving them full blow Full Control permission. This in theory would still allow the user to create and delete files/folders within their %username% folder, however this is not the case. After configuring this and testing with a user, their account is still given the Change Permission right for some reason and I don’t get why.
Do you have any recommendations on how to configure permissions so that users can’t change permissions on their files/folders but still be able to create/delete their own files within their %username% folder?
The permissions I recommend are in the previous article in this series. The intent all along in this series was for users to create their own folders are part of the logon process. If you want more complicated permissions, you’re most likely going to need to create the folders manually or as part of an automated process instead of allowing them to be created by the end user.
I actually figured it out. Instead of using the Creator Owner account, you can use the Owner Rights account instead, and assign to it Modify special permissions. This will allow the users to auto create their redirected folders when they log in, but not change permissions on their data. Here’s how:
Share Settings:
-Create the share and make it hidden by adding $ to the end, this way users can’t find it by searching. For example: \\server\UserDir$
-For Share permissions, configure Authenticated Users to have Full Control.
NTFS Settings:
Configure the folder not to inherit permissions and remove all existing permissions.
-Add Domain Admins with Full Control – This Folder, Subfolders, and files.
-Add Enterprise Admins with Full Control – This Folder, Subfolders, and Files.
-Add System account with Full Control – This Folder, Subfolders, and Files.
-Add Authenticated Users with Create Folders/Append Data – This Folder only. Ticking ONLY Create Folders/Append Data still allows user accounts to auto-create their redirected folder in the root of the share, but DOESN’T allow them to go in the root of the share and see everyone else’s user folders.
-Add Owner Rights account with Modify special permissions – Subfolders and Files only. Modify special permissions are basically everything EXCEPT for Full Control, Delete Subfolders and files, Change Permissions, and Take Ownership. Make sure you untick those. Doing this will still allow users to create and delete their own files/folders but WILL NOT allow them to change the permissions on their files/folders.
By setting it up this way, you can have it secured and locked down as much as possible so only Admins can explore the root of the share and see all the individual user folders, but most importantly prevent users from changing permissions on their files/folders.
Refer here for more info: http://social.technet.microsoft.com/Forums/en-US/7abfb366-db58-40fe-a172-2347684d84d6/folder-redirection-prevent-users-from-changing-permissions-on-their-files
I believe that the directory permission “List Folder / Read Data” is required for regular users to perform the initial background synchronization. Without this permission given to “Everyone” (or whatever group is representing normal users) the initial files are NOT synched to the server but instead sit in the user’s local offline files cache.
Newly created files and files manually synched perform as expected, but in order to get the initial synchronization to work, this permission must be enabled. You’re welcome to test this yourself!
This is most unfortunate because that then allows users to navigate to this directory, create new directories, and fill them with data. Do you offer any alternative suggestions that will allow the initial synchronization to happen yet block regular users from navigating to the share?
Thank you!
Thank you for your fantastic guide on folder redirection. I have follwed your guide and everything is working as it should. The redirection is working great although I have a slight issue –
As Administrator if I now need to create a folder in a users profile, let’s say within their Desktop folder, the user see’s the folder but cannot access it. Their user principal name is not in the list security tab properties of the new folder. How can I have the permissions of new files and folders created by the administrator inside a users profile have the same permissions as all their folders in their profile?
I recreated my lab environment and I can’t replicate your issue. When I have a test user log in, the login process creates the folder structure for the test account’s Redirected Folders. If I log in to the file server and create a file or folder, the permissions include the UPN for the user that owns the home directory on the file server and the test user can access the files. It sounds like you’ve either got a permissions problem with your original setup or you’re moving a file from the same NTFS volume and the permissions are moving with the file/folder.
Well, I believe this happens when you are making experiments and your user wasn’t able to create the folders on the share for the first time. The account is created locally and then the profile gets corrupted. If you eliminate the local profile once the permissions are set straight, then logoff and logon, everything works as expected.
Hey Kyle I have done this plenty of times in the past but it we have discovered a problem that I cannot figure out. Server 2008 R2 file server setup with the user share and the appropriate permissions and group policy set to do folder redirection. When new user logs in the first time they get the folder but when you check their permissions instead of full control this folder, subfolders and files only they are getting Special this folder only. The user can create files and folders no problem but if an administrator moves or creates a file or folder in their home folder they will not inherit permissions to use it. I also noticed that Creator Owner has Special permissions Subfolders and files only instead of full control this folder, subfolder and files only.
I’d really need to see a dump of the permissions to say for sure. If you’re having issues with new files getting wrong permissions, the top level folder permissions may be wrong. Moving files is another story entirely… If a file resides on an NTFS volume and is moved to another location on the same NTFS volume, it retains its original permissions. As an example, let’s take a file that is in a share called Marketing. The Marketing share is only available to that department. You’re asked to move (not copy) a Word document from the Marketing share to a user’s Desktop folder (a folder that was redirected to the file server on the same NTFS volume) that is in the Sales department. The file will retain its original permissions and, unless the user has access to the Marketing share files, he/she won’t be able to access the file. If you have Access Based Enumeration turned on, the user won’t even see the file.
I am having the same issue.
Root Folder Permissions:
Creator Owner – Special (Full Control) – Subfolders and Files
System – Full Control – Folders, Subfolders and Files
Users – Special (Traverse Folder / execute file, List folder/read data, Read attributes, read extended attributes, read permissions)
When I place something inside of their profile folder they do not get rights to the folder/files and permissions for that auto created folder is to “This folder only”
Hey Kyle I know what you are saying about the difference between coping a file and moving a file as to how the permissions are retained or inherited. I found out today that this is happening on Server 2012 R2 as well. I created the shared folder and gave Everyone full control on the shared folder. I go to the NTFS security tab on the share and disable inheritance. Now I have Administrators Full control, This folder, subfolders and files. Creator Owner Full control, Subfolders and files only, System Full control, This folder, subfolders and files. I take the two local user groups one has Traverse folder/execute file, List folder/read data, Read attributes, Read extended attributes and Read permissions applies to This folder, subfolders and files. The other has Create files/write data and Create folders/append data that applies to This folder and subfolders. I take both of these user groups and change the applies to and change them to This folder only. This is the local user group on the server which also contains the Domain Users group. At this point the folder redirection and automatic folder creation work for new users except for the rights that are assigned to the new user folder. Instead of Full control This folder, subfolders and files they end up with Full Control This folder only. While this works for the user because they can create files and folders if I have to restore something inside that folder from backup the user does not inherit permissions to the restored files because they were put there by the backup software that is running under a domain service account. Or if I as a domain administrator go in and copy something that was deleted from Shadow copies of their home folder and drop it back in there it will not inherit as the user only has Full Control This folder only. At first I though that this had something to do with the way Server 2008 R2 displays the Creator Owner permissions as Special instead of Full control but now I see that has nothing to do with the issue.
Hey Dusty did you ever figure this out?
I’ve been encountering the same issue as in other comments, where files and folders created inside users’ redirected folders by Admins or SYSTEM cannot be accessed by the users.
However, after a lot of searching for a solution I’ve just come across Microsoft’s KB on the subject (http://support.microsoft.com/kb/274443), which states in the More Information section that:
So, in other words, folder redirection users no longer inherit permissions on Subfolders and Files, and have to be granted those permissions manually (or via scripting I suppose).