AppLocker, Service Accounts, and Group Policy Pitfalls

AppLocker is managed and enforced by two Windows Services: AppIDSvc and AppID.  AppIDSvc handles the configuration and management of AppLocker, and is the service primarily discussed in Microsoft documentation.  But, AppID is the service that AppIDSvc depends on to do the actual enforcement of AppLocker policy.  In order for AppLocker to work correctly, both of these services must be enabled and running.

For this reason, it makes sense to include some extra settings in your group policy to ensure that the AppIDSvc is running on your target systems: Naturally, you’ll open up your Group Policy Management Editor and navigate to Computer Configuration -> Preferences -> Control Panel Settings -> Services.  Then, right-click, select New, and then Service.  Type in the Service name, “AppIDSvc”, and set the Service action to Start Service.  Click the radio button to set the Log on account to Local System account, click OK and then you are done!  Right?

Wrong!  If you do this, you’ll end up spending the next 4 hours trying to trace the cause of “Error 31: A device attached to the system is not functioning” while simultaneously being baffled by the fact that some of your systems are still enforcing and logging AppLocker debugging error messages.

You need to make sure that your service is configured to run as “NT Authority\Local Service” in your group policy settings.  If you (like me) have accidentally pushed out a policy with the “Local System account” set as the Log on user for the account, you can go back into your group policy settings, change the Log on as setting to This account: and type in “NT Authority\Local Service”.  You will need to specify a password to satisfy the dialog box—but it doesn’t matter what it is, the Local Service account doesn’t have a password and whatever you type there will be ignored by the client system.  Just type in something to satisfy the dialog box.  I used a single space.  Now you should see the account correctly displayed in the Group Policy editor.

 
But why were my AppLocker policies that were already pushed out still being enforced even though the service stopped running?  Remember the AppID service?  The AppID service is actually there to register a kernel-mode device driver that handles the actual enforcement of policy.  So even if you break AppIDSvc, which is responsible for managing and applying policy, AppID will keep running and keep enforcing whatever policy you had in place when you decided to break AppIDSvc.

You shouldn’t need to specify anything for this service to start, as it’s a registered dependency of AppIDSvc.  If you wanted to be extra-thorough, you could verify that the service isn’t marked as disabled in the registry.  Implementing that step, perhaps by tattooing the registry, is left as an exercise to the reader.  Details about both services are located in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\.  Details about those details (metadetails?) are described in this Microsoft TechNet article.

Of course, once you've got the services enabled and working correctly, you’ll still need to configure your AppLocker Application Control Policies, link your Group Policy Object to your target OU, and refresh group policy on your clients before you start to see AppLocker in action.  Don’t forget to look in Server Manager -> Diagnostics -> Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> AppLocker to see information about how your policies are being enforced on your system.