Setting Up Win2008 R2 Server – IIS_IUSRS Permissions

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.

Edit

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

This sounds like a user access control problem.

With UAC turned on you are not a member of the Administrators group even if you log on as local administrator. You only "belong" to that group when you "run as administrator". So if you launch notepad "as administrator" you will be able to edit the files with no problem. So the answer is to either turn off UAC or grant your user account explicit Modify permissions to the file. Yes it is really annoying.

So that fixes the problem of you editing the config files, but it sounds like you want the app to also edit files. That sounds a bit dangerous, but probably acceptable if you are controlling who has access to the application.

The best approach is to put the web app in its own application pool not the default app pool. Then set the identity on the app pool to a specific user account, not the default network service account. Then grant that account the permissions it needs on the specific files and/or folders.