Permissions required for secure roaming profiles & redirected folders

This post could also be titled “How to break permission inheritance properly, without breaking everything else,” and the advice applies well beyond the scope of maintaining roaming profiles and redirected folders.

I often run into a lot of new clients that are incorrectly configured when it comes to redirected folders & roaming profiles.  Specifically, the NTFS permissions / security ACL’s tend to get borked, and be incorrect. The number one mistake that I see being made is this: the inheritance of permissions is usually broken / disabled in such a way that all the default or SYSTEM permissions are stripped out. Trust me, you do not want to do this, or you will have problems.

Even when explicit permissions are manually configured on each folder after the fact, you may still see issues such as users not able to apply a redirection policy, or users getting logged into a “temporary” profile, or users not being able to access or write to their redirected folders, and so on. In some cases, I’ve also seen this affect backup agents which rely on the default SYSTEM or Administrator-level permissions to successfully take backups. Plus you may have to manually configure redirected folder structures for new users rather than letting the system take care of it automatically.

Now I generally do not recommend breaking inheritance unless it is absolutely necessary. I prefer to create all the permissions you need on root-level shares and grant access based on that level to those resources directly, when possible. However, there are cases when broken inheritance may be required–when you have a root level directory that all users need access to, and a sub-folder that requires more restrictive access. User profiles are a perfect example of this. Oftentimes admins do not want other users being able to casually browse directories belonging to other individuals.  So you will need to break inheritance in this case. The correct way to go about this is as follows:

• From the Advanced security settings dialogue box on the shared folder, Disable inheritance
• Choose the option to Convert the inherited permissions into explicit ACL entries
• Remove only the entries that you do not want in place (e.g. Read access for all Domain users)
• Add back in any additional entries that may be required for the purposes of the folder
• Always leave the SYSTEM and CREATOR OWNER permissions alone

Now, in the case of redirected folders, what exactly do you need to “add back in?”  Luckily, there are a number of online references where this is documented by Microsoft.  For example here and here.

Not that the internet needs yet another redundant reference out there on the same topic, but I will include it below also for my own reference library, and as well to explain why these are required–because the result of not including these permissions will have consequences that you do not want.

• CREATOR OWNER – Full Control (Apply onto: Subfolders and Files Only)
• System – Full Control (Apply onto: This Folder, Subfolders and Files)
• Domain Admins – Full Control (Apply onto: This Folder, Subfolders and Files)
• Everyone – Create Folder/Append Data (Apply onto: This Folder Only)
• Everyone – List Folder/Read Data (Apply onto: This Folder Only)
• Everyone – Read Attributes (Apply onto: This Folder Only)
• Everyone – Traverse Folder/Execute File (Apply onto: This Folder Only)

There, I blatantly plagiarized from an article I mentioned above. Now, I will say this: Instead of using “Everyone” in the above examples, it is okay to limit this down to “Domain Users,” and in fact, I think that it is a better idea to do so. Second, as promised, here is an explanation of why these entries are all necessary.

CREATOR OWNER – This should be a default/inherited permission if you break inheritance correctly per my above advice, and convert to explicit ACL entries. If you don’t have this in place, then adding a new user may not work right.  For example, the first time a new user logs in, a folder structure for their roaming profile/redirected data will be automatically generated.  That is, unless you are missing this permission–then they may not be able to create or take ownership of the new sub-directories.

SYSTEM – Another default / inherited permission that should be left alone in almost all cases. This should be intuitive, but you want the system to retain access to everything on itself. Backup agents that rely on SYSTEM permission also need to be able to leverage this in order to take successful backups.

Domain Admins – Technically optional, if you refer to the MSDN article. But in most cases, it makes sense. Administrators sometimes need this level of access to browse & retrieve files, restore files from backup, troubleshoot problems with access or what have you. The proper way to limit administrative access is to limit this level of superuser access to the people and the times it is required. So a network administrator’s “main” or default user account should NOT be a domain administrative user, period. They can have a separate account that is leveraged only in those cases when it is required. This “position of least privilege” is a well known and well-documented best practice in the industry, yet it is often skirted, especially in the SMB space.

Everyone (or Domain Users) – Notice that these permissions apply to THIS FOLDER ONLY (not Subfolders and Files). The users must be able to “hang out” in this directory itself, enumerate its objects and interact with them to some extent. Furthermore they must be able to create new folders (namely, their own folders).  But you wouldn’t want the same to be true for the subfolders which belong to other users. When a user creates their own folders, for instance by logging into the network for the first time, they will become the owners of said subfolders and all files and therefore have Full Control access over those subdirectories (see CREATOR OWNER above). For pre-existing user data, just be sure to give ownership and Full Control access back to the respective security principals, if such entries do not exist already. If you have ever subsequently taken ownership of these subfolders as an administrator, you might notice that the next interactive login for the user doesn’t go so well–they might get a strange experience (temporary profile) or they are unable to apply a redirection policy or write to their folders properly. If you ever do need to take ownership of a user’s folder temporarily, be sure to reassign ownership back after the fact.

That is the long-winded version of it.  More information than most of us need, perhaps, but I hope that it helps someone out there do this better, and avoid the unnecessary problems that I am too often being paid exorbitant amounts of money to correct.