执行Get-ADUser跨林查询时遇SSPI调用失败错误求助

这个SSPI错误在跨林AD查询场景里挺常见的，结合你提到其他信任林查询都正常的情况，大概率是g.org林的身份验证或连接配置出了问题，给你列几个最可能的排查方向：

1. 身份验证协议不兼容 #

SSPI错误大多和Kerberos认证失败有关——可能你的客户端与g.org域控制器的Kerberos加密类型不兼容，导致认证握手失败。

解决方法： #

• 强制使用NTLM协商认证，修改命令如下：

  Get-ADUser -Filter '*' -SearchScope 2 -Server g.org -Properties DistinguishedName,DisplayName,GivenName,ObjectClass,SamAccountName -Authentication Negotiate
  

• 检查你的客户端机器支持的Kerberos加密类型，确保和g.org域控制器的配置兼容（比如g.org是否禁用了RC4，而你的客户端仅支持RC4）。

2. 林信任的权限或SID过滤问题 #

虽然是双向可传递信任，但可能存在以下权限问题：

• 当前登录用户在g.org林中没有读取用户对象的权限；
• g.org林的信任设置启用了SID过滤，导致你的用户SID被拦截。

解决方法： #

• 联系g.org的AD管理员，确认你的用户账号在该林中拥有读取所有用户对象的权限；
• 检查g.org林的信任属性，确认SID过滤是否为默认启用状态（一般默认启用不会影响正常查询，但如果有自定义修改可能导致问题）。

3. DNS解析或域控制器连接问题 #

你指定了-Server g.org，但如果你的机器无法正确解析g.org的域控制器，或者解析到的DC处于不可用状态，也会触发SSPI错误。

解决方法： #

• 先测试DNS解析：

  nslookup g.org
  

  查看返回的域控制器FQDN是否正确，尝试ping这些DC确认网络连通性；
• 直接指定g.org的某个可用域控制器FQDN执行命令，避免自动解析问题：

  Get-ADUser -Filter '*' -SearchScope 2 -Server dc01.g.org -Properties DistinguishedName,DisplayName,GivenName,ObjectClass,SamAccountName
  

4. PowerShell会话的身份上下文问题 #

你的当前PowerShell会话可能绑定在本地林的身份上，跨林查询时没有正确切换到g.org的身份上下文。

解决方法： #

• 使用g.org域的用户身份启动新的PowerShell会话：

  Start-Process powershell.exe -Credential g.org\your-username
  

  在新窗口中执行查询命令；
• 或者在命令中直接指定g.org的凭据：

  $cred = Get-Credential g.org\your-username
  Get-ADUser -Filter '*' -SearchScope 2 -Server g.org -Credential $cred -Properties DistinguishedName,DisplayName,GivenName,ObjectClass,SamAccountName
  

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