如何正確設置IIS 7應用程序池標識？

Question

將我的網站部署到IIS7.5后，我發現了一個奇怪的行為：默認情況下，當應用程序池標識為ApplicationPoolIdentity （如IIS應用程序池標識中所推薦的那樣）， Ninject似乎被忽略，因為我在創建時遇到以下錯誤第一個控制器：

System.InvalidOperationException：嘗試創建類型為“..MainController”的控制器時發生錯誤。 確保控制器具有無參數的公共構造函數。 ---> System.DirectoryServices.DirectoryServicesCOMException：發生操作錯誤。

我試圖將IIS AppPool\\<MySiteAppPool> FullAccess授予包含該站點（包括所有子文件夾和文件）的文件夾，但這並沒有改變任何內容。

但是，當我將應用程序池標識設置為任何域帳戶（即使是簡單的帳戶，沒有管理權限，以及沒有任何訪問該站點的文件夾）時，它仍然可以正常工作。

根據通過NuGet包設置MVC3應用程序教程來安裝Ninject。

我不確定，如果它是相關的，該站點應該在具有Windows身份驗證的域Intranet中工作。

因此，唯一的問題似乎是應用程序池標識。 至於我渴望使用推薦的方式，我希望擁有ApplicationPoolIdentity ，而不是域帳戶。

這有什么用？ 是否可以將所有這些混合在一起？

---

這是一個具有類似問題的SO線程： ASP.NET MVC 4 + Ninject MVC 3 =沒有為此對象定義的無參數構造函數 。 但是根本沒有合適的答案。

---

作為刪除的評論建議，我嘗試使用NetworkSerive作為身份。 它運作正常。 但是，我想這並不比非特權域帳戶好多少。

---

編輯

突然發現另一個依賴：應用程序池標識用於sql server上的Windows身份驗證，但我希望在那里使用客戶端用戶的憑據。

根據評論

同意通過模擬可以使用經過身份驗證的憑據訪問遠程SQL Server。

---

但是，仍然不清楚ApplicationPoolIdentity和Ninject的問題是什么。

在這個問題的最頂部提到的文章讓我想到這可能是因為虛擬帳戶沒有用戶配置文件 。 這個方面對我來說仍然不清楚，因為仍然可以使IIS使用LoadUserProfile屬性加載用戶配置文件。 如果虛擬帳戶沒有配置文件，我無法獲取，IIS將加載什么？

有人說：

IIS不會加載Windows用戶配置文件，但某些應用程序可能會利用它來存儲臨時數據。 SQL Express是執行此操作的應用程序的示例。 但是，必須創建用戶配置文件以將臨時數據存儲在配置文件目錄或注冊表配置單元中。 NETWORKSERVICE帳戶的用戶配置文件由系統創建，始終可用。 但是，通過切換到唯一的應用程序池標識，系統不會創建任何用戶配置文件。 只有標准應用程序池（DefaultAppPool和Classic .NET AppPool）在磁盤上具有用戶配置文件。 如果管理員創建新的應用程序池，則不會創建用戶配置文件。

但是，如果需要，可以通過將“LoadUserProfile”屬性設置為“true”來配置IIS應用程序池以加載用戶配置文件。

---

我在serverfault.com上找到了以下主題：

如何將活動目錄權限分配給默認應用程序池標識

在那里還指出，應用程序池標識不能用作網絡服務，特別是查詢AD。

Answer 1

iispool \\ appPoolName帳戶被稱為虛擬帳戶並被添加到Windows 2008.這個想法認為它們並不是真正意義上的帳戶。 他們允許的是增強使用基本帳戶的流程之間的安全性。

您計算機上的許多服務都使用networkService，這是一個具有網絡訪問權限的內置帳戶。 因此，如果攻擊者要利用其中一種服務，則可以訪問在同一帳戶下運行的任何其他進程。 虛擬帳戶（例如IIS使用的帳戶）通過顯示為不同的帳戶來防止這種情況，同時仍然是同一個帳戶 - 您的asp.net應用程序仍然在技術上作為網絡服務運行並授予此帳戶訪問權限仍然有用的功能。 這也意味着如果您需要訪問網絡資源，iispool帳戶會這樣做，因為網絡服務會使用計算機域帳戶。

如果要訪問遠程SQL Server，則應添加此帳戶以允許從Web服務器進行訪問。 我不建議使用模擬，除非你真的需要查看用戶在SQL服務器上的用戶。 如果您將其關閉，您的應用安全性會更簡單。

至於為什么你的注射不起作用，它可能是你的任何依賴失敗。 如果controllerA注入了ClassB，而ClassB又注入了ClassC並且該類沒有注入ClassD，那么整個鏈就會失敗。 我已經發生了這種情況，並且花了一段時間才意識到它是從我所看到的東西中刪除的東西。

Answer 2

從問題中的細節來看，它聽起來很像是一個導致拋出COMException的權限問題，這阻止了Ninject實例化MainController 。 該異常與System.DirectoryServices有關， System.DirectoryServices是用於查詢Active Directory的類。

當IIS在正常的應用程序池帳戶下運行時，這些帳戶無權對Active Directory進行查詢，並且可能拋出COMException 。 我認為異常中的實際消息（找不到無參數構造函數）有點像紅色鯡魚，並且Ninject試圖回退到另一個構造函數，因為正常的消息不起作用。

這可以解釋為什么當您更改IIS應用程序池以作為域帳戶運行時，它突然起作用，因為該帳戶確實有權查詢域。

從您自己是否正在使用System.DirectoryServices或Ninject / IIS / ASP是否正在使用它們的問題中不清楚。 如果您自己使用它們，請確保AD類中的任何構造函數都不能拋出異常（捕獲它們並記錄它們或其他東西），這會阻止您的應用程序在啟動時崩潰。 你可能會發現我上面說的關於權限的內容。

如果您需要IIS作為普通應用程序池帳戶運行（這是一個好主意），但仍然將AD作為域用戶進行查詢，那么您可以指定DirectoryEntry的憑據並使用DirectorySearcher進行AD搜索。 如果您使用的是.Net 4或更高版本，那么我建議您使用新的System.DirectoryServices.AccountManagement類（這也允許您指定憑據）。

使用該方法，您不需要對AD查詢進行任何模擬，您的應用程序池仍可以作為普通的應用程序池帳戶運行。