授权内网测试中 WinRM 可达却无法远程执行，如何定位权限边界与日志证据？

背景与提问在一次已授权的 Windows 域内网测试中，测试机到目标服务器 TCP 5985 可达，域账号也能正常登录业务系统，但使用 PowerShell Remoting 建立会话时返回 Access is denied。换用本地管理员账号后仍然失败。此类问题不应直接归因于“凭据错误”，通常要把网络路径、WinRM 配置、会话端点 ACL、UAC 远程令牌过滤、域策略以及日志证据分层检查。场景边界：以下操作用于已取得书面授权的测试环境。目标是验证远程管理权限是否符合设计，并形成可复核的证据，不涉及绕过认证或扩大授权范围。问题定位思路建议先判断失败发生在哪一层。TCP 不通属于网络或防火墙问题；WSMan 探测失败多为服务、监听器或协议配置问题；探测成功但创建会话被拒绝，重点检查账号授权、端点安全描述符和令牌过滤；会话建立后命令受限，则检查 JEA、AppLocker、WDAC 或 PowerShell 语言模式。现象优先检查关键证据5985/5986 不通路由、主机防火墙、网络配置文件防火墙日志、Test-NetConnectionWSMan 探测失败WinRM 服务、监听器、HTTP/HTTPS 配置WinRM Operational 日志创建会话时拒绝访问组成员关系、端点 ACL、UAC 令牌过滤4625、WinRM 记录、端点权限能登录但命令受限JEA、执行策略、AppLocker、WDACPowerShell 4103/4104、AppLocker 日志操作步骤一：确认网络与服务面先在测试机确认名称解析和端口，再在目标机检查 WinRM 服务、监听器以及防火墙规则。不要仅凭 ping 判断，因为 ICMP 被禁用并不代表 WinRM 不可达。# 测试机：确认解析、端口和 WSMan 响应
Resolve-DnsName srv-app-01
Test-NetConnection srv-app-01 -Port 5985
Test-WSMan srv-app-01

# 目标机：以本地交互管理员身份检查
Get-Service WinRM
winrm enumerate winrm/config/listener
Get-NetConnectionProfile
Get-NetFirewallRule -DisplayGroup 'Windows Remote Management' |
Select-Object DisplayName, Enabled, Profile, Direction, Action如果目标网络配置文件被误识别为 Public，而规则只允许 Domain，端口测试可能直接失败。应修正网络识别或将防火墙规则限定到实际管理网段，不建议为了验证而全局关闭防火墙。操作步骤二：确认账号身份与授权边界WinRM 默认并不等价于“任何有效域账号都能远程执行”。通常需要账号位于 Administrators 或 Remote Management Users，并且会话端点的安全描述符允许访问。还应核对账号实际 SID 与组令牌，避免同名本地账号、域账号混淆。# 目标机：核对本地组成员
Get-LocalGroupMember -Group 'Administrators'
Get-LocalGroupMember -Group 'Remote Management Users'

# 当前上下文：核对身份和组令牌
whoami /user
whoami /groups

# 检查 PowerShell 会话端点
Get-PSSessionConfiguration |
Select-Object Name, Permission, Enabled, PSVersion

# 使用明确的域身份测试，避免名称歧义
$cred = Get-Credential 'CONTOSO\\audit.user'
New-PSSession -ComputerName 'srv-app-01.contoso.local' -Credential $cred若 Remote Management Users 被授予连接权限，但端点 Permission 中没有对应主体，应检查端点是否被自定义或被 GPO 重写。不要直接使用 Set-PSSessionConfiguration 放宽为 Everyone；更稳妥的方式是建立专用域组，并只授予所需端点权限。操作步骤三：区分域账号与本地账号的 UAC 远程限制本地管理员账号通过网络登录时，可能受到 UAC 远程令牌过滤，获得的是过滤后的令牌。这会出现“账号属于 Administrators，但远程管理仍拒绝访问”的现象。检查以下注册表项只能作为诊断，不应把开启该项作为默认修复方案。# 只读检查，不修改
$path = 'HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System'
Get-ItemProperty -Path $path -Name LocalAccountTokenFilterPolicy -ErrorAction SilentlyContinue

