2.7.2 AppLocker (part 2 by Val Bakh In our last month’s blog post on AppLocker we covered the basics. Let’s now look at some examples of AppLocker usage that can help you avoid unpleasant and unexpected situations.
Let’s say GPO1 is connected to an organizational unit (OU), which contains computers in your test lab. You create multiple AppLocker executable Rules in GPO1 without defining any enforcement settings. These rules work perfectly. Let’s say GPO2 is linked with the domain. You create another set AppLocker executable rules for GPO2 and choose the Audit only option. GPO1 is linked with the OU and has precedence over domain level GPO2, but the explicit Audit only setting in GPO2 prevails over the implicit configuration in GPO1. Your lab computers will be subject to both GPOs’ rules, but they will also be subject to the audit only mode. All relevant events and applications will be logged but not prevented from running. You can now explicitly enforce the rules of GPO1 by enabling the Configured option, and selecting the Enforce rules option to executable rules. The AppLocker configurations from both GPOs will be in conflict and GPO1 will win. All of the rules from both GPOs will now be enforced on the lab computers.
AppLocker configuration is made up of many layers. It can get confusing and complicated sometimes. Keep your AppLocker deployment plan simple. You can easily lock down your entire network if you are not careful. As an example, let’s say you create a single rule (it could even be an Allow rule) in a domain-level GPO. Then, you configure a policy to allow the Application Identity service start automatically. Next thing you know, all computers within the domain are unusable. How can you correct this mistake if everyone, including yourself, cannot log on to any computer within the domain? Safe Mode is a way to restart a domain controller. GPOs are disabled in Safe Mode and only the essential services are launched. You can then log in to the domain controller locally to disable the Application Identity service. After restarting the domain controller, you can create the default AppLocker rules and any additional custom rules necessary to allow the operating system to work properly. You can now restart all other computers to unlock them.
Another tricky situation is here. Let’s suppose that all clients computers on your network are running Windows XP, Windows Vista or Windows 7 Professional. According to the company’s IT security guidelines, users are prohibited from installing unauthorized software. This requirement is enforced by software restriction policies (SRPs). The company’s management decides that the client computers should be upgraded or migrated to Windows 7 Enterprise. The deployment is successfully completed. Windows 7 fully supports SRPs so the software restrictions do not cease to work. Your company then purchases a new app for one department. You deploy the application and set up an AppLocker rule to ensure that only authorized users can use the application. The entire domain is now locked down. What happened? Before AppLocker was introduced, SRPs were set up in a way that allowed all operating systems to function. All computers that were targeted by an AppLocker rule and were running Windows 7 Enterprise, Windows Server 2008 R2, and other Windows versions became subject to the AppLocker policies and began to ignore any existing SRPs. The SRP rules that maintained the operating systems were no longer in effect. You may need to first resolve the lockdown, as described in the previous example. Once all computers are turned off, you can restore normal operation.
