具有 Windows 身份驗證的 IIS 7.5 Web 應用程序是否要求最終使用者具有文件權限？
簡潔版本：
對於具有 Windows 身份驗證的 IIS 7.5 Web 應用程序，最終使用者是否需要具有讀取文件訪問權限？
長版：
我有一個使用 Windows 身份驗證的 Intranet ASP.NET Web 應用程序。它安裝在數十家不同的公司，通常驗證工作正常：使用者導航到該站點，例如
http://appserver/MyApp，該應用程序辨識他們登錄的身份並相應地顯示頁面。我剛剛在一個新客戶端上安裝了它，遇到了一個問題：例如，當連接到時，系統會
http://appserver/MyApp提示我輸入 Windows 憑據，但在輸入它們後，我會反复提示。在多次重新輸入憑據後，我看到一個 401 錯誤頁面，上面寫著“401 - 未經授權：由於憑據無效，訪問被拒絕。”。因此，它不僅沒有通過我的身份，而且即使輸入使用者名和密碼，它仍然拒絕訪問。向應用程序的最終使用者授予讀取和執行權限可以解決這個問題，但我認為這根本沒有必要。
在 Windows 應用程序事件日誌中，有一條消息“請求的文件授權失敗”以及執行緒帳戶名稱：NT AUTHORITY\NETWORK SERVICE 和使用者：[正確的工作站使用者的域帳戶]。這表明文件訪問是使用使用者的身份執行的，而不是網路服務的 AppPool 身份。果然，如果我授予最終使用者對應用程序目錄的讀取和執行權限（我沒有嘗試只讀），那麼一切正常：當使用者瀏覽到該站點時，他們會自動進行身份驗證，而不是提示，並且網站正確辨識自己的身份！因此，我的解決方案是向應用程序目錄中的每個人授予讀取和執行權限…
這似乎很奇怪。據我記得，我以前在 IIS 7.5 中從來不需要這樣做，而且在 IIS 6 或 IIS 7 中絕對不需要這樣做。這是 IIS7.5 的新事物嗎？文件說預設情況下模擬是關閉的。我在 web.config 中添加了一個元素以確保刪除了網路服務以外的文件權限，但問題仍然存在。
有什麼想法嗎？對於 IIS 7.5 上的 Windows Authenticated 站點，最終使用者需要對 Web 伺服器文件的文件權限是否正常？
一些相關細節：
- 網路服務對應用文件夾具有完全控製文件權限。
- 當從伺服器本身連接時，我被提示輸入憑據，但在輸入憑據後，我已通過身份驗證並且應用程序正常工作，包括顯示我的 Windows 登錄名以及連接和檢索數據庫中的數據。後來我確定它正在提示輸入憑據，因為
http://localhost它位於受信任的站點中，因此未被辨識為 Intranet 區域，因此沒有傳遞身份。我還確定它作為此使用者身份工作，因為它是具有文件權限的管理員使用者。- Web 伺服器正在執行 Windows Server 2008 R2 / IIS 7.5。在我安裝它之前，它上面沒有 IIS。我安裝了預設功能以及 Windows 身份驗證、ASP.NET 以及可能的其他一些項目。我安裝的一個使用 IIS、匿名身份驗證和 .net 2.0 的單獨 WCF 應用程序在該 Web 伺服器上執行良好。
- 應用程序安裝過程是文件的手動副本、IIS 應用程序池和 Web 應用程序的創建、更新連接字元串等。
- 我檢查了 IE 安全設置。它將伺服器辨識為 Intranet 區域，並選擇了“僅在 Intranet 區域中自動登錄”選項。同樣在“高級設置”中，“啟用集成 Windows 身份驗證”選項已被選中。
- 安裝 IIS 後，我執行
aspnet_regiis -i了 .net 2.0 和aspnet_regiis -iru.net 4.0。- 我的應用程序禁用了匿名身份驗證，並啟用了 Windows 身份驗證。
- 該應用程序在 ASP.NET v4 上執行，但我安裝的另一個應用程序在執行 ASP.NET v2 時遇到了同樣的問題。
- 該應用程序使用 Identity = Network Service 和 32 位模式執行。
- 數據庫連接字元串包括
Trusted Connection=True和數據庫權限被授予 Web 伺服器帳戶，[domain]\[server]$例如DGM\MyServer$。- 在 IIS > 身份驗證 > Windows 身份驗證 > 提供程序中，列表首先是協商，然後是 NTLM。我嘗試重新排序，所以 NTLM 是第一位的。
- 在 Windows 安全事件日誌中有一系列 Microsoft Windows 安全審核事件：登錄和註銷。他們表示登錄成功並顯示工作站使用者的使用者 ID。這是從我從另一個工作站連接並在幾次嘗試後收到 401 Unauthorized 時開始的。
我看到有人在這里報告了這個問題，但沒有解決方案。最初我在ASP上發布，然後在IIS論壇上發布，到目前為止沒有任何答案。
更新： 這篇 msdn 文章說
當啟用 Windows 身份驗證但禁用模擬時，ASP.NET使用從瀏覽器發送的憑據在文件授權模組中執行文件訪問檢查*（我的重點）* . 不需要啟用模擬，因為 FileAuthorizationModule 模組確保請求使用者被允許對資源進行讀取訪問或寫入訪問，具體取決於執行請求之前的請求動詞（例如，GET 或 POST）。此行為適用於輸入託管程式碼的任何請求。在早期版本的 ASP.NET 中，訪問基於諸如“Default.aspx”之類的 URI 的文件會觸發訪問檢查。在 ASP.NET MVC 應用程序中，通常使用無副檔名 URL 執行對資源的訪問，此檢查通常不適用，因為沒有要檢查的物理文件。在這種情況下，FileAuthorizationModule 類回退到檢查文件夾的訪問控制列表 (ACL)。
這確實表明最終使用者需要對文件（在 .aspx 的情況下）或文件夾（對於 MVC）的權限……儘管這似乎仍然有些隱蔽且不確定。這篇關於應用程序池的文章說它們被用作保護資源的身份，這與需要向最終使用者授予權限的想法相矛盾。除非應用程序池和網路服務的規則不同，否則可能會出現這種情況，但會令人驚訝。
最簡潔的答案是不。在 IIS 7.0 和 IIS 7.5 中使用 Windows 身份驗證時，您不需要授予文件訪問權限。
我們之所以能夠發現這一點，是因為我們的伺服器管理員嗅到了向使用者和組授予文件級別訪問權限的路線所產生的安全和管理問題。
對於處理此問題的任何人，或者如果您正在設置新的 IIS7/IIS7.5 伺服器和/或從 IIS 6 遷移，這裡有一篇文章為您提供了所有需要修改以避免的 Windows 身份驗證選項和配置授予個人或團體文件級訪問權限。
請閱讀 POST 末尾的兩條評論，以獲得對本文中使用的方法的一些有效批評。
<http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk>
除了文章中的資訊，請注意 IIS 7.5 沒有使用 system.web 的 web 配置標籤（至少在我的 MVC 4 應用程序中沒有）。
它在 system.webserver 標記中查找授權配置（您需要在其中列出使用者訪問您的應用程序所需的 Windows 域\組）。
– DSB
是否允許經過身份驗證的使用者訪問 app 文件夾？
