I have been asked about this a few times in the past, so thought I would quickly document it while it is fresh in my memory.
AppLocker is Microsoft’s GPO-based technology that deals with application execution restriction. It superseded the old Software Restriction Policies and is itself slated to be replaced by Microsoft Defender Application Control, but as of today, it is still the recommended application management solution, particularly within multi-user environments. Rather than discuss the ins and outs of each of these technology stacks (or even third-party tools that can extend these capabilities, such as Ivanti Application Control or Citrix WEM), I will simply link you to this article for further reading (which was actually written by me, despite what the author details may have you think!)
A common requirement for any application management tool is to restrict system applications. Think anything in the Windows system folders – the command prompt, Registry editor, FTP, subst, etc., etc. etc. There are GPOs that can control some of these, but if AppLocker is your approach then it makes sense to leverage that. The commonest use case I see is that people want administrators to be able to run anything, but wish to restrict the use of certain system executables to “whitelist” groups. Let’s take an example and use FTP – the FTP executable is only to be used by Administrators, and any users added to an “FTP Allow” Active Directory group. Everyone else is blocked by default.
Obviously it goes without saying that you’d need to turn on AppLocker (by enabling the App Identity service and configuring it for “Enforced” – both of which are covered in the article linked above) and create your required AD group ahead of time.
The requirement sounds easy enough, but AppLocker can be a little bit tricky to get right with these parameters. Let’s give you some examples of incorrect ways that people attack it.
Unseasoned AppLocker users often go for this approach, which can burn quite badly. If you’re aware that AppLocker supports exceptions, you may have this thought. “Well, why don’t I just block everything in the Windows folder for Everyone, and then put an exception in for my ‘Allow’ group?”
First of all, though, the AppLocker concept of an exception might not be what you think it is. You can’t set up an exception for a specific user or group, you simply set up an exception that isn’t caught as part of the rule. So the only thing you can do is set up an exception for the target executable – it can’t be associated with a user or group.
Secondly, Deny trumps all. So even if you’re allowing administrators to run everything with a wildcard, the Deny for Everyone will still override it.
If you set it up (which I wouldn’t advise), the GPO you configured would probably look something like this
The exception configured would simply be a path or hash rule that specifies the FTP executable, as shown below
If you do set this up and also link it to an OU, I hope you have a snapshot. Because this will actually stop everyone from being able to run anything from the %WINDIR% folder apart from the FTP executable. And if you think you can just disable the policy and run a Group Policy update, think again…
…because even gpupdate will be blocked. if you haven’t taken a snapshot – get rebuilding.
Now of course, when confronted with this, a lot of users circle back and end up taking the “group blacklist” approach. That is, you allow the Windows folder executables to run but simply stop them from running for certain users or groups, as shown below.
This works, and has the added bonus of not breaking your machine so badly it needs to be restored from a snapshot. But this doesn’t really fulfil our requirements. Why not? Well, it relies on each user who is being restricted from running the target executable being added to a specific AD group, so it isn’t the desired state, which is that users are only allowed to run the sensitive app if they’re specifically configured to. Using the “blacklist” approach means that all users who aren’t in the group can run the app, so any user that slips through the net or isn’t provisioned properly escapes the rule.
There is a way to do this, but it feels a bit back-to-front. The trick is, configure an Allow rule for the Windows folder for Everyone, but put an exception in for your target executable (so in this case, c:\windows\system32\ftp.exe). Because AppLocker blocks everything except that which is specifically allowed, the exception actually creates a targeted block. You can then create an Allow rule for your AD group, which doesn’t interfere with the exception – because an exception isn’t an explicit Deny rule. Obviously, you also need the Default Rule as well that allows everything for Administrators.
In case you’re confused, here’s the GPO with the required settings added
The exception is exactly the same as it was previously, except applied to an Allow rule rather than a Deny
This works perfectly – any user not in the group can’t run the target executable, and any user who is added to the group can run it without issue, along with Administrators who can run anything.
AppLocker is a somewhat convoluted beast, but it has a lot of good features to help enhance your security posture. Until MDAC becomes fit for multi-user systems, it’s really the only choice you have for app management unless you are adopting third-party tools. This guide should help you with dealing with what looks like a straightforward use case but which becomes slightly complicated if you’re unfamiliar with the tech.
A few helpful notes when dealing with AppLocker. Firstly, familiarize yourself with the event log under Applications and Services | Microsoft | Windows | AppLocker. Secondly, if you see any inconsistency and weirdness when applying rules, a reboot will normally sort it out. Finally, if your Windows Start Menu stops functioning after applying AppLocker rules, you may need to configure the “Default Rules” for Packaged Apps – even if you haven’t configured Packaged Apps to “Enforced”! This looks like a bug.
More content due later this week – please keep coming back and supporting this site!
13,549 total views, 13 views today
Weird one but have you ever seen where an exception just wont apply?
I’m following the above steps to try and block RDP and then allow it for a certain AD group but after applying the same as above, it still launches for everyone.
If I set an explicit deny on RDP then that works, nobody can launch it but for now a few users still need it.
My next step to do disable this GPO (It was setup before I joined and configured with god knows what else) and do a fresh one in UAT but just wanted to get your thoughts
What does the event log say, is it allowed by a rule? Sounds odd….
Yeah the log says its allowed. And doing the steps from https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/test-an-applocker-policy-by-using-test-applockerpolicy to test for blocks returns nothing.
Will test a new GPO today and see!
So it turns out that someone had configured the default rules as a local policy too and left them in the image. Disabled them and all was good.
I would have thought that the rules configured on the GPO applied to the OU would have taken precedence over the local rules but sure anyway!
I agree, would have thought OU would have applied over local.
Thank you, very good article, there are many tutorials on the internet that explain the basics of applocker but none explain the correct technique as you do with the exceptions.