我在处理SQL Server集群作业问题时碰到过好几个类似的案例，你这个报错的核心是：SQL Server运行作业时，没办法从Active Directory（AD）里获取到作业所有者US\domainaccnt的信息，哪怕你能用这个账户登录服务器、用Windows身份验证连接实例，作业调度的权限验证逻辑和手动登录是不一样的。下面给你一步步排查和解决的方案：

1. 先确认作业所有者的AD账户状态 #

• 首先检查US\domainaccnt这个域账户本身有没有问题：有没有被禁用、密码过期，或者AD里的用户属性出现异常？你可以联系域管理员在域控制器上查看这个账户的状态，确保它是启用状态，密码有效期正常。
• 另外，在任意一个集群节点上试试模拟这个账户登录：打开命令提示符，运行runas /user:US\domainaccnt cmd，如果能正常打开新的命令行窗口，说明账户本身的登录权限没问题；如果失败，直接排查AD账户的问题。

2. 检查SQL Server服务账户的AD查询权限 #

作业运行时，是SQL Server服务账户（不是作业的运行账户）去AD查询作业所有者的信息，所以这个服务账户必须有读取AD用户/组信息的权限：

• 打开SQL Server配置管理器，找到你的SQL Server服务对应的运行账户。如果是域账户，确认它没有被加入限制AD读取权限的组；如果是本地账户，那大概率会出问题（本地账户没法跨域查询AD信息），建议改成有AD读取权限的域账户。
• 测试一下：用SQL Server服务账户登录到集群节点，打开PowerShell运行Get-ADUser domainaccnt -Server <你的域控制器FQDN>，如果能正常返回用户信息，说明权限没问题；如果报错，联系域管理员给这个服务账户添加AD用户读取权限。

3. 重新同步作业所有者与SQL Server的权限映射 #

有时候SQL Server缓存的AD信息过期，或者账户的权限映射出现异常：

• 先做个测试：把作业的临时所有者改成你确定有权限的账户（比如本地管理员，或者sa账户——注意sa只是临时测试，不要长期用），然后手动运行作业。如果作业能成功，说明原来的所有者账户的权限映射有问题。
• 改回原来的US\domainaccnt：在SSMS里找到这个作业，右键→属性→所有者，重新选择一次US\domainaccnt（确保选择时能正常找到这个账户），然后保存。
• 同时在SQL Server实例里执行下面的命令，同步Windows账户和SQL Server的登录映射：

  EXEC sp_change_users_login 'Update_One', 'US\domainaccnt', 'US\domainaccnt'
  

4. 验证集群所有节点的AD连接状态 #

因为是3节点集群，要确保每个节点都能正常连接域控制器，解析AD信息：

• 在每个节点上运行nltest /dsgetdc:你的域名，看看能不能正常返回域控制器的信息，这能验证节点和DC的网络连接正常。
• 检查防火墙：确保集群节点和域控制器之间没有拦截AD相关的端口（比如LDAP的389端口、Kerberos的88端口）。
• 清空每个节点的DNS缓存：运行ipconfig /flushdns，然后重启SQL Server代理服务，再测试作业。

5. 检查SQL Server代理服务的权限配置 #

SQL Server代理服务的运行账户需要有足够的权限来管理作业和验证所有者：

• 确认代理服务的账户属于**SQLServerSQLAgentUser$<节点名>$<实例名>**本地组，同时在SQL Server实例里拥有SQLAgentOperatorRole或者更高的代理角色权限。
• 如果代理服务用的是本地系统账户，建议改成域账户，因为本地系统账户在跨域查询AD时会有很多限制。

按照上面的步骤排查，基本能解决这个问题——我之前处理的几个集群案例，大多是服务账户的AD权限不足或者节点AD连接异常导致的。

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