# 同时检查相关策略结果
Get-GPResultantSetOfPolicy -ReportType Html -Path C:\\Windows\\Temp\\gpresult.htmlLocalAccountTokenFilterPolicy 不存在或为 0 时，本地管理员远程令牌通常会被过滤；设为 1 会扩大本地管理员通过网络获得完整令牌的范围，增加横向移动风险。生产环境更建议使用受控域管理账号、Windows LAPS 管理的唯一密码、JEA 端点或集中运维平台，而不是放宽此策略。操作步骤四：从日志还原失败点客户端报错信息往往不够精确，至少应关联安全日志、WinRM 日志和 PowerShell 日志。记录测试时间、源 IP、目标主机、账号和命令，便于按时间窗口筛选。# 安全日志：最近 30 分钟内的成功、失败登录与特权分配
$start = (Get-Date).AddMinutes(-30)
Get-WinEvent -FilterHashtable @{
LogName='Security'
Id=4624,4625,4672
StartTime=$start
} | Select-Object TimeCreated, Id, MachineName, Message

# WinRM 操作日志
Get-WinEvent -FilterHashtable @{
LogName='Microsoft-Windows-WinRM/Operational'
StartTime=$start
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

# PowerShell 操作日志，确认会话建立后是否执行过脚本块
Get-WinEvent -FilterHashtable @{
LogName='Microsoft-Windows-PowerShell/Operational'
Id=4103,4104
StartTime=$start
} | Select-Object TimeCreated, Id, Message重点关注 4625 中的 Logon Type、Status、SubStatus、Source Network Address。WinRM 常见网络登录会呈现类型 3，但最终表现与认证方式及配置有关。若没有任何 4624 或 4625，而 WinRM Operational 已记录连接异常，问题更可能位于协议协商、监听器或防火墙层。若已有 4624，随后端点拒绝，则优先检查授权 ACL 与令牌内容。容易误判的配置TrustedHosts：它主要影响客户端在非 Kerberos 场景下对目标的信任，不是服务端授权列表。域内可正常使用 Kerberos 时不应随意设置为星号。AllowUnencrypted：允许未加密的 WinRM 消息会降低安全性，不应作为排障捷径。HTTP 传输并不等于凭据明文，但仍应优先使用 Kerberos，跨域或工作组场景可配置 HTTPS 监听器。Basic 认证：不应为解决 Access is denied 而直接启用。先确认 Kerberos SPN、DNS、时间同步和域信任。关闭防火墙：只能掩盖规则问题，还会扩大暴露面。应按管理网段、主机组和端口建立最小范围规则。风险与修复建议将远程管理权限授予专用域组，定期审计成员，避免把普通业务账号加入本地 Administrators。通过 JEA 提供受限端点，只暴露运维所需 cmdlet、参数和目标资源，避免完整交互式管理员会话。保留 WinRM Operational、PowerShell 4103/4104 及安全审计日志，并转发到集中日志平台；容量和留存周期应覆盖审计要求。对本地管理员使用 Windows LAPS，确保每台主机密码唯一，降低凭据复用导致的横向风险。限制 5985/5986 的来源地址，只允许堡垒机或管理 VLAN；跨不可信网络时使用 HTTPS 监听器并校验证书。修复后复测应同时包含正向和反向用例：授权运维组能够建立会话，普通域用户、本地非管理员及非管理网段均应失败。结论“端口可达但 WinRM 拒绝访问”通常不是单一故障。可靠的排查顺序是：网络连通性、WSMan 服务与监听器、身份解析、组与端点 ACL、UAC 远程令牌、限制策略、日志关联。最终交付不应只写“已连通”，还应说明账号为何被允许、权限止于何处、失败尝试留下哪些日志，以及修复后哪些越权路径已被阻断。

先把“WinRM 可达”拆成四层：监听器/网络、认证、会话端点授权、进程执行控制。Test-WSMan 成功只证明 WS-Man 能响应，不代表该账号有权创建 PowerShell Runspace。

建议用同一账号做最小化复现，并保留完整错误对象。客户端先执行：

$cred = Get-Credential
Test-WSMan server01

try {
    Invoke-Command -ComputerName server01 -Credential $cred `
        -Authentication Negotiate `
        -ScriptBlock { whoami /all; $PSVersionTable } `
        -ErrorAction Stop
} catch {
    $_ | Format-List * -Force
    $_.Exception | Format-List * -Force
}

根据失败位置分流：

• Kerberos/Negotiate 报错：优先用主机 FQDN，不要先加 TrustedHosts=*。检查时间、DNS 和 SPN：

  Resolve-DnsName server01.example.local
  w32tm /stripchart /computer:server01 /samples:5 /dataonly
  setspn -Q WSMAN/server01
  setspn -Q WSMAN/server01.example.local
  klist purge

  若使用 IP、工作组或跨无信任域，Kerberos 通常不可用；这时应明确改用 HTTPS，或把单一目标加入 TrustedHosts，避免全局通配。
• Access is denied：检查账号是否属于目标机 Administrators 或 Remote Management Users，以及 PowerShell 端点 ACL：

  Get-LocalGroupMember Administrators
  Get-LocalGroupMember 'Remote Management Users'
  Get-PSSessionConfiguration | Format-List Name,Enabled,Permission
  Get-PSSessionCapability -ConfigurationName Microsoft.PowerShell -Username 'DOMAIN\user'

  Remote Management Users 只解决基础远程管理资格，端点安全描述符、JEA RoleDefinitions 仍可能继续限制。不要直接重置端点 ACL；先导出当前配置并与同基线主机比较。
• 会话能建立但命令被拒绝：检查是否落入 JEA/受限端点，以及 AppLocker、WDAC、Constrained Language Mode：

  Invoke-Command -ComputerName server01 -Credential $cred -ScriptBlock {
      $ExecutionContext.SessionState.LanguageMode
      Get-Command | Select-Object -First 20 Name,CommandType
  }
  
  Get-AppLockerPolicy -Effective -Xml
  Get-CimInstance -ClassName Win32_DeviceGuard `
    -Namespace root\Microsoft\Windows\DeviceGuard

  如果只有部分 cmdlet 可见或提示 “not recognized/unauthorized command”，更像端点能力边界，而不是 WinRM 本身故障。
• 本地管理员账号失败、域管理员正常：核对远程 UAC 令牌过滤。查看 LocalAccountTokenFilterPolicy，但不建议为了测试直接设为 1；优先使用域账号或显式授予端点权限：

  reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy

服务端配置可以这样采集，重点比较监听器、认证方式和插件，而不是直接执行 winrm quickconfig 覆盖现状：

winrm enumerate winrm/config/listener
winrm get winrm/config/service
winrm get winrm/config/service/auth
winrm enumerate winrm/config/plugin
Get-Service WinRM
Get-NetTCPConnection -LocalPort 5985,5986 -State Listen
Get-Item WSMan:\localhost\Service\Auth\*

证据链建议围绕一次精确到秒的复现建立。目标机同时导出以下日志：

$start = (Get-Date).AddMinutes(-10)

Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-WinRM/Operational'; StartTime=$start
} | Select-Object TimeCreated,Id,LevelDisplayName,Message

Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-PowerShell/Operational'; StartTime=$start
} | Select-Object TimeCreated,Id,LevelDisplayName,Message

Get-WinEvent -FilterHashtable @{
  LogName='Security'; Id=4624,4625,4672,4688; StartTime=$start
} | Select-Object TimeCreated,Id,Message

4625 的 Status/SubStatus 用来判断账号、密码、登录权或认证包问题；4624 成功后仍无 Shell，重点转向 WinRM Operational、端点 ACL/JEA；已经创建进程但脚本失败，再看 PowerShell Operational、AppLocker 的 EXE and DLL/MSI and Script 日志及 WDAC CodeIntegrity 日志。WinRM 日志中的活动 ID（ActivityId）应与客户端失败时间关联，不要只凭某个事件 ID 下结论。

最后再检查组策略赋权冲突，尤其是“从网络访问此计算机”和“拒绝从网络访问这台计算机”；拒绝项优先级更高：

gpresult /h C:\Windows\Temp\gp.html
secedit /export /cfg C:\Windows\Temp\secpol.cfg
findstr /i "SeNetworkLogonRight SeDenyNetworkLogonRight" C:\Windows\Temp\secpol.cfg

排查时最好用三组账号做矩阵：已知管理员、待测账号、普通域用户；分别记录 Test-WSMan、认证结果、Runspace 创建结果和最小命令结果。这样通常能很快确认边界是在认证、登录权、端点 ACL，还是应用控制策略，而不必通过放宽 TrustedHosts、关闭 UAC 或重置 WinRM 来“碰运气”。