IIS and users group

Question

In Windows Server 2012 R2 IIS is running as a web server under usual conditions. The web content however is not from c:\inetpub\wwwroot\ but from some other folder. The web applications are still running under their own user that is from the defaultAppPool.

I actually forgot to give ever give IIS_IUSRS read/execute rights to the web content folder. The folder did give access to users though. I only added IIS_IUSRS read/execute/write rights if a subfolder needs to be writable.

Wanting to tighten security a bit, I went through the access rights of the web content folder, and learned by trial and error that now access for IIS_IUSRS was missing, it is the access for the users group that is responsible for everything to still work. Because when I remove access to the users group, the application stops working.

I tried giving access to some other accounts/groups and I figured out that giving access to both users and IIS_IUSRS individually get my application running. Giving access to just IIS APPPOOL\ doesn't. But giving access to my specific application pool user (EG IISAPPPOOL\nl-x-homepage) does. And this very last bit is what I want, as I don't want one application to be able to access files of some other application.

But I was wondering... How do the IIS like accounts work exactly? Why does granting access to users also work for my application pool to access the web content folder? I cannot see my specific application pool user in the lusrmgr, but I guess that my specific application pool user is in the users group, or in some other group that is in the users group. Can anyone confirm this?

And as a last question to this matter: to have specific folders 'password protected' I have created a normal user in Windows, removed that user from the users group, and in IIS Manager I went to that folder and did Authentication -> Basic Authentication -> Enabled, and in Authentication Rules I have set an Allow rule for my newly created Windows user account. This works. But analyzing the read/write access I was surprised to learn that though the application is running under the application pool user, the application pool user only needs read rights (no write rights), and the newly created Windows user needs to have both read and write rights on top of that for the folder to be writable. Can someone help explain why this works this way?

Answer 1

The behavior you are encountering seems quite logical to me.

IIS_IUSRS is a group, not an account, whose only purpose is to enable its members to be assigned as app-pool identities, so adding it by itself is not enough (as you found out).

The Users group contains the ASPNET account which has enough permissions for the website to work, so adding it was enough for default permissions. I believe that the ASPNET account is the one used as DefaultAppPool.

A file or folder created by a user has always the read permission, because the creator is the owner and has all permissions. In the case where another user has created the file or folder - giving only write permissions without read never worked in Windows, since read access is required to check permissions and available space and the like before being able to write.

Answer 2

IIS_IUSRS is IIS Worker Process Accounts group. This built-in group has access to all the necessary file and system resources so that an account, when added to this group, can seamlessly act as an application pool identity.

If you right click the domain and open up Edit permissions, you should see the listed groups and permissions. Under the Security tab, you will see MACHINE_NAME\IIS_IUSRS and also the /Users. IIS automatically has read-only permission on the directory.

For every application pool you create, the Identity property of the new application pool is set to ApplicationPoolIdentity by default. The IIS Admin Process (WAS) will create a virtual account with the name of the new application pool and run the application pool's worker processes under this account by default. Whenever a new application pool is created, the IIS management process creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name "MyFirstPool," a security identifier with the name "MyFirstPool" is created in the Windows Security system. From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console. This is the normal behavior. If you want to provide access to a certain folder, just add this to the folder by editing the permissions. However, you gotta check the default authentication configuration (anonymous identity) and see if proper selection is available, or configure it to avoid access errors.

More on Application Pools.

This post addresses the rest of the questions. Inheritance.

Obviously Windows user you are adding here requires permissions as the account must inherit permissions from necessary groups. Read permission here is vital. It is meant to access the local resources, however.