1

We use the folder redirection group policy to place users' My Documents folders on a network share.

We have configured the share with Microsoft's recommended NTFS permissions, as defined here: https://support.microsoft.com/en-us/help/274443/how-to-dynamically-create-security-enhanced-redirected-folders-by-usin. Specifically:

  • 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)

However, that KB article also states (key points in bold):

By the end of May 2017, all supported operating systems converted the CREATOR OWNER ACE to:

    <Folder-User> - Full Control (Apply onto: This Object only)

Whereas this does not affect the daily operations of the folders for the users, it makes a difference when the administrator has to work on the contents of the home folders or redirected folders.

If you want to make sure the user to get the inheritable full control on all child objects, you have to:

Create the folder matching for the users samaccountname by yourself. Set the permissions that are needed for the folder, omit the Everyone ACEs above, and make sure that you have the ACE:

    <Folder-User> - Full Control (Apply onto: This Folder, Subfolders and Files)

In other words, if SYSTEM creates a subfolder in a user's folder, the user won't be able to access that subfolder because they no longer inherit full control of it like they used to.

Microsoft's workaround for this is to manually create the user's root folder and manually set the user's permissions with the necessary scope.

Is there any way to automate this via group policy, or is scripting the only option here?

  • The addendum to that article contradicts itself and is oddly written. Have you confirmed for yourself that the settings described in the original article don't work? – Harry Johnston Jul 6 '18 at 7:30
  • @HarryJohnston Yes, confirmed. With CREATOR OWNER set to have full control on subfolders and files at the root, the user then gets granted full control on this folder only when their My Documents folder is generated. If SYSTEM subsequently creates a subfolder in there, the user has no permissions on it at all and cannot access the contents. This matches the behaviour alluded to in the addendum. – morbiD Jul 6 '18 at 8:17
  • Thanks for the clarification; I'll post an answer shortly. – Harry Johnston Jul 6 '18 at 10:40
0

That's the expected behaviour for CREATOR OWNER, and it is unlikely to have ever been any different; I think the addendum to the article is misleading in that respect. In my experience, it wouldn't usually be a problem, because you don't usually want to add stuff to the user's folder anyway. That's probably why the original article never mentioned it.

If you aren't going to create each user's directory in advance with explicitly chosen permissions, then as far as the group policy goes, you only have two options: if you set "Grant the user exclusive rights" option, they get full access to the entire folder and contents, but nobody else does; if you don't set it, they only get access to the content they created themselves.

If you go with the first option, you can use backup privilege to bypass the permissions whenever you want to add content. This is elegant, but can be inconvenient because the built-in tools for using backup privilege are fairly limited.

If you go with the second option, you can change the permissions on the user's folder before you add content; or you can explicitly set the permissions on the content that you're adding.

Another approach (as you suggest) is to use a group policy logon script to change the permissions on the user's folder when the user first logs in. This may be the most convenient option if whatever process is adding content to the user's folder isn't under your control.

  • Not that it affects your answer, but I think the expected behaviour has changed at some point in time. For reference, see comments from Joel and Kyle here. Joel seems to be experiencing the same problem as me, while Kyle (the article's author) says that's not the expected behaviour and can't reproduce the issue in his lab. There are similar reports from other readers there, which again seem to confuse the author. – morbiD Jul 6 '18 at 14:11
  • If I get a chance I'll run up a VM with an old version of Windows next week and see whether the behaviour of CREATOR OWNER is any different. Although I suppose it might be the behaviour of redirected folders that has changed, that would be a lot more work to check. As you say it doesn't really matter, since we have to deal with things as they are now. – Harry Johnston Jul 6 '18 at 22:58
  • Trying to avoid using a logon script to solve this, so it seems like our best bet is to use powershell to create the user's folder in advance, at the same time as their AD account. Would still be interesting to confirm whether there has indeed been a change in behaviour though. – morbiD Jul 13 '18 at 11:04
  • I don't understand how Kyle got his results, as far as I can see that shouldn't have worked. Perhaps I'm overlooking something - or I dunno, maybe there's a registry key somewhere that changes the behaviour. It isn't a (recent) change in the way CREATOR OWNER works, though; I've tried it on a Windows 2000 VM - as far back as I can go at the moment - and CREATOR OWNER behaves the same way as Windows 10. (It might have worked on Windows NT, because AFAIK that didn't have inheritance flags at all; but then I'm not at all sure it had CREATOR OWNER either.) – Harry Johnston Jul 16 '18 at 21:09
  • But anyway, if you have the option to create the folder (and set explicit permissions) at the same time you create the account, that's always the best choice, because it means that nobody can preempt the creation of anybody else's directory. – Harry Johnston Jul 16 '18 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.