windows用户权限分配本身不会自动记录日志，必须启用高级审核策略（gpedit.msc→高级审核策略配置）中的account management、policy change和object access（配合sacl），才能通过事件查看器捕获id 4719、4728、4732、4670等可追溯日志。

windows 用户权限分配本身不会自动记录在默认日志中，必须主动启用对应审计策略，并配合事件查看器才能捕获相关行为。关键不是“系统会不会记”，而是“你有没有告诉系统去记”。

哪些操作属于“权限分配”且可被审计

以下行为在启用正确策略后，会生成可追溯的日志事件：

• 修改本地安全策略中的“用户权限分配”项：例如赋予某用户“从网络访问此计算机”或“允许本地登录”，触发事件 ID 4719（系统审计策略已更改）
• 将用户加入或移出敏感组（如 Administrators、Backup Operators）：由“账户管理”子类审计，对应事件 ID 4728（添加到启用的全局组）、4729（从启用的全局组移除）、4732（添加到启用的本地组）等
• 直接修改 NTFS 或注册表权限：需提前为该资源设置 SACL（系统访问控制列表），启用“审核对象访问”后，成功/失败的权限变更会记录为 ID 4670（权限更改）

必须启用的审计策略位置

secpol.msc（本地安全策略）里的“审核策略”页面已弃用，实际生效的是：

• 打开 gpedit.msc → 计算机配置 → Windows 设置 → 安全设置 → 高级审核策略配置
• 逐项启用以下子类（成功 + 失败）：
    • Account Management（账户管理）
    • Policy Change（策略更改）
    • Object Access（对象访问，仅当设置了SACL时才记录具体文件/注册表变更）

如何验证权限分配是否被记录

配置完成后，不要只看开关是否勾选，要查真实日志：

• 打开 eventvwr.msc → Windows 日志 → 安全
• 筛选事件 ID：
    • 4719：确认策略变更时间、操作账户、修改了哪条权限
    • 4728 / 4732：确认用户加入哪个组、由谁执行
    • 4670：确认哪个文件或注册表项的权限被改动、前后差异
• 右键事件 → “将事件另存为…” → 用文本工具打开，检查“Subject”（操作者）、“Privilege List”（是否用了 SeSecurityPrivilege 等高危权限）

权限分配后没留下日志？常见原因

不是策略没开，而是执行过程绕过了审计路径：

• 用 net localgroup administrators zhangsan /add 命令添加用户——这类命令不走组策略引擎，可能不触发 4728/4732，但会触发 4719（如果它间接导致策略重载）
• 通过第三方工具（如 PowerShell 模块、域管理脚本）批量加组，未启用对应审计子类
• 目标用户当前登录会话未刷新，新权限未体现在令牌中，导致后续操作不触发预期审计（可用 whoami /all 验证）
• 安全日志已满且设置为“不覆盖”，新事件无法写入（检查 wevtutil gl Security 中 Enabled 和 IsFull 状态）