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?
Best Answer
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.