当 SQL Server 作为域帐户而不是 SYSTEM 或 NETWORK SERVICE 运行时，SQL CLR 函数无法模拟答案

【问题标题】：SQL CLR function fails to impersonate when SQL Server is running as a domain account instead of SYSTEM or NETWORK SERVICE当 SQL Server 作为域帐户而不是 SYSTEM 或 NETWORK SERVICE 运行时，SQL CLR 函数无法模拟
【发布时间】：2011-06-11 13:56:23
【问题描述】：

我有以下代码在测试盒上完美运行，它以 SYSTEM 身份运行 MSSQLSERVER 服务：

      currentIdentity = SqlContext.WindowsIdentity;
      impersonatedIdentity = currentIdentity.Impersonate();

       client.PreAuthenticate = true;
       client.Credentials = CredentialCache.DefaultNetworkCredentials;
       client.Url = currentURL;

   /* Encrypt */
   try
   {
      encryptedText = client.Encrypt(plainText);
   }
   finally
    {
        if (impersonatedIdentity != null)
        {
            impersonatedIdentity.Undo();
        }
    }

        return encryptedText;

此功能的基本思想是通过内部托管的 Web 服务加密/解密文本。每当在以“SYSTEM”或其他本地帐户运行 MSSQLSERVER 服务的服务器上调用此函数时，模拟就可以正常工作。如果服务器将 MSSQLSERVER 服务作为域帐户（即 DOMAIN\sqlaccount）运行，则“DOMAIN\sqlaccount”的凭据始终会传递给 Web 服务，并且模拟似乎不起作用。

这是预期的行为吗？提前致谢。

【问题讨论】：

澄清一下，这适用于数据库服务器和IIS服务器是同一台机器的测试环境。从 MSSQLSERVER 服务作为本地帐户运行的另一台服务器到另一台 IIS 计算机进行测试会产生相同的结果。

标签： .net sql-server impersonation sqlclr

【解决方案1】：

对于您运行 SQL Server 的服务帐户，该帐户是否启用了模拟？在活动目录中的用户的属性窗口中有一个称为委托的选项卡。您可以选择不允许委派、允许不分青红皂白地委派或配置该帐户有权委派的服务。默认值为“不信任”，这可能是您的问题。看一看，看看你发现了什么。

【讨论】：

谢谢，本。我认为这是我们的问题，因为我们似乎遇到了 IIS 的双跳问题。

【解决方案2】：

将您的加密函数调用移出 SQLCLR。从 SQL 进行 Web 服务调用是一个非常非常非常糟糕的主意。 SQL Server 资源太宝贵了，不能将它们浪费在等待 HTTP 响应上，甚至是内部 Intranet 响应上。除了目光短浅的冷静因素之外，我从未遇到过为什么要从 SQLCLR 内部进行 Web 服务调用的合理解释。从应用程序调用 Web 服务，是等待 HTTP 响应的正确位置。

【讨论】：

我完全同意 -- 特别是因为 SQL Server 提供了本机加密 -- 应该没有理由离开服务器。

【解决方案3】：

您使用什么协议进行身份验证？

如果您使用的是 Kerberos，我会预料到这种行为。在 Kerberos 中，系统和网络服务器 SPN 是自动定义的。但是，如果您想使用自定义服务名称，则需要定义一个 SPN（为该服务名称）才能使身份验证工作。

【讨论】：

我可以看到为运行 MSSQLSERVER 的域帐户注册了以下 SPN：“MSSQLSvc/servername.host.net:1433” IIS 端应该也有一个吗？跨度>
抱歉，我们实际上是在使用 NTLM。
Web 服务是否设置为启用 NTLM？您需要在配置文件中设置 impersonation = true。
是的，在 IIS 中为“集成 Windows 身份验证”设置了 Web 服务。至于在那里启用模拟，似乎更多的问题是当前用户在 SQL 中的凭据没有传递给 IIS。