對每個人的寫訪問都有效，IUSR、IIS_IUSRS、DefaultAppPool 不起作用。為什麼？
行。在這裡，我們嘗試在 Windows Server 2008 R2 的 IIS 7.5 上建立一個經典的 ASP 網站。在網站的根目錄下有一個名為 dbc 的文件夾，它有一個文件，用於在處理每個頁面時讀取和寫入某些資訊。
問題是，如果我授予 IUSR 寫入權限、IIS_IUSRS 寫入權限或 DefaultAppPool 寫入權限，我會收到“拒絕訪問路徑 ‘E:..\websiteroot\dbc\filename.txt’”
但是，如果我授予每個人對該 dbc 文件夾的寫入權限，那麼我不會收到任何錯誤，一切看起來都很完美。
更多資訊：該網站以經典管道模式執行，啟用匿名身份驗證（也許這是唯一啟用的身份驗證）。我嘗試使用 IUSR 帳戶以及應用程序池身份進行匿名身份驗證。就我而言，ApplicationPoolIdentity 是網站身份驗證的身份。我們使用 COM+ 進行文件 I/O。而Classic ASP Server.CreateObject 則將一個對象實例化出來。COM+ 作為網路服務執行。
想法？我不想授予每個人寫權限。我錯過了什麼嗎？
已解決：這就是我所做的。
我的網站名為 CipherDemo 在 IIS 7.5 中的 AppPoolIdentity 下執行，可以通過 Identity IIS AppPool\CipherDemo 定位。我使用 ICACLS 為該文件夾授予 RW 權限。
並且實際執行文件 I/O 的 COM+ 在網路服務標識下執行。當我使用程序監視器來跟踪訪問被拒絕錯誤時，發現網路服務對該文件夾只有讀取權限。
我使用 ICACLS “foldername” /grant:r “NT AUTHORITY\NETWORKSERVICE”:(OI)(CI)RXW /T 授予對該文件夾的寫入權限。
並解決了它。
我的意圖是，由於網站以 CipherDemo Identity 執行，這將是用於通過 COM+ 訪問文件的帳戶。但是令人尷尬的是，COM+ 仍然可以在它自己的身份邊界上工作。
在 IIS 7.5（以及可選的 IIS 7 中）下，所有工作人員都使用應用程序池標識執行：使用者“IIS AppPoolPoolName”。
授予該使用者而不是每個人的訪問權限（您需要在選擇身份對話框中輸入名稱 - 它不會顯示在查找功能中）。
iis.net上有一個非常有用的頁面，其中涵蓋了更詳細的內容。
另請注意：在 IIS7 (Server 2008) 下：
- 您可以在高級設置中為每個應用程序池設置應用程序池標識。
- 沒有 GUI 支持，因此您需要命令行來設置權限 (
icacls.exe)。最後，SQL Server 的標識選擇也不知道應用程序池標識：使用
CREATE LOGIN和CREATE USER最初，此後 GUI 可用於授予角色等。