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. Because AppLocker blocks everything except that which is specifically allowed, the exception actually creates a targeted block.
APPLOCKER POLICIES WINDOWS
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). There is a way to do this, but it feels a bit back-to-front. 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. 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.
But this doesn’t really fulfil our requirements. This works, and has the added bonus of not breaking your machine so badly it needs to be restored from a snapshot. If you set it up (which I wouldn’t advise), the GPO you configured would probably look something like this So even if you’re allowing administrators to run everything with a wildcard, the Deny for Everyone will still override it. 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. 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.
“Well, why don’t I just block everything in the Windows folder for Everyone, and then put an exception in for my ‘Allow’ group?”įirst of all, though, the AppLocker concept of an exception might not be what you think it is. If you’re aware that AppLocker supports exceptions, you may have this thought. Unseasoned AppLocker users often go for this approach, which can burn quite badly. Let’s give you some examples of incorrect ways that people attack it. The requirement sounds easy enough, but AppLocker can be a little bit tricky to get right with these parameters. 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. 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. 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. There are GPOs that can control some of these, but if AppLocker is your approach then it makes sense to leverage that. Think anything in the Windows system folders – the command prompt, Registry editor, FTP, subst, etc., etc. 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!)Ī common requirement for any application management tool is to restrict system applications.
APPLOCKER POLICIES SOFTWARE
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.
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.ĪppLocker is Microsoft’s GPO-based technology that deals with application execution restriction.
0 kommentar(er)
