使用活动目录服务帐户从.net连接到SQL Server

"Integrated Security=SSPI" 

连接字符串与此无关

用户请求他们有连接到MS SQL Server的选项使用活动目录服务帐户而不是网络用户账户

这意味着用户已经请求您的应用程序作为服务帐户运行，而不是作为当前登录的用户。一种简单的方法是在runas /netonly下启动应用程序:

runas /netonly /user:domain'serviceaccount MyWinFormsApp.exe

这样，您的应用程序作为网络上的域服务帐户运行，它将使用domain'serviceaccount凭据连接到SQL Server。这将满足您的客户的要求，至少在表面上粗略地看一下。

如果使用runas的解决方案不令人满意(客户端可能会合理地抱怨它要求启动应用程序的用户知道域服务帐户密码)，那么事情就会变得有点复杂。正确的方法是将应用程序分成两个，一个是在登录用户凭据下运行的UI表示层.exe应用程序，另一个是在域'serviceaccount凭据下作为服务运行的业务逻辑层组件。这两个组件使用您选择的IPC(通常是WCF)进行通信。您可能已经意识到，这需要对应用程序进行s major重写。

有些人可能建议在打开数据库连接之前让应用程序模拟域'serviceaccount。由于服务帐户密码存储/检索混乱，我强烈反对这样做。由于应用程序需要知道服务帐户密码才能模拟它，因此登录运行应用程序的用户要么知道该密码，要么很容易找到它(如果应用程序可以找到它，没有办法阻止他找到它)。因为domainservice密码是可以访问登录用户无论如何，他可能只是使用runas /netonly解决方案。这最终解释了为什么runas解决方案只是一个肤浅的烟雾和镜子解决方案:您的客户端可能已经请求了他所请求的内容的唯一原因是他希望将登录用户的特权与应用程序的特权分开(即。不要让SQL Servera访问每个员工)。由于runas解决方案(以及应用程序中的模拟)要求登录用户知道服务帐户密码，因此特权分离并没有真正发生，因为登录用户可以随时使用服务帐户密码并提升其特权以随意访问SQL Server数据库。因此，唯一值得讨论的解决方案是将应用程序分成两个部分。

连接字符串"Integrated Security=SSPI"将把当前用户凭据传递给SQL Server。但是，如果用户希望在不更改连接字符串的情况下使用其他Active Directory用户，则使用操作系统提供的Run As功能。如果您使用的是windows 7，请按Shift并右键单击exe并选择以不同用户运行。

这只是一个hack而不是一个合适的解决方案。

一般来说，活动目录帐户与网络用户帐户相同。也有例外，例如工作组和非ad网络，但对于大多数情况，它们将是相同的。

如果您的用户在非ad网络上，那么您的用户要求的是相当复杂的东西(不同网络类型之间的跨域信任)。

但是，如果您的用户运行在AD网络中，但希望以与其交互用户不同的用户身份登录(例如，他们以MJames的身份登录到自己的机器，但希望以FJones的身份登录到数据库)，那么您有两种选择:

1)告诉他们需要以被请求的用户身份登录到他们的机器。

2)提示用户输入登录凭据，并执行AD登录来验证他们的凭据，然后使用。net框架模拟登录的用户。这个MSDN链接，虽然对于ASP。Net中有您需要的基本信息，特别是关于Impersonating by Using LogonUser的部分。

在上述任何情况下，您的Integrated Security=SSPI命令字符串参数将作为您的用户当前登录的AD用户连接到SQL Server，直接连接到计算机或通过模拟。

"Integrated Security=SSPI"将传递当前登录用户的凭据。服务帐户只是另一个用户，尽管实际上必须在连接字符串中指定。我假设在默认情况下，您只希望通过使用"Integrated Security=SSPI"传递登录用户，但提供指定登录凭据的选项，在这种情况下，您将使用指定用户名和密码的连接字符串。

这是我尝试的连接字符串，它为我工作。是-需要Integrated Security=SSPI。

"Data Source=myServerName'myInstanceName;Initial Catalog=myInitialDB;App=myApplication;Integrated Security=SSPI;"

您可以通过将应用程序池的标识设置为该特定用户来连接到数据库。当然，该用户应该具有执行该池的所有必要访问权限。