..ActiveDirectory.ActiveDirectorySite.getComputerSite().name 返回錯誤：ActiveDirectoryObjectNotFoundException
感謝觀看：希望這不僅可以幫助以後的其他人，而且可以幫助我們現在！（請溫柔一點，這是我在 Stack 上的第一個問題，儘管我已經是很長時間的使用者/貢獻者了）
情況 (SNAFU) AD 站點感知應用程序正在從 AD 中提取一些資訊。此應用程序只能連接到伺服器託管的 Active Directory 站點內的控制器；如果沒有找到該站點的控制器，我們會遇到更大的問題，但程式碼會處理這種可能性。
為此，我們打算：
- 獲取託管 Web 應用程序的伺服器所在的站點名稱。
- 利用該站點名稱資訊查詢 DirectoryServices 以獲取站點內的控制器列表
- 遍歷控制器，直到我們得到所需資訊的有效響應。
所以虛擬碼：
System.DirectoryServices.ActiveDirectory.DirectoryServices.GetComputerSite().Name獲取伺服器所在站點的名稱…然後循環遍歷
System.DirectoryServices.ActiveDirectory.DirectoryServices.ActiveDirectorySite直到我們找到與獲取的名稱相匹配的站點。現在我們有了這個集合，我們可以從 servers 屬性中請求特定的伺服器。最後通過伺服器，請求所需的 AD 資訊。
問題： 第一步，
GetComputerSite().Name返回錯誤：ActiveDirectoryObjectNotFoundException在我們的開發環境中，這工作得很好。在我們的生產環境中不會。
我們驗證了伺服器在域中，並且通過檢查其他堆棧文章中提到的系統資料庫項定義了一個站點
更多研究將我們引向一篇描述類似問題的技術網文章。我們使用提到的 powershell 腳本來查看我們的 Web 伺服器會發生什麼：
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()它返回了伺服器和我們期望找到的 8 個控制器的列表；連同正確的站點名稱；與系統資料庫中的相同。因此，這導致我們發現預設應用程序池 NetworkServices 與 ApplicationPoolIdentity 之間的權限差異。正如我們現在所知道的那樣，Web 伺服器可以看到站點和伺服器……那麼為什麼 Web 應用程序不能呢？
我們發現通過從 ApplicationPoolIdentity 切換到 NetWorkServices 站點再次工作（這恰好是開發設置並解釋了為什麼開發工作但生產不會工作。但是，因為這不再是預設的 IIS 7.5 配置（ApplicationPoolIdentity 是）；和我們傾向於嘗試保持預設值，因為更新檔有時會將設置移回預設值……我們希望找到更接近 MSFT 方向的更穩健的長期答案。
問題：
- 是否有更好的方法來處理伺服器站點內的活動/響應控制器並訪問使用者部門資訊？
- 需要向 ApplicationPoolIdentity 添加哪些權限才能允許此應用程序訪問 AD 服務？
其他相關文章
- 如何正確設置 IIS 7 應用程序池標識？
- 使用應用程序池標識的 IIS 應用程序失去主令牌？
- https://serverfault.com/questions/81165/how-to-assign-permissions-to-applicationpoolidentity-account
不幸的是，到目前為止，我們發現的所有內容都與設置查看文件夾/文件系統的權限有關，但不使用 AD 伺服器（或者我們是否需要授予對包含正在使用的 AD 類的 DLL 的特定文件夾的訪問權限？
更新： 我們認為考慮到錯誤，問題可能在於 ApplicationPoolIdentity 無法訪問 System.DirectoryServices.dll，因此我們明確授予了權限
cacls.exe %windir%/assembly/System.DirectoryServices /e /t /c /p “OurAppPoolIdentityAcct”:R它開始工作了！！！
我們簡直不敢相信，所以我們撤消了更改……並重新啟動了 IIS……它仍然有效……
所以它似乎神奇地修復了自己。我們甚至嘗試通過從 NetworkServices 切換回 ApplicationPoolIdenity 來進行生產，然後一切又開始工作了……我們不知所措，但沒有更多的字元串可供調查。我們將暫時監控並希望問題不會再次出現……這不是最好的方法，但由於我們無法像之前那樣重現問題，我們不知道還能嘗試什麼。
Next to last Update 我們發現 使用應用程序池標識的 IIS 應用程序中引用的 KB 失去了主令牌？實際上是問題所在。我們
- 已驗證的站點可以執行（它是）
- 使用修補程序中引用的 Nltest.exe 實用程序強制更改機器密碼
- 已驗證該站點已損壞（確實如此）
- 重新啟動
- 驗證該站點再次執行（它是）
我們接下來的步驟是執行類似的步驟，以確認修補程序確實糾正了問題。我們將： 。
- 驗證站點是否正常執行（是）
- 部署修補程序（完成）
- 重啟（完成）
- 驗證站點是否正常執行（它是）
- 使用修補程序中引用的 Nltest.exe 實用程序強制更改電腦密碼（完成）
- 驗證站點是否正常執行（它是！！！！！！！！！）
- 重啟（完成）
- 驗證站點是否正常執行（它是！！！！！！！）
如果所有站點都可以執行，那麼我們將假定該修補程序已完成所需的工作。目前，這似乎適用於使用 Service Pack 1 的 win 2008 機器。
因此，對於遇到問題並希望轉移到 ApplicationPoolIdentity vs NetworkServices 的其他人…如果您在 Service Pack 1 上使用 2008 伺服器…。我建議您參考：使用應用程序池身份的 IIS 應用程序失去主令牌？問題。把這裡的答案歸功於…它幫助了我們！
更新檔已被證明即使在機器帳戶密碼自動循環 30 天后仍然有效。標記問題已關閉。
根本原因：
在 Windows 2008 上 30 天內和之後每30 天從 Web 引用 Active Directory 時，應用程序池標識中的 MSFT 錯誤。（假設預設設置）
臨時解決方法：
- 將應用程序工具設置為使用網路服務與身份。
- 重新啟動網路伺服器，強制應用程序池標識更新在作業系統級別控制的機器 ID/密碼，以便在 AD 控制器之間進行通信。
使固定：
- 在 Win 2008 伺服器上應用Microsoft 知識庫文章 KB2545850更新檔。