SharePoint AppLocker Setup *Update*

So in the last post we talked about using “AppLocker” as a way to control executable processes from running on servers. Using these rules we were able to “whitelist” and “blacklist” so only those processes needed can run.

https://www.helloitsliam.com/2015/07/10/using-applocker-on-a-sharepoint-server/

Now for a SharePoint Server, as you know everyone has different ways of managing them, different accounts, always using Administrator, separate Install and Farm accounts or just use what is there. This can cause issues when using “AppLocker” as you need to be able to run updates and deploy components on those servers.

So to understand this let’s look at how this process should work. Firstly for SharePoint we should be using something like this for Permissions and Management.

Account Account Permission Account Role
Administrator Domain User/Admin and Local Server Administrator Local Server Administrator full access to everything on the server
Setup Domain User and Local Server Administrator Local Server Administrator full access to everything on the server
Farm Administrator Domain User User Account

This means that anyone who logs into the server as either “Administrator” or the “Setup” account would then be allowed to run really any executable due to the default rule for “Administrators” in the core rule base.

As you can see this rule allows ALL files to be used for the “BUILTIN\Administrators” security group, so creating rules that are specific to security groups can ensure that not every account in the SharePoint Farm that *needs* to be a local Administrator can do what they want.

The following steps would be needed:

  1. Modify the default rule (shown) to be for the local administrator account ONLY
  2. Create other rules for specific accounts such as the SharePoint Setup account which would need local administrator permissions for install and other patching and deployment processes
  3. Create rules for the SharePoint Farm administrator as needed

With specific rules created for the various accounts and security groups you are able to maintain integrity and not allow the Administration accounts to do whatever they want. Just because we don’t trust the developers doesn’t mean we should have Administration access to everything J #justkidding

Liam Cleary

I work as an Associate Director for Protiviti in Virginia. My main focus is to ensure that SharePoint can either natively or with minimal customization meet the business requirement securely. I am currently a SharePoint MVP focused on Architecture but also cross the boundary into Development and Security. I am often found at user groups, conferences speaking, offering advice, spending time in the community, teaching my kids how to code, raspberry PI programming, hacking the planet and sometimes building Lego robots.

You may also like...