我正在尝试设置以下scheme。 我有3个服务器,他们都在同一个域。
服务器B和C在SQL群集中。 B和C的实例是链接的服务器。
当我从A运行SQL Server Management Studio并使用我的域帐户(dom \ usr)连接到B时,我尝试执行从B和C中select数据的查询,并且它工作正常。
当我尝试相同的Web应用程序,我得到的错误:
用户'NT AUTHORITY \ ANONYMOUS LOGON'login失败。
我看到SQL中的连接具有用户dom \ web的auth_scheme KERBEROS,所以它不是NTLM。
此外,dom \ web域帐户在AD中没有select“帐户敏感且无法委托”选项。
我也认为SPN是正确设置的,因为双跳在第一种情况下不起作用。
这是服务器C上的错误:
源login
用户'NT AUTHORITY \ ANONYMOUS LOGON'login失败。 原因:基于令牌的服务器访问validation失败,出现基础结构错误。 检查以前的错误。 [客户:10.65.10.53]
源login
消息错误:18456,严重性:14,状态:11。
我相信IIS的网站设置为“匿名”与IUSR帐户。 这是作为匿名login通过域。
如果你打开IISpipe理器,在左边有一棵树。 在此树中,展开服务器,然后展开“网站”,然后单击您正在用于此项目的网站(即默认网站)。 在IISpipe理器的右侧,双击“身份validation”图标。 在下一个屏幕上,右键单击“匿名身份validation”,然后从上下文菜单中select“编辑”。 确保select“特定用户”并点击“设置”button。 将用户更改为dom \ web并input正确的密码。 点击OK。
此时,您可能会遇到dom \ web无法访问SQL Server的问题。 您将不得不为dom \ web创build一个SQLlogin名,然后在数据库中创build一个您想让dom \ web访问的用户。
要添加到其他人 – 我一直处于运行查询从SSMS而不是从IIS通过应用程序前端工作的情况。
我主要用这两个环节来解决问题。 Active Directory,configuration文件,IIS和操作系统有很多不同的设置需要考虑,它可能是您不太期望的。 关键是要知道操作系统/ IIS / SQL Server认为正在发生什么,请参阅下面的DELEGCONFIG链接。
所以正确设置SQL Server的Kerberos圣经的链接 – http://msdn.microsoft.com/en-us/library/ff679930(v=SQL.100).aspx 。 我知道它特定于Reporting Services,但仍然适用于应用程序服务器,因为您可以将Reporting Services视为另一个应用程序。
我发现解决身份validation问题的最佳方法是使用名为DELEGCONFIG的工具; 它可以帮助您设置正确的SPN的Kerberos工作。 你可以在这里find这个工具: http : //www.iis.net/community/default.aspx ?tabid=34& g=6&i=1434 。 这是一个你在服务器上安装的IIS网站,它告诉你是否你的SPN和委派安装正确。 它也可以为你做出改变。 我运行它,直到所有的检查都是绿色的 – 你会明白,如果你运行该工具。
我不会把DELEGCONFIG网站放在生产环境中,但是在设置或让生产pipe理员设置db / app服务器时,他们可以使用它来计算出结果。 一旦你做对了,然后删除该网站或隐藏并保护它。
HTH
在服务器B和C上为dom \ web创build一个login名,并将对数据库的访问权授予新创build的login名。
只要放下我的假设:
所以,既然你提到SPN,我假设你已经使用类似这样的方式注册了一个:
setspn -S http/webapp.fqdn.tld dom\web
你有没有去用户帐户dom \ web上启用委派? 为了双倍工作,运行Web应用程序的用户帐户需要被允许再次传递这些凭据。 在域中的用户帐户属性中,find“委派”选项卡并启用“对任何服务(Kerberos)信任委托”。
如果没有问题,请确保您的IIS网站设置为通过Windows身份validation,而不是使用NT USER \ Anonymous帐户。
此时,您可以通过从命令行运行klist来检查Kerberos和IIS是否全部configuration正确。 这将输出当前login用户的所有Kerberos票证问题。 找一个具有Server: http/webapp.fqdn.tld并检查是否设置了forwardable和ok_as_delegate 。
接下来(如上面所build议的那样),将可能使用该应用程序的一组用户添加到SQL,并根据需要授予他们对数据库的权限。
…近一点。 我想我现在可以给我一些build议。 希望有些东西可以帮助你,明天我会在工作中增加更多。 (我在新西兰,因此这个怪异的探空时区)。
我记得在过去有一个类似的问题,有些同事通过在服务启动时将SQL服务帐户作为域pipe理员组成员解决,然后在删除之后解决了这个问题。 这是SPN的一些问题。
这可能不是解决这个问题的正确方法,但是它让所有事情都处于非计划停机的关键时期。