Microsoft SQL Server用户ID是否区分大小写？SSMS登录异常求助

咱们来一步步拆解你的两个问题：

这个答案不是绝对的，核心取决于你的SQL Server实例使用的排序规则（Collation）：

• 如果排序规则是区分大小写的（名称结尾带_CS，比如SQL_Latin1_General_CP1_CS_AS），那用户ID不管是SQL登录名还是映射的Windows用户，都会严格区分大小写——比如John和john会被当成两个完全不同的身份。
• 如果排序规则是不区分大小写的（默认大多是这类，名称结尾带_CI，比如SQL_Latin1_General_CP1_CI_AS），那用户ID就不区分大小写，系统会自动识别为同一个身份。
  额外提一句：Windows本身的用户名默认是不区分大小写的，但SQL Server只会认自己的排序规则，所以映射过来的Windows身份也得跟着SQL Server的规则走。

先来分析原因 #

你遇到的现象本质是SSO传递的身份和手动输入凭据时的身份，在SQL Server端的大小写表现不匹配，结合场景来看，大概率是这几个情况：

1. SQL Server实例是区分大小写的排序规则：你的Windows用户名本身是小写（比如domain\himanshu），但通过RDC登录服务器后，SSO自动传递的身份被系统转成了大写（DOMAIN\HIMANSHU），而SQL Server里对应的数据库用户是小写的——因为排序规则区分大小写，大写身份找不到对应的权限，自然就连接失败了。
2. 本地会话的身份缓存问题：RDC登录后，服务器本地会话里的Windows身份被缓存成了大写格式，SSMS启动时直接继承这个会话身份；而“以其他用户身份运行”时，你手动输入的凭据会以原始小写格式传递给SQL Server，刚好匹配到了正确的数据库用户。
3. AD域的身份映射偏差：少数情况下，AD域里的用户账号在SQL Server的登录映射中，大小写被错误记录，导致SSO传递的大写身份无法匹配到权限。

对应的解决方法 #

• 方法1：修改SQL Server实例排序规则（适合长期解决，需谨慎操作）
  如果业务允许不区分大小写的身份验证，可以把实例排序规则改成不区分大小写的类型（比如SQL_Latin1_General_CP1_CI_AS）。注意：修改实例排序规则需要重建系统数据库，操作前一定要备份所有数据！步骤如下：

  1. 停止SQL Server服务和相关的代理服务。
  2. 打开命令提示符，以单用户模式启动SQL Server：sqlservr.exe -m
  3. 用SQLCMD连接实例，执行命令修改系统库排序规则：

     ALTER DATABASE master COLLATE SQL_Latin1_General_CP1_CI_AS;
     ALTER DATABASE model COLLATE SQL_Latin1_General_CP1_CI_AS;
     ALTER DATABASE msdb COLLATE SQL_Latin1_General_CP1_CI_AS;
     ALTER DATABASE tempdb COLLATE SQL_Latin1_General_CP1_CI_AS;
     

  4. 重启SQL Server服务。

• 方法2：添加对应大小写的登录与用户（无需修改排序规则）
  如果不能改排序规则，那就直接在SQL Server里加一个大写形式的Windows登录，并映射到目标数据库：

  1. 用有登录管理权限的账号打开SSMS，新建登录名，选择Windows身份认证，输入大写的用户名（比如DOMAIN\HIMANSHU）。
  2. 把这个登录名映射到你需要访问的数据库，赋予和小写用户完全相同的权限。这样不管SSO传过来的是大写还是小写身份，都能匹配到对应的权限。

• 方法3：清除本地会话的Kerberos缓存（临时应急）
  在RDC登录的服务器上，打开命令提示符执行：klist purge，清除当前会话的Kerberos票据缓存，然后重启SSMS，看看能不能正确传递小写身份。这个方法适合临时救急，可能每次登录服务器后都需要操作一次。

• 方法4：检查AD域用户属性
  联系公司的AD管理员，确认用户账号的userPrincipalName和sAMAccountName属性的大小写是否正确，确保SQL Server映射的是正确的大小写格式。

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