授权测试中 SMB 登录成功却提示“拒绝访问”，该查共享权限还是 NTFS？

发布于7小时前7小时

背景：认证成功，不代表目录可读

问题：在一次授权内网测试中，使用域测试账号访问文件服务器。TCP 445 可达，服务器出现该账号的 4624 登录事件，但打开指定共享目录仍提示“拒绝访问”。这能否证明账号具有共享访问权限？应该从哪里排查？

结论：不能。4624 只能说明某次登录成功；即使确认是本次 SMB 请求对应的网络登录，也不能证明目标文件的授权检查通过。需要依次核对实际会话身份、共享权限、NTFS 权限，以及操作对应的访问检查记录。

以下以域成员文件服务器 FS01、共享 Audit、实际目录 C:\Shares\Audit 为例。所有操作限定在批准的测试账号和目录内，不枚举无关共享，不进行口令尝试。

问题定位：先把现象描述准确

访问的是普通业务共享还是管理共享？Audit 与 C$ 的权限边界不同，不能用管理共享失败推断普通共享异常。
失败发生在打开共享根目录、进入子目录、读取文件，还是创建文件？不同动作需要的权限不同。
服务器记录的账号是否真的是测试账号？客户端可能复用了已有 SMB 会话。
路径是否经过 DFS、别名或集群入口？客户端输入的名称不一定就是最终处理访问的服务器。
客户端与服务器时间是否一致？建议记录时间、时区、客户端地址、完整路径和具体操作，避免关联错事件。

第一步：确认连接目标和实际身份

在客户端执行以下只读检查。读取目录本身会产生访问痕迹，应使用范围内已约定的测试共享。

Test-NetConnection -ComputerName FS01 -Port 445
Get-SmbConnection |
    Select-Object ServerName, ShareName, UserName, Credential, Dialect, NumOpens
Get-ChildItem -LiteralPath '\\FS01\Audit' -ErrorAction Stop

445 可达只说明 TCP 连接正常。Get-SmbConnection 用于检查当前 SMB 连接身份；如果访问尚未建立成功，可能没有对应条目。不要把客户端 whoami 的输出直接当成服务器访问令牌，因为 SMB 可以使用显式提供的其他凭据。

若发现同一服务器已有其他身份的连接，先记录连接信息，再在隔离测试终端或独立测试会话中复现。不要直接清空所有网络连接，尤其不要在业务终端执行无差别断连操作。

第二步：分别核对共享 ACL 与 NTFS ACL

在 FS01 上由管理员执行：

$share = Get-SmbShare -Name 'Audit'
$share | Select-Object Name, Path, Description, FolderEnumerationMode
Get-SmbShareAccess -Name 'Audit'

$acl = Get-Acl -LiteralPath $share.Path
$acl | Format-List Owner, AreAccessRulesProtected
$acl.Access |
    Select-Object IdentityReference, AccessControlType,
                  FileSystemRights, IsInherited,
                  InheritanceFlags, PropagationFlags

# 如果仅子目录失败，必须单独检查该子目录
Get-Acl -LiteralPath 'C:\Shares\Audit\Reports' |
    Format-List

对普通远程文件访问，共享层和 NTFS 层都必须允许请求的操作。共享授予 Change，不会覆盖 NTFS 只读限制；NTFS 授予 Modify，也不会绕过共享层的 Read 限制。

重点看以下几项：

共享授权给的是哪个安全组，测试账号是否实际属于该组。
失败目录是否关闭了继承。AreAccessRulesProtected 为 True 表示 DACL 继承受到保护，不代表它一定配置错误。
ACE 是否作用于当前目录、子目录或文件。仅比较权限名称，容易漏掉继承和传播范围。
是否存在对账号或所属组生效的拒绝项。显式、继承 ACE 的顺序与适用范围会影响结果，不能简单套用“任何拒绝都优先”的口诀。
请求究竟是列目录、读取内容还是写入。读成功、写失败不等于配置故障，可能就是预期边界。

Get-Acl 展示的是安全描述符，不会替你完整计算该账号的有效访问。复杂组嵌套场景可结合服务器上的“高级安全设置 → 有效访问”分析，并用实际 SMB 请求复核。账号刚调整组成员关系时，已有登录令牌和会话也可能仍使用旧的组信息，应通过批准的新会话重新验证。

第三步：把日志串成同一次请求

在 FS01 上查询最近二十分钟的相关安全事件：

$start = (Get-Date).AddMinutes(-20)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624, 4625, 5140, 5145, 4656, 4663
    StartTime = $start
} -ErrorAction Stop |
    Sort-Object TimeCreated |
    Format-List TimeCreated, Id, Message

# 只查看当前审计配置，不修改策略
# 输出中的子类别名称随操作系统语言变化
auditpol /get /subcategory:*

建议按下面的顺序解读，而不是仅搜索账号名称：

