当SQL Server以域帐户而不是SYSTEM或NETWORK SERVICE的身份运行时,SQL CLR功能无法模拟

| 我在一个测试箱上完美运行了以下代码,该测试箱将MSSQLSERVER服务作为SYSTEM运行:
      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服务加密/解密文本。每当在运行MSSQLSERVER服务的服务器上以\'SYSTEM \'或其他一些本地帐户调用此函数时,模拟都可以正常工作。如果服务器将MSSQLSERVER服务作为域帐户(即DOMAIN \\ sqlaccount)运行,则\'DOMAIN \\ sqlaccount \'的凭据将始终传递到Web服务,并且模拟似乎无法正常工作。 这是预期的行为吗?提前致谢。     
已邀请:
        对于运行SQL Server的服务帐户,该帐户是否启用了模拟功能?在活动目录中,用户的属性窗口中有一个选项卡称为“委派”。您可以选择不允许委派,不加选择地委派或配置该帐户有权委派给哪些服务。默认值为“不信任”,这可能是您遇到的问题。看看吧,看看您发现了什么。     
        将您的加密函数调用移出SQLCLR。从SQL进行Web服务调用是一个非常非常非常糟糕的主意。 SQL Server资源非常宝贵,无法浪费它们等待HTTP响应,甚至是内部Intranet。我从来没有遇到过一个合理的解释,为什么除了短暂的冷静因素之外,还是要从SQLCLR内部进行Web服务调用。从应用程序调用Web服务,是等待HTTP响应的适当位置。     
        您使用哪种协议进行身份验证? 如果您使用的是Kerberos,则可能会出现这种情况。在Kerberos中,系统和网络服务器SPN是自动定义的。但是,如果要使用自定义服务名称,则需要定义一个SPN(用于该服务名称)以使身份验证起作用。     

要回复问题请先登录注册