Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to reset permissions on user directories and having a bit of trouble with the last step of my script. My script basically takes ownership of the entire user directory, resets the permissions on all files and folders for the directory, explicitly grants the permissions I need, stops all inheritance of permissions from parent folders, sets the rightful owner (specified user) for all files and folders, and then removes the permission I gave to myself so that I could operate on the files. I need this last step to remove myself from ALL files and subfolders, but at the moment it just removes me from the %userDir% and leaves all the inherited permissions below. This is an apparent shortcoming in ICACLS. Does anyone know of any other way to accomplish this?

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /inheritance:r
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%"
share|improve this question
I'm playing around with the unsupported XCACLS.vbs script created by Microsoft and I've had luck employing it for the last line of my script. Instead of this ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%" I've replaced it with cscript.exe xcacls.vbs "e:\Test" /E /R "MYDOMAIN\%username%" This works, but I'd really like to avoid the use of XCACLS.vbs since it has severe performance issues. Any other ideas? –  pk. Jul 21 '09 at 22:09
add comment

2 Answers

up vote 14 down vote accepted

An observation first: Every time you block inheritance you're cutting yourself off from future flexibility. I avoid blocking inheritance at all costs.

If you need users to be able to list the contents of the top-level "E:\Home Directories" folder, for example, consider the following permission:

  • SYSTEM - Full Control - Applied to this folder, sub-folders, and files
  • BUILTIN\Administrators - Full Control - Applied to this folder, sub-folders, and files
  • BUILTIN\Authenticated Users - Read and Execute - Applied to this folder only

The last permission doesn't inherit down into the subfolders. At each subfolder, inheritance remains enabled and you simply specify the user with "Modify" or "Full Control" rights (depending on how you feel about users being able to set permissions inside their home directory). (Typically I set that last permission by adding "Authenticated Users" in the non-"Advanced" Security properties sheet, unchecking the "Read" and "Read and Execute" check boxes. I then proceed into the "Advanced" dialog and change the "Apply onto" setting for that ACE to "This folder only". That's about the easiest way, in terms of number of clicks, to set it.)

Then, your script becomes:

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T

I strongly suspect that the addition of the "Authenticated Users" permission I've described above w/ the inheritance set to "This folder only" will give you what you're looking for in functionality and will give you future flexibility if you find out that you have to set a permission that might need to inherit into all the user home directories in the future.

This is my SOP for user home directories, redirected "My Documents", "Desktop", etc folders, and for roaming user profile directories. It works great.


re: your comment about BUILTIN\Administrators access

I've had various arguments with people about my take on granting BUILTIN\Administrators access over the years, and my take is this:

  • It's easier to solve a certain class of user problems if you can get to their files. It's a pain to "take ownership" and can be quite slow if there are a large number of files present, too.

  • As you've seen with ICACLS, BUILTIN\Administrators can "assign" ownership (besides "taking" it) so there's no "security" added by not having the files accessible to BUILTIN\Administrators in the first place.

  • Unless you're using auditing (and sifting through a potentially huge number of false-positive entries) there won't be an audit trail when a BUILTIN\Administrators user takes ownership of files they shouldn't be accessing, copies them, and then returns the files back to their "proper" owner and permission.

  • In the Microsoft world, Encrypting filesystem (EFS) is meant to solve the problem of keeping unauthorized BUILTIN\Administrators access from happening. NTFS ACLs don't solve that problem. (Obviously, EFS isn't the only show in town. Encryption is the real answer to solving the "limit the network Administrator's access" problem no matter how you slice it.)

To my mind, not specifying BUILTIN\Administrators with access to user home directories (and, in fact, any folder) means that you're increasing the complexity and time needed to resolve issues while providing less than no real security ("less than none" because it imparts a false sense of security where there is none).

I've given up trying to win the argument with people by way of logic. It seems to be an emotional issue with some people. It's like the silly "Deny / Receive As" ACE that gets placed at the root of an Exchange organization to prevent certain privileged groups from opening users mailboxes. It offers no real security (since w/o auditing one could remove / re-apply the ACE as necessary), a false sense of security, and gets in the way when solving real problems.

Even if you don't like my argument about BUILTIN\Administrators having access you want to keep the inheritance hierarchy intact by using "This folder only" inheritance where appropriate. Blocking inheritance in permission hierarchies is a sure sign that something about the design is "broken" (inverted, etc).

share|improve this answer
Do you recommend giving BUILTIN\Administrators full access to the entire directory structure? I'm of the opinion that we (administrators) really shouldn't have full access to everyone's user directories/profiles without taking ownership. –  pk. Jul 22 '09 at 14:09
+1, love the points about false sense of security... –  DCookie Mar 27 '11 at 14:54
add comment

First, thanks for your script excerpt. I've been working on the same thing but was stuck in a different place. On my SBS 2008 box, the below code works for me (assuming it's run elevated, of course). I did an icacls %userdir% /t of a brand new (default) user folder created by the OS, and compared it to the icacls %userdir% /t of a folder after running this script and it looks like all the "O's and I's" are correct. Hopefully it'll work for you as well.

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(oi)(ci)f
ICACLS "E:\Home Directories\%userDir%\*.*" /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%\*.*" /inheritance:r
ICACLS "E:\Home Directories\%userDir%\*.*" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%" /t

Best Regards,

share|improve this answer
Make sure you verify the final line of your script. It was my experience that ICACLS will not successfully remove inherited permissions. It removes the entry on the "MYDOMAIN\%username%" folder, but the permissions of the subfolders are untouched. Therefore, "MYDOMAIN\%username%" will still have access to the subfolders if accessed directly, you just won't be able to browse to them. XCACLS.vbs resolved this for me. cscript.exe xcacls.vbs "e:\Test" /E /R "MYDOMAIN\%username%" –  pk. Aug 14 '09 at 13:36
That's where the . part came in on my edit. doing /inheritance:r on the parent folder, I had the same problem. but doing it on . in the parent folder seemed to do the trick. After running the above, %userdir% has %username%, system, and administrators, but everything under that is just %username% and system, which is how the server set them up initially - just what I wanted. –  user16680 Aug 14 '09 at 14:52
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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