applocker强制执行需先启用application identity服务并配置规则集合，再通过gpo设置“强制实施”，且必须经审核验证后上线。
applocker 的强制执行不是一键开启的操作，它依赖于规则集合、组策略继承顺序和应用程序标识服务的协同运作。直接启用“强制实施规则”前，必须完成规则设计、审核验证和策略部署三步，否则容易导致业务应用被意外拦截。
确认 AppLocker 基础服务已启用
强制执行的前提是 Application Identity 服务（AppIDSvc） 正在运行且设为自动启动。该服务负责识别文件签名、路径、哈希等属性，没有它，所有规则都无效。
- 在目标计算机上运行
services.msc，找到“Application Identity”，右键属性 → 启动类型设为“自动”，并手动启动服务 - 若使用域环境，可通过组策略统一配置：计算机配置 → 策略 → Windows 设置 → 安全设置 → 系统服务 → Application Identity → 设为“自动”并“已定义”
- 注意：Windows Server Core 或 Nano Server 默认不安装此服务，需先添加“Application-Identity”功能
在 GPO 中正确配置规则集合与强制模式
AppLocker 规则按类型分为五个集合：可执行文件、Windows Installer、脚本、DLL 和打包应用。每个集合的强制设置独立控制，不能混用。
- 打开“组策略管理控制台”（GPMC），编辑目标 GPO → 计算机配置 → 策略 → Windows 设置 → 安全设置 → 应用程序控制策略 → AppLocker
- 依次展开各规则集合（如“可执行文件规则”），右键 → “创建默认规则”仅作起点，不可直接用于生产；应基于实际业务软件清单逐条新建规则
- 右键“AppLocker”节点 → “属性” → 切换到“强制实施”选项卡 → 对每个需生效的集合勾选“已配置”，再选择“强制实施规则”
- 切勿对同一集合同时启用“强制实施”和“仅审核”——后者仅用于测试阶段，上线前必须全部切换
处理多层 GPO 的继承与冲突
AppLocker 强制设置遵循“最后一次写入生效”原则，但规则本身会叠加合并。这意味着上级 GPO 设为“强制”，下级 GPO 设为“未配置”，最终仍会强制；但若下级明确设为“仅审核”，则覆盖上级强制。
- 检查 GPO 链接顺序：OU 层级越深、链接顺序越靠后，其强制设置优先级越高
- 使用
gpresult /h report.html查看客户端实际生效的 AppLocker 策略和强制状态 - 避免在不同 GPO 中为同一路径或发布者重复建规则；拒绝规则始终优先于允许规则，哪怕它来自更高级别 GPO
- 建议将“基础允许规则”（如系统目录、签名可信软件）放在顶层 GPO，“业务专用限制”放在部门级 GPO，便于定位问题
上线前必须完成审核与验证
跳过审核阶段直接强制，是导致用户无法启动关键应用的最常见原因。AppLocker 日志（事件查看器 → 应用程序和服务日志 → Microsoft → Windows → AppLocker）是唯一真实反馈源。
- 先将所有规则集合设为“仅审核”，保持 1–2 周，收集 Event ID 800x（允许）、800y（拒绝）事件，重点关注被拦截但应放行的进程
- 用 PowerShell 快速验证单个文件是否匹配规则：
Test-AppLockerPolicy -PolicyObject (Get-AppLockerPolicy -Local) -FilePath "C:\app\tool.exe" - 导出当前策略为 XML（右键 AppLocker → “所有任务” → “导出策略”），便于版本比对和回滚
- 首次强制后，建议保留 48 小时应急窗口：通过组策略立即切回“仅审核”，或临时禁用 AppIDSvc 缓解影响
