PowerShell执行Get-ADPrincipalGroupMembership时身份验证错误求助

这种跨域AD操作的身份验证问题确实挺棘手的，结合你描述的场景——只有这一个命令报错、其他AD命令正常、临时指定服务器能解决但影响跨域访问，我给你几个针对性的解决方案：

1. 动态指定目标域的服务器参数 #

因为你需要同时访问Domain A和Domain B，硬编码单一服务器肯定会顾此失彼。可以写个简单的逻辑，根据目标用户所在的域动态选择对应域的PDC模拟器（PDC是域内身份验证的权威节点，稳定性更高）：

function Get-CrossDomainGroupMembership {
    param(
        [Parameter(Mandatory=$true)]
        [string]$UserIdentity
    )

    # 获取目标用户所属的域
    $userObj = Get-ADUser -Identity $UserIdentity
    $targetDomain = $userObj.Domain

    # 动态获取对应域的PDC模拟器
    $domainPDC = (Get-ADDomain -Identity $targetDomain).PDCEmulator

    # 执行组查询时指定目标域的PDC
    Get-ADPrincipalGroupMembership -Identity $UserIdentity -Server $domainPDC
}

调用的时候直接用Get-CrossDomainGroupMembership -UserIdentity "目标用户名"就行，这样既保证了身份验证的有效性，又不会影响跨域搜索。

2. 重置AD模块的身份验证上下文 #

你提到设置$PSDefaultParameterValues后生效一阵又复现，大概率是PowerShell的AD模块缓存了过期的凭据上下文。可以尝试强制重置：

# 清除AD模块的临时缓存变量
Remove-Variable -Name "ADPSDrive" -ErrorAction SilentlyContinue

# 强制重新导入AD模块，刷新凭据上下文
Import-Module ActiveDirectory -Force

# 如果使用服务账号，也可以重新加载凭据
# $adCred = Get-Credential -Message "输入AD访问凭据"
# Connect-ADServiceAccount -Credential $adCred -Identity "你的服务账号名"

这个方法能快速解决缓存导致的临时身份验证失效问题，适合脚本运行一段时间后突然报错的场景。

3. 开启Kerberos日志排查根源 #

如果上面的方法都没解决，建议开启Kerberos详细日志，精准定位问题：

1. 打开组策略编辑器（gpedit.msc），导航到计算机配置>管理模板>系统>Kerberos
2. 启用「Kerberos事件日志记录」，设置日志级别为「详细」
3. 重启机器后，打开事件查看器，查看系统>事件源>Kerberos下的错误事件（比如ID 4768、4769）

通过日志你能看到是Kerberos票据生成失败、跨域信任问题，还是服务器端的身份验证配置异常——毕竟只有这一个命令报错，大概率是这个命令的Kerberos票据流程有特殊问题。

4. 检查跨域信任的SID筛选设置 #

跨域信任的SID筛选有时候会干扰跨域组查询，尤其是你的账号在两个域都有身份的情况：

# 检查Domain A到Domain B的信任配置
Get-ADTrust -Identity DomainB.com -Server DomainA.com | Select-Object Name, SIDFilteringQuarantined

# 如果SIDFilteringQuarantined为True，可临时禁用测试（生产环境需谨慎操作）
# Set-ADTrust -Identity DomainB.com -Server DomainA.com -SIDFilteringQuarantined $false

临时禁用后如果问题解决，说明SID筛选限制了跨域组查询的身份验证，这时可以根据实际需求调整信任配置，或者优化账号的跨域权限设置。

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