Ok. Here we are trying to set up a Classic ASP website at IIS 7.5 in Windows Server 2008 R2. There is a folder named dbc under the website's root and it has a file which is used to read and write certain information while every page is processed.
The issue is, if I grant IUSR Write Permissions, and IIS_IUSRS Write Permissions, or DefaultAppPool Write Permissions, I get the "Access to the path 'E:..\websiteroot\dbc\filename.txt' is denied"
But If I grant EVERYONE Write access on that dbc folder, then I don't get any error, everything seems perfect.
More Info: The website runs in Classic Pipeline mode, Anonymous Authentication is Enabled (perhaps it's the only authentication enabled).. And I tried Anonymous authentication using IUSR account as well as, Application Pool Identity. In my case, ApplicationPoolIdentity is the Identity for the Authentication of the website. We use a COM+ for file I/O. And Classic ASP Server.CreateObject to instantiate an object out of it. The COM+ runs as a Network Service.
Thoughts? I don't want to grant Write permission to EVERYONE. Am I missing something?
SOLVED: Here's what I did.
My website named CipherDemo was running under an AppPoolIdentity in IIS 7.5, that could be located by the Identity IIS AppPool\CipherDemo. I used ICACLS to give RW permissions on that folder.
and the COM+ that was actually doing the file I/O was running under the Network Service Identity. When I was using Process Monitor to trace the Access Denied Error, it turned that Network Service has only a Read permission on that folder.
I used ICACLS "foldername" /grant:r "NT AUTHORITY\NETWORKSERVICE":(OI)(CI)RXW /T to grant Write access on that folder.
And solved it.
I was on an intention that since the website runs as CipherDemo Identity, this will be the account that will be used to access the file via COM+. But it's embarrassing to find out that the COM+ would still work on it's own Identity boundaries.
User Right Assignment don't have a "default" configuration.
This is due to the fact that these settings are modified by when certain Windows roles and features are installed. Other applications can also modify these rights, creating a situation where a one-size-fits-all definition of default would leave many systems half functional.
Further, the User Right Assignments fall into a broader category of GP settings that cannot be conveniently reverted to a default state due to an effect known as Group Policy tattooing.
You must apply your own "default" settings
If you only have a few User Rights to modify, edit the settings through the Local Group Policy editor () and refer to another workstation that has the desired rights assignments for your configuration.
If you have many User Rights to modify, then consider using the Secedit command-line tool to export the settings from a computer with the desired configuration and then apply them into the target machine. Example commands:
Export the current machine's User Rights Assignments:
Apply the exported User Rights Assignments to the local machine:
This Microsoft support article explains why it's not possible to restore Windows Security settings to a so-called default state and offers some possible workarounds.
This and this article discuss Group Policy tattooing and its implications for Windows Security Settings.