Join Log in
Score:1
avatar Server

Dynamic Windows 10 AppLocker rules for user groups not working

jp flag
Edgar.A

I'm trying to make dynamic app blocking rules with AppLocker. The setup is that I have predefined AppLocker rules (for example, Allow windows user group 'Chrome' access 'chrome.exe' (not actual group name or actual path)) and then assigned users to groups at login with the help of a Windows service.

That worked fine at first, but after a while it stopped (AppLocker itself worked, but user groups specific rules didn't apply--in other words, everything was blocked). I tested all policies combined via PowerShell commandlets, and according to them the user that belongs to the user group Chrome should be allowed to access chrome.exe, but in reality I'd get an app blocked prompt.

Then I tried creating user specific rule to allow chrome.exe, which worked fine and as soon as I removed it (group rule still exists), I'd get blocked again. Or even just changing existing user group policy to point to specific user made it work and then changing back to point to user group not work again.

Funny part - after a few VM restarts it worked again, and then next day when I wanted to demo it to a colleague, I got the same issue again, which again was solved by multiple VM restarts.

An obvious possible issue could be 'does the user really belong to the group?' and the answer is yes: each time when the policy wouldn't work, I'd go into lusrmgr and verify that.

For additional context - the VM is hosted on Azure, running Windows 10 multi-session 21H1, AppLocker is setup on local machine level (no domain wide policies or anything like that atm).

196
1 + 0
Score:1
SamErde avatar Server
gg flag
SamErde

The reason this is failing when you rely on the automated application of this rule is because users are being added to groups after they have logged on.

When you add a user to a group, their new group membership does not take effect until the next time they log on (while their account remains in that group). At logon, a user's Kerberos token is generated based on a combination of their account SID and the SIDs of all groups that they are a member of. Whenever any group-based operations are checked for a user (ACLs, AppLocker policies, etc), the thing that actually gets checked is their Kerberos token.

There would be multiple different solutions, depending on a lot of factors in your environment. Two solutions could be:

  • Use domain-based security groups to assign users' access to applications. These would be present before they log on, and their Kerberos token would be complete. This would be the far better approach than the 'solution' below.
  • If unable to use domain-based groups, you could run a script after your Windows service adds the user to a group. To manually update a user's Kerberos token with group membership changes after they have logged on, and without requiring them to log off/on again, run the command klist purge. This will force their Kerberos token to be regenerated, and it will then include their new group membership. At this point, your dynamic AppLocker policies will work.

klist: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/klist

0 + 1
jp flag
Edgar.A
My hero! You just saved many hours of frustration and possibly my sanity
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.