使用者組的動態 Windows 10 AppLocker 規則不起作用
我正在嘗試使用 AppLocker 制定動態應用程序阻止規則。設置是我預定義了 AppLocker 規則（例如，
Allow windows user group 'Chrome' access 'chrome.exe'（不是實際組名或實際路徑）），然後在 Windows 服務的幫助下在登錄時將使用者分配到組。起初效果很好，但過了一段時間就停止了（AppLocker 本身可以工作，但使用者組的特定規則不適用——換句話說，一切都被阻止了）。我測試了通過 PowerShell commandlet 組合的所有策略，根據它們，屬於使用者組的使用者
Chrome應該被允許訪問chrome.exe，但實際上我會得到一個應用程序被阻止的提示。然後我嘗試創建使用者特定的規則來允許
chrome.exe，它工作正常，一旦我刪除它（組規則仍然存在），我會再次被阻止。或者甚至只是將現有使用者組策略更改為指向特定使用者使其工作，然後更改回指向使用者組不再工作。有趣的部分 - 在幾次 VM 重新啟動後它再次工作，然後第二天當我想向同事展示它時，我又遇到了同樣的問題，再次通過多次 VM 重新啟動解決了這個問題。
一個明顯的可能問題可能是“使用者真的屬於該組嗎？” 答案是肯定的：每次政策不起作用時，我都會去
lusrmgr驗證。對於其他上下文 - VM 託管在 Azure 上，執行 Windows 10 多會話 21H1，AppLocker 設置在本地電腦級別（沒有域範圍的策略或類似的 atm）。
當您依賴此規則的自動應用程序時失敗的原因是使用者在登錄後被添加到組中。
當您將使用者添加到組時，他們的新組成員身份在他們下次登錄時才會生效（而他們的帳戶仍保留在該組中）。在登錄時，使用者的 Kerberos 令牌是根據其帳戶 SID 和他們所屬的所有組的 SID 的組合生成的。每當為使用者檢查任何基於組的操作（ACL、AppLocker 策略等）時，實際檢查的是他們的 Kerberos 令牌。
將有多種不同的解決方案，具體取決於您環境中的許多因素。兩種解決方案可能是：
- 使用基於域的安全組來分配使用者對應用程序的訪問權限。這些將在他們登錄之前存在，並且他們的 Kerberos 令牌將是完整的。這將是比下面的“解決方案”更好的方法。
- 如果無法使用基於域的組，您可以在 Windows 服務將使用者添加到組後執行腳本。要在使用者登錄後使用組成員身份更改手動更新使用者的 Kerberos 令牌，並且不需要他們再次註銷/登錄，請執行命令
klist purge。這將強制重新生成他們的 Kerberos 令牌，然後它將包括他們的新組成員身份。此時，您的動態 AppLocker 策略將起作用。klist：https ://docs.microsoft.com/en-us/windows-server/administration/windows-commands/klist