快...
如何使用Windows身份验证到SQL Server与单SQL客户端 无需在连接字符串中用户名+密码在Windows上运行？
更多...
我们必须使用单声道支持多种平台为我们的应用程序的某些组件
这是我们无法改变的外部限制
我们将运行只能在Windows访问数据库的组件
Mono的SQL客户端的便携/ OS无关的功能，增加价值
也就是说，在非Windows运行的所有组件将不会访问SQL Server数据库
在一些Windows用户运行的过程（真实的用户，服务帐户，等等）
嵌入的用户名和密码是一件坏事
无论你来自哪个角度
那么，怎样才能使单声道SQL客户端读取运行进程的用户的NT登录令牌，通过这个到SQL Server？ 就像MS .NET呢？
是否有不有据可查的标志或设置
难道我们需要实现我们自己的扩展？
如果是这样，我们真的第一个民间要做到这一点？
有5个其他问题（目前）标记的单声道和SQL-服务器：他们不回答这个...
这是不容易做到，因为它的声音。 正如我敢肯定你知道， 单声道的SqlClient有NT验证的支持：
对NT身份验证连接字符串格式：服务器=主机名;数据库=的databaseName;用户ID = windowsDomain \ windowsUserid;密码= windowsPassword;集成安全性= SSPI
不过，当然，你想的比较简单的形式Integrated Security=SSPI ，让NT验证握手使用当前的进程凭据。 而这就是问题。 虽然琐碎查询当前进程的用户名（身份），是不可能的过程来发现它自己的证书密码 。 在做NT验证的Windows进程实际上并没有做认证，而是被要求的LOCA安全管理局 （又名LSASS.EXE，琐事：不调试器附着在它;））来验证这个过程。 这意味着，要达到同样的任何库必须使用相同的协议，即。 问LSA来验证它。 实际细节，好奇，是的序列中AcquireCredentialHandle ， InitializeSecurityContext ， AcceptSecurityContext如描述使用SSPI 。 我没有研究单源的SqlClient，但我敢肯定，他们使用一些GSS-API库，用于验证，而不是 SSPI。 因此，根据定义，他们需要知道，因为他们会做的Kerberos交换自己的密码，不要问LSA做代表他们。
这是，你可以告诉，投机，更多的是猜测的在我身边，但我会很惊讶地听到一个不同的故事。 虽然它肯定是可能的叉子或补丁Mono.Data.Tds和修改身份认证实施方案使用SSPI而不是GSS，这会，顾名思义，是一个不可移植的Windows具体实施。 我猜想有什么激励措施是考虑到单声道的＃1吸引力的一点是， 不是特定于Windows。 我怕你将不得不执行它你自己的。
使用NTLM授权代理服务器 ，并通过代理连接到SQL Server。
