快的...
如何在连接字符串中没有用户名+密码的情况下使用在 Windows 上运行的Mono SQL 客户端对 SQL Server 进行 Windows 身份验证？
更多的...
我们必须使用 Mono 来支持我们应用程序的某些组件的多个平台
这是我们无法更改的外部限制
我们将仅在 Windows 上运行访问数据库的组件
Mono SQL 客户端的可移植性/与操作系统无关的特性没有任何价值
也就是说，在非 Windows 上运行的任何组件都不会访问 SQL Server 数据库
该进程在某些 Windows 用户（真实用户、服务帐户等）下运行
嵌入用户名和密码是一件坏事
无论您来自哪个角度
那么，我们如何让 Mono SQL 客户端读取运行该进程的用户的 NT 登录令牌并将其传递给 SQL Server？就像 MS .net 一样？
是否存在未充分记录的标志或设置
我们需要实现我们自己的扩展吗？
如果是这样，我们真的是第一个想要这样做的人吗？
还有 5 个其他问题（当前）标记为 Mono 和 SQL-Server：他们没有回答这个问题......
这并不像听起来那么容易实现。我相信你知道，Mono SqlClient支持 NT 身份验证：
具有 NT 身份验证的连接字符串格式：Server=hostname;Database=databaseName;User ID=windowsDomain\windowsUserid;Password=windowsPassword;Integrated Security=SSPI
但是，当然，您想要更简单的形式Integrated Security=SSPI并让 NT 身份验证握手使用当前进程凭据。这就是问题所在。虽然检索当前进程用户名（身份）很简单，但进程不可能发现它自己的凭据密码。在进行 NT 身份验证时，Windows 进程实际上并不进行身份验证，而是要求Locas 安全机构（又名 LSASS.EXE，琐事：不要将调试器附加到它；））来验证此进程。这意味着任何想要实现相同功能的库都必须使用相同的协议，即。要求 LSA 对其进行身份验证。对于好奇的人来说，实际的细节是按 , 的顺序排列的，AcquireCredentialHandle如使用SSPI中所述InitializeSecurityContextAcceptSecurityContext. 我没有研究 SqlClient 的单声道源，但我很确定他们使用一些GSS-API库进行身份验证，而不是SSPI。因此，根据定义，他们需要知道密码，因为他们将自己进行 Kerberos 交换，而不是要求 LSA 代表他们进行。
正如你所知道的，这是我的猜测和更多的猜测，但如果听到不同的故事，我会感到惊讶。虽然分叉或修补 Mono.Data.Tds 并修改身份验证实现以使用 SSPI 而不是 GSS 当然是可能的，但根据定义，这将是一个不可移植的 Windows 特定实现。考虑到 Mono 的第一个吸引点不是特定于 Windows的，我猜想它没有什么动力。恐怕您将不得不自己实施它。
使用NTLM 授权代理服务器并通过代理连接到 SQL Server。