4624：核对账号、源地址、登录类型和 Logon ID。SMB 常见登录类型为 3，但类型 3 本身不能单独证明请求就是 SMB。
4625：若确实出现，先核对状态码与子状态码，判断认证或登录权限问题，不要直接归因于目录 ACL。
5140：用于确认网络共享访问上下文，不能据此认定某个文件读取成功。
5145：若启用了详细文件共享审计，可查看共享名、相对目标名、请求的访问类型及检查结果；它不能替代后续 NTFS 访问检查证据。
4656、4663：结合对象名、访问类型和事件结果分析文件系统访问。4656 表示请求对象句柄，4663 可帮助确认实际使用的对象权限；不能期待每次拒绝访问都必然出现 4663。

同一台服务器内可使用 Logon ID 关联登录与共享事件，再核对源地址、时间和目标路径。不要跨主机把相同数值的 Logon ID 当成同一会话。高负载服务器上的全量查询可能很大，应缩短复现窗口，并按账号和目标继续筛选。

没有事件，不等于没有访问。相应高级审计策略未开启、对象 SACL 未配置、日志已覆盖，或请求实际落在其他节点，都可能造成证据缺失。文件系统对象审计通常还需要匹配的 SACL；只开启审计子类别并不足以保证记录目标访问。

技术分析：几种容易误判的结果

4624 成功，但共享 ACL 不包含账号或其有效组：先处理共享授权问题，不能拿登录成功作为共享可读证明。
共享检查通过，但指定子目录失败：优先核对子目录 ACL、继承范围和实际请求权限，不要立即扩大整个共享的权限。
目录可列出，文件无法读取：列目录与读取文件内容属于不同权限，继续检查文件自身 ACL。
本地管理员访问 C$ 失败：可能涉及本地账号的远程 UAC 令牌过滤，但必须结合账号类型、策略和日志确认；域账号与本地账号不能混为一谈。
调整安全组后仍失败：先考虑旧会话或旧登录令牌，不要反复叠加授权来“试通”。

风险与修复建议

修复应围绕预期业务动作，而不是以“能打开”为唯一目标。建议使用专门的域安全组承载权限，分别定义只读和修改角色，并检查共享层与 NTFS 层是否一致。确需写入验证时，只在获批的测试子目录创建无敏感内容的临时文件，验证后清理并留存操作记录。

不要为了排障授予 Everyone 完全控制，也不要直接关闭远程 UAC 过滤、开启 SMB1 或放宽全局认证策略。这些操作会改变安全边界，却未必触及真正故障点。

需要补充审计时，先评估日志量，在指定目录配置必要的 SACL，按变更流程启用相关成功或失败审计，并确认集中采集没有丢失。复测至少包含：应允许的账号执行应允许的动作成功；不应允许的账号或动作仍然失败。

总结：问答时提供哪些证据最有用

提交这类求助，建议附上脱敏后的系统版本、域或工作组环境、账号类型、访问路径、失败动作、准确时间、共享 ACL、失败对象的 NTFS ACL，以及同一窗口内相关事件的关键字段。不要公开密码、票据或其他认证材料。

排查顺序可以固定为：确认目标与身份 → 核对共享授权 → 核对目标对象权限 → 关联日志 → 最小化修复 → 正反向复测。这样才能把“拒绝访问”定位为可复现的权限边界问题，而不是靠放大权限碰运气。

6小时前6小时

两层都要查，但先确认“拒绝访问”发生在哪一步。SMB 登录成功只代表身份认证通过，不代表有共享或文件访问权限。另外，不能枚举共享，也不等于无法访问已知共享，建议直接测试授权范围内的具体路径。

客户端先确认实际使用的身份，排除已有 SMB 会话复用了其他凭据：

Get-SmbConnection | Format-Table ServerName,ShareName,UserName,Dialect
net use

如需重连，只断开目标共享，不要用 net use * /delete 影响其他连接：

net use \\server\share /delete
net use \\server\share /user:DOMAIN\testuser *
dir \\server\share
dir \\server\share\目标目录

服务端有管理权限的话，对照检查共享 ACL 和实际目录的 NTFS ACL：

Get-SmbShare -Name "share" | Select-Object Name,Path
Get-SmbShareAccess -Name "share"
icacls "D:\Share"
icacls "D:\Share\目标目录"

共享根目录都进不去：共享权限和根目录 NTFS 权限都可能有问题，不能仅凭这一点定性。
根目录能列，子目录或文件打不开：优先看对应对象的 NTFS ACL、继承是否中断，以及用户所属组是否命中拒绝项。
能读不能写：共享层是否只有 Read，NTFS 层是否缺少创建、写入或修改权限；删除、重命名也要单独验证。

最终权限受两层共同限制。NTFS 可以在“高级安全设置 → 有效访问”中选实际账号核对，但别把这里的结果当成共享权限检查。

如果访问的是 C$、ADMIN$，还要考虑本地管理员账号的远程 UAC 令牌过滤，不建议为了验证直接关闭它。日志方面可关联安全日志 4624（登录类型 3）和 5145（需启用详细文件共享审核）；注意 5145 主要定位共享层检查，不能单独证明 NTFS 已放行。最好补充具体 UNC 路径、失败操作和账号类型，才能进一步缩小范围。

登录