2.7.2 AppLocker (part 2)
By Val Bakh
In last month’s blog post about AppLocker, we covered the basics of using AppLocker. Now let’s consider a few examples of AppLocker use that might help you avoid unexpected and sometimes unpleasant situations.
Suppose GPO1 is linked to an organizational unit (OU) that contains computers in your testing lab. You create several AppLocker executable rules in GPO1 and do not configure any explicit enforcement settings. The rules work fine. Suppose GPO2 is linked to the domain. You create another set of AppLocker executable rules in GPO2 and select the Audit only option. Although GPO1 is linked to the OU and, therefore, has precedence over domain-level GPO2, the explicit Audit only setting in GPO2 overrides the implicit configuration in GPO1. As a result, your lab computers are subject to all of the rules in both GPOs, but all those rules are applied in Audit only mode; all relevant events are logged, but no applications are prevented from running. If you now explicitly enforce the rules in GPO1 (that is, you enable the Configured option and select the Enforce rules option for executable rules), the AppLocker configurations in the two GPOs will be in a conflict and GPO1 will win the conflict. As a result, all of the rules in both GPOs will be enforced on the lab computers.
As you can see, AppLocker configuration consists of several layers and can sometimes get rather complicated and confusing. Therefore, try to keep your AppLocker deployment plan as simple as possible. And always be extra cautious; otherwise, you can easily end up locking down your entire network. For example, assume you create a single rule—it may even be an Allow rule—in a domain-level GPO and configure a policy for the Application Identity service to start automatically. The next thing you know, all computers in the entire domain have become unusable. How would you correct your mistake if no one, including yourself, can log on to any computer in the domain? One possible solution is to restart a domain controller in Safe Mode. In this mode, GPOs are not applied and only the essential services are started. You can then log on to the domain controller locally and disable the Application Identity service. After restarting the domain controller normally, you will be able to create the default AppLocker rules or the appropriate additional custom rules that will enable the operating system to function properly. To unlock all the other computers, you can now simply restart them.
Here is another tricky situation. Let’s say all client computers on your network run Windows XP, Windows Vista, or Windows 7 Professional. The company’s IT security guidelines prohibit users from running unauthorized software. You have configured software restriction policies (SRPs) that enforce this requirement. The company’s management decides to upgrade or migrate the client computers to Windows 7 Enterprise. You successfully perform the deployment. The software restrictions are still functioning properly at this point because Windows 7 fully supports SRPs. Then your company purchases a new application for one of the departments. You deploy the application and configure an appropriate AppLocker rule so that only authorized users can run the application. Suddenly the entire domain is locked down. What happened? Before you started using AppLocker, SRPs were configured in such a way that allowed operating systems on all computers to function. When you created an AppLocker rule, all computers targeted by that policy and running Windows 7 Enterprise, Windows Server 2008 R2, or more recent versions of Windows became subject to the AppLocker policy and started ignoring any existing SRPs. Consequently, the SRP rules that kept the operating systems running no longer applied. To correct the situation, you may first need to resolve the lockdown as described in the previous example. Once all computers have been unlocked, you should create additional AppLocker rules that duplicate the existing SRP rules and thus allow the operating systems to work properly. AppLocker is more flexible and, hence, more secure than SRPs. But if SRPs support all the restrictions that you need to enforce, you do not necessarily have to switch to AppLocker, and you can continue using SRPs.
Interested in Microsoft Certification? Try our practice exam demos.
