![IIS7 / Windows 2008 上的多跳 Kerberos 委派](https://linux22.com/image/608779/IIS7%20%2F%20Windows%202008%20%E4%B8%8A%E7%9A%84%E5%A4%9A%E8%B7%B3%20Kerberos%20%E5%A7%94%E6%B4%BE.png)
因此,我又要处理 IIS 上可能排名第一的支持问题,即 SPN。在这方面,我并不是新手,过去几年来,我经历了在多个不同环境中让 SSRS 前端委派 SQL 和 SSAS 后端的痛苦。
但是微软现在已经提高了赌注,推出了重新设计的 IIS7 界面和带有内核模式的 Windows 2008,而我又得回到办公室熬夜、用头敲打桌子。
过去我曾成功地使用 Brian Booth 的 DelegConfig 工具来快速查明问题的根源,但就我目前的情况而言,我得到的结果并不可信,而且我怀疑该工具是否准确地描述了问题,或者只是在浪费我的时间处理不存在的问题。
因此,也许现在是时候听取第二个(以及第三个和第四个)意见了。
从高层次来看,我有一个 Web 服务器,它将运行需要充当代理以访问 SQL 和 SSAS 后端实例的应用程序。表面上听起来很简单。
好消息是后端实例已经设置完毕并开始运行。这些是命名实例,在域服务帐户上运行,并且已设置了相应的 SPN。
前端服务器如下所示:
操作系统:Windows Server 2008 R2 Enterprise IIS:7.5.7600.16385
机器帐户
- Netbios 名称: COLOVWEB
- 服务器FQDN:colovweb.co.local
使用主机标头
- IISSiteName: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.本地
- HTTP/网络
msDS-允许委托:
- MSOLAPSvc.3/colosql3.co.local:MyInstance
- MSOLAPSvc.3/colosql3:我的实例
- MSOLAPDisco.3/colosql3.co.local
- MSOLAPDisco.3/colosql3
- MSSQLSvc/colosql3.co.local
- MSSQLSvc/colosql3
- MSSQLSvc/colosql3.co.local:MyInstance
- MSSQLSvc/colosql3:我的实例
我的理解是,虽然在这种情况下不需要,但以下内容也是适当的:
服务主体名称:
- HTTP/colovweb.co.本地
- 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$,而不是用户的帐户。
我在根 Web 中的服务器上运行 elmah,因此可以很好地捕获用户会话:
AUTH_TYPE negotiate
AUTH_USER CO\user
HTTP_AUTHORIZATION Negotiate YIIKMwYGKwYBBQ....
因此,客户端浏览器显然提交了适当的请求。
答案1
最后,这被证明是应用程序的问题。旧版 ASP 应用程序默认使用模拟。但是,ASP.NET 默认禁用模拟。在 ASP.NET 数据源中设置模拟是不够的,开发人员还必须明确启用模拟。这可以通过 web.config 来完成
<identity impersonate="true" />
尽管它可以在站点内的多个不同级别进行控制,但对于开发人员来说,评估安全要求并在适当的地方进行更改非常重要。
例如,当在站点级别启用模拟时,SSAS 连接开始工作……而几乎所有其他东西都中断了,因为大多数其他东西都被编写为不使用模拟,因此您很容易在安全模型中产生争用……而且它并没有帮助微软在前一天晚上推出的 IE9,它破坏了一堆东西,显然这一切都是这个变化造成的,直到有人弄明白了。