IIS7 / Windows 2008 上的多跳 Kerberos 委派
所以在這裡我再次處理可能是關於 IIS、SPN 的第一個支持問題。在這方面，我不是新手，在過去幾年中，我一直忍受著讓 SSRS 前端為 SQL 和 SSAS 後端委派的痛苦。
但微軟現在已經通過重新設計的 IIS7 界面和帶有核心模式的 Windows 2008 加大了賭注，而我又回到那里通宵達旦，頭撞在桌子上。
過去，我成功地使用了 Brian Booth 的 DelegConfig 工具來快速查明問題的根源，但在我目前的情況下，我得到了我不知道我信任的結果，並且我懷疑該工具是否準確地描繪了問題，或者只是在不存在的問題上浪費我的時間。
所以，也許現在是時候獲得第二（以及第三和第四）意見了。
從高層次來看，我有一個 Web 伺服器，它將執行需要充當代理以訪問 SQL 和 SSAS 後端實例的應用程序。表面上聽起來很簡單。
好消息是後端實例已經設置好並且可以工作了。這些是命名實例，在域服務帳戶上執行，並具有適當的 SPN。
前端伺服器如下所示：
作業系統：Windows Server 2008 R2 企業版 IIS：7.5.7600.16385
機器帳號
- Netbios名稱：COLOVWEB
- 伺服器全名：colovweb.co.local
使用主機頭
- IIS站點名稱： CONET
- IISsiteNameFQDN：conet.co.local
應用程序池
- 池名：CONET
- 身份：網路服務
網站
$$ CONET $$託管約 50 個“應用程序”和約 20 個“虛擬目錄”。本練習有一 (1) 個感興趣的應用程序，我們稱之為“MyApplication”。DelegConfig 應用程序現在也存在於這個網站中。 在頂層
$$ CONET $$“匿名身份驗證”和“Windows 身份驗證 {kernelModeAuthentication = true}”已啟用。 在 MyApplication 級別啟用了“Windows 身份驗證 {kernelModeAuthentication = true}”。DelegConfig 也是如此。
我的理解是伺服器域電腦帳戶
$$ CO\COLOVWEB$ $$需要以下內容： 服務主體名稱：
- HTTP/conet.co.local
- HTTP/conet
msDS-AllowedToDelegateTo:
- MSOLAPSvc.3/colosql3.co.local:MyInstance
- MSOLAPSvc.3/colosql3:MyInstance
- MSOLAPDisco.3/colosql3.co.local
- MSOLAPDisco.3/colosql3
- MSSQLSvc/colosql3.co.local
- MSSQLSvc/colosql3
- MSSQLSvc/colosql3.co.local:MyInstance
- MSSQLSvc/colosql3:MyInstance
我的理解是，雖然在這種情況下不需要，但以下內容也是合適的：
服務主體名稱：
- HTTP/colovweb.co.local
- HTTP/colovweb
一切都應該工作，對吧？
好吧，它沒有。根據我用於前端主機名 DelegConfig 抱怨的確切語法：
The domain or workstation membership of NETWORK SERVICE (http://conet$) could not be determined.或者
Service account NETWORK SERVICE (COLOVWEB$) is not a domain account.我知道我正在與 Kerberos 委派作鬥爭，但我不確定 DelegConfig 是幫助還是傷害。對任何一個的答案表示讚賞。
編輯 - 20130403
應用程序 ConnectString 已經過驗證，如下圖所示：
Data Source=colosql3\MyInstance;Catalog=OurCatalog;Integrated Security=SSPI;SSPI=negotiate;Impersonation Level=Delegate;SspropInitAppName=MyApplication到達 OLAP 伺服器的登錄仍然是 CO\COLOVWEB$ 而不是使用者的帳戶。
我在根網路的伺服器上執行 elmah，以便很好地擷取使用者會話：
AUTH_TYPE negotiate AUTH_USER CO\user HTTP_AUTHORIZATION Negotiate YIIKMwYGKwYBBQ....因此，客戶端瀏覽器顯然正在送出適當的請求。
最後，這被證明是應用程序的問題。預設情況下，舊 ASP 應用程序將使用模擬。但是，ASP.NET 預設禁用模擬。在 ASP.NET 數據源中設置模擬是不夠的，開發人員還必須明確啟用模擬。這可以通過 web.config 完成
<identity impersonate="true" />雖然它可以在站點內的多個不同級別進行控制，但對於開發人員來說，評估安全要求並在適當的位置進行更改非常重要。
例如，當在站點級別啟用模擬時，SSAS 連接開始工作……幾乎所有其他東西都壞了，因為大多數其他東西都被編寫為不使用模擬，因此您很容易在安全模型中出現爭用……它並沒有幫助微軟在前一天晚上推出了 IE9，它破壞了一堆顯然被歸咎於這種變化的東西，直到有人弄清楚了。