Linux服务器下使用ODBC Driver 17 for SQL Server通过Active Directory用户名密码登录SQL Server的实现方法

当然能在Linux服务器上通过「ODBC Driver 17 for SQL Server」，用Active Directory的用户名密码登录SQL Server（无需Trusted_Connection=Yes）。我们来逐个拆解你遇到的问题：

问题1：未指定认证方式导致的登录失败 #

你的第一个连接字符串没有明确告诉驱动用什么方式认证——ODBC Driver 17默认会使用SQL Server身份验证，而你传入的是AD域账号，自然会出现登录失败。必须添加Authentication=ActiveDirectoryPassword参数，这是用AD账号密码登录的核心配置。

问题2：自签名SSL证书验证失败 #

第二个连接字符串的错误，是因为你的SQL Server使用了自签名证书，而Linux环境下的ODBC驱动默认会严格验证SSL证书的合法性。你有两种解决思路：

方案1：临时跳过证书验证（适合测试环境） #

在连接字符串中追加TrustServerCertificate=Yes参数，强制驱动信任服务器的证书：

Driver=ODBC Driver 17 for SQL Server;MultiSubnetFailover=Yes;UID=你的AD账号@域名.com;PWD=你的AD密码;Server=SQL服务器地址;Database=目标库名;Authentication=ActiveDirectoryPassword;TrustServerCertificate=Yes

⚠️ 注意：这个方法会绕过SSL证书校验，生产环境不建议使用，存在安全风险。

方案2：信任自签名证书（适合生产/高安全要求环境） #

把SQL Server的自签名证书导入Linux系统的信任存储，让驱动认可它的合法性：

1. 从SQL Server服务器导出证书（通常路径是C:\Program Files\Microsoft SQL Server\MSSQLXX.MSSQLSERVER\MSSQL\DATA，文件后缀为.cer）
2. 将证书上传到Linux服务器，比如放到/usr/local/share/ca-certificates/目录下
3. 运行命令更新系统信任存储：

sudo update-ca-certificates

完成后再使用带Authentication=ActiveDirectoryPassword的连接字符串，就不会再出现证书验证错误了。

额外注意事项 #

• AD账号格式：优先使用UPN格式（比如user@yourdomain.com），部分环境下DOMAIN\user格式可能需要额外配置才能被正确识别
• 网络连通性：确保Linux服务器能访问AD域控制器（LDAP/LDAPS端口389/636需开放），且能正确解析SQL Server和AD的域名
• 驱动版本：建议安装最新版的ODBC Driver 17 for SQL Server，旧版本可能存在AD认证的兼容性bug

内容的提问来源于stack exchange，提问作者Sat