Rus*_*ell 2 .net c# sql-server connection-string
我有用C#编写的Winforms应用程序,它连接到SQL Server数据库.当我连接到SQL Server时,我建立了一个连接字符串,它可以包含SQL Server登录详细信息或使用Windows身份验证,在这种情况下,我省略了用户名和密码并使用
"Integrated Security=SSPI"
在连接字符串中设置.
现在,用户请求他们可以选择使用Active Directory服务帐户连接到MS SQL Server,而不是网络用户帐户(我假设使用Windows身份验证的连接将通过.
我不熟悉服务帐户或Active Directory,并且想知道是否有人可以指出我正确的方向.有没有办法构建一个连接字符串,允许我的应用程序使用特定的Active Directory服务帐户连接到数据库？
连接字符串与此无关.
用户请求他们可以使用Active Directory服务帐户而不是网络用户帐户连接到MS SQL Server
这意味着用户已请求您的应用程序作为服务帐户运行,而不是当前登录的用户.一种简单的方法是简单地启动以下应用程序runas /netonly:
runas /netonly /user:domain\serviceaccount MyWinFormsApp.exe
这样,您的应用程序在网络上作为域服务帐户运行,它将使用domain\serviceaccount凭据连接到SQL Server .这将满足您的客户的要求,至少在浅表面粗略的外观.
如果使用runas的解决方案不令人满意(客户端可能会合法地抱怨它需要启动applciation的用户知道域\ serviceaccount密码)那么事情会变得复杂一些.正确的方法是将应用程序拆分为两个,一个是在登录用户凭据下运行的UI表示层.exe应用程序,另一个是在域\ serviceaccount凭据下作为服务运行的业务逻辑层组件.这两个组件使用您选择的IPC(通常是WCF)进行通信.您可能已经意识到,这需要对您的应用程序进行重大改写.
有些人可能会建议您在打开与数据库的连接之前使用您的应用程序模拟domain\serviceaccount.我强烈反对,因为serviceaccount密码存储/检索混乱.由于应用程序需要知道serviceaccount密码才能模拟它,登录运行应用程序的用户要么知道密码,要么很容易找到它(如果应用程序没有办法阻止他找到它可以找到它).由于密码的DomainService是访问登录的用户无论如何,他可能只是使用runas /netonly的解决方案.这最终解释了为什么runas解决方案只是一个浅薄的烟雾和镜像解决方案:客户可能已经请求他所要求的唯一原因是他想要将登录用户的权限与应用程序的权限分开(即don不给每个员工提供SQL Servera.由于runas解决方案(以及在应用程序中模拟)要求登录用户知道服务帐户密码,因为登录用户可以随时使用服务帐户密码并提升他的权限,因此不会真正发生权限分离.随意访问SQL Server数据库的权限.因此,唯一值得讨论的解决方案是将应用程序分为两部分.