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.
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:
- Modify the default rule (shown) to be for the local administrator account ONLY
- 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
- 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