AppLocker策略必须在域环境下用组策略部署，因依赖Group Policy集中下发和Application Identity服务强制执行；本地配置无效。
AppLocker策略为什么必须在域环境下用组策略部署
单独在本地计算机配置 applocker 几乎无效——applocker 策略依赖 group policy 的集中下发和强制执行，且仅在域控制器（windows server）上启用 application identity 服务后才真正生效。本地组策略编辑器（gpedit.msc）能配规则，但若没启用该服务或未通过域策略推送，applocker 实际不拦截任何程序。
实操要点：
- 域内所有目标客户端（Windows Pro/Enterprise/Education，版本 ≥ Win10 1607 或 Win Server 2012）必须加入域，并启用
Application Identity服务（启动类型设为“自动”，并确保运行中） - 策略必须发布到
Computer Configuration → Policies → Windows Settings → Security Settings → Application Control Policies → AppLocker路径下，而非用户配置分支 - 首次启用时建议先设为“审核模式”（Audit only），避免误拦关键系统进程（如
svchost.exe、dllhost.exe）导致登录失败或服务异常
如何用默认规则快速建立可信白名单基线
从零手写每条规则极易遗漏，官方推荐的 Default Rules 是安全起点：它们基于发布者签名、路径和文件哈希三重约束，覆盖系统目录（%WINDIR%\*）、程序文件目录（%PROGRAMFILES%\*、%PROGRAMFILES(X86)%\*）及已签名的 Microsoft 组件。
启用方式（在组策略编辑器中）：
- 右键
Executable Rules→ “Create Default Rules” - 同理为
Windows Installer Rules、Script Rules、Dll Rules分别创建（注意：DLL 规则默认禁用，需手动勾选“Configured”并启用） - 默认规则本身不阻止任何内容，但为后续细化提供结构化基础；务必检查生成的规则是否包含你环境特有的可信路径（如自定义软件安装目录
C:\Apps\*）
为什么“发布者规则”比“路径规则”更可靠但更难维护
Path Rule（如 C:\Program Files\MyApp\*.exe）见效快，但一旦软件升级改路径、解压即用型工具（如 curl.exe 放桌面）就绕过管控；而 Publisher Rule 基于代码签名证书，只要开发者签名有效、证书链可信，无论文件放在哪都受控。
但现实约束明显：
- 大量内部工具、Python 打包脚本（
pyinstaller）、PowerShell 模块无合法签名，无法用发布者规则覆盖 - 签名证书过期或被吊销会导致规则失效，需定期用
certutil -verify检查信任链 - 测试阶段可用
Get-AppLockerFileInformation -FilePath "C:\temp\tool.exe"预览签名信息，再右键导出规则——别直接靠肉眼识别 CN 字段
审核日志里看到“事件 ID 8003”却没阻断，说明什么
Event ID 8003 表示 AppLocker 记录了一次“本应被阻止但当前策略允许”的访问，常见于规则配置冲突或策略未强制刷新。它不是错误，而是审计线索，但若频繁出现且你预期应拦截，大概率是以下问题：
- 客户端未成功应用策略：运行
gpupdate /force后检查rsop.msc是否显示 AppLocker 策略已加载（路径含Application Control Policies） - 规则作用域错误：规则被配置在“用户配置”下，而 AppLocker 执行引擎只读取“计算机配置”分支
- 规则优先级被覆盖：后创建的规则可能隐式否决前面的规则，用
Get-AppLockerPolicy -Effective -ComputerName $env:COMPUTERNAME | Export-Clixml policy.xml导出实际生效策略，人工比对顺序
最易被忽略的是：AppLocker 不处理子进程继承权限，若父进程（如 cmd.exe）被放行，其调用的未授权子程序（如 net.exe）仍可运行——这时候得靠 LSA 保护或 WDAC 补位，AppLocker 本身管不了这一层。
