我正在尝试使用 AppLocker 制定动态应用程序阻止规则。设置是，我已预定义 AppLocker 规则（例如，Allow windows user group 'Chrome' access 'chrome.exe'（不是实际组名或实际路径）），然后在登录时借助 Windows 服务将用户分配到组。
一开始运行良好，但过了一段时间就停止了（AppLocker 本身可以工作，但用户组特定规则不适用——换句话说，一切都被阻止了）。我通过 PowerShell 命令测试了所有组合策略，根据这些策略，属于用户组的用户Chrome应该被允许访问chrome.exe，但实际上我会收到应用程序被阻止的提示。
然后我尝试创建特定于用户的规则以允许chrome.exe，这很有效，但一旦我将其删除（组规则仍然存在），我就会再次被阻止。或者甚至只是将现有用户组策略更改为指向特定用户使其工作，然后更改回指向用户组不再起作用。
有趣的是 - 在几次 VM 重启之后它又可以工作了，然后第二天当我想向同事演示它时，我再次遇到了同样的问题，这个问题再次通过多次 VM 重启得到解决。
一个明显的可能问题是“用户真的属于该组吗？”答案是肯定的：每次当该政策不起作用时，我都会进入lusrmgr并验证这一点。
有关其他背景信息 - VM 托管在 Azure 上，运行 Windows 10 多会话 21H1，AppLocker 在本地机器级别设置（目前没有域范围的策略或类似的东西）。
答案1
当您依赖此规则的自动应用时，此操作会失败，原因是用户被添加到组中后他们已经登录。
当您将用户添加到某个组时，他们的新组成员身份直到下次登录时才会生效（但他们的帐户仍保留在该组中）。登录时，用户的 Kerberos 令牌是根据其帐户 SID 和其所属的所有组的 SID 的组合生成的。每当为用户检查任何基于组的操作（ACL、AppLocker 策略等）时，实际检查的是他们的 Kerberos 令牌。
解决方案有很多种，具体取决于您环境中的很多因素。以下两种解决方案可能适用：
- 使用基于域的安全组来分配用户对应用程序的访问权限。这些权限在用户登录之前就已存在，并且他们的 Kerberos 令牌是完整的。这种方法比下面的“解决方案”要好得多。
- 如果无法使用基于域的组，您可以在 Windows 服务将用户添加到组后运行脚本。要使用组成员身份更改手动更新用户的 Kerberos 令牌后他们已登录，无需再次注销/登录，运行命令
klist purge。这将强制重新生成他们的 Kerberos 令牌，然后它将包括他们的新组成员身份。此时，您的动态 AppLocker 策略将起作用。
列表：https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/klist