Using AppLocker to lock down Remote Desktop Services apps
The time it takes to get AppLocker fully functional negates its benefits, but with Remote Desktop Services, the Windows 7 application security tool is a no-brainer.
Getting Microsoft's AppLocker fully functional is a labor-intensive task that overshadows the tool's benefits,...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
but AppLocker shines when it comes to locking down unapproved applications in Remote Desktop Services.
It's no surprise that many businesses haven't implemented the Windows 7 application security feature because even the smallest network supports dozens, if not hundreds, of apps spread across every desktop. Inventorying all of them into an AppLocker whitelist is a project whose sheer magnitude and costs might far exceed the benefits.
Exacerbating this potentially negative return on investment are AppLocker's own inventory tools. AppLocker can scan an individual machine to gather application characteristics and generate rules. But accomplishing that task across multiple machines requires careful orchestration of the Windows Application Identity Service with Event Log Forwarding. The problem is twofold: The service doesn't aggregate data into immediately usable reports, and implementing event log forwarding is far from a trivial task.
That's not to say that AppLocker isn't useful. Once you possess an inventory, mapping those applications into AppLocker policies is easy. When AppLocker is fully functional, it creates an environment of "approved execution," allowing only approved executables to run on targeted computers.
An operational AppLocker infrastructure bestows significant power to IT in enforcing the list of software that's allowed on the network. Everything else -- including the quasi-legitimate, illegal and unlicensed apps that you'd rather not manage -- is automatically rejected from execution.
So while AppLocker's capabilities are indeed beneficial, getting it to a fully operational state is a big adoption hurdle. But don't let AppLocker's limitations mask other use cases, particularly Remote Desktop Services (RDS).
AppLocker and RDS
If you've never taken a look at AppLocker's Group Policy configuration, navigate to "Computer Configuration | Policies | Windows Settings | Security Settings | Application Control Policies | AppLocker" in the Group Policy Management Editor. There, you'll find its four locations for configuring settings.
The root node here configures the enforcement settings for executables, Windows Installer files, scripts and even Dynamic Link Libraries (albeit with a strong warning that enforcing DLLs can affect system performance). Each category can be configured to enable enforcement or to simply audit user executions. The latter option merely monitors user behaviors without actually inhibiting them.
Right-clicking any of the three subnodes -- executable rules, Windows Installer rules or script rules -- brings up a list of options for creating approval rules. This is where AppLocker's scanning capabilities really stand out.
For many admins, the application set within RDS servers remains relatively static. We don't often add applications to those servers. When we do, they're typically added only after thorough testing and configuration management. Recall that AppLocker is equipped to scan a single machine to inventory-approved applications. Running this scan against your RDS servers means documenting the apps you've approved for users. Once the scan is complete, you can restrict specific applications and system executables (such as iexplore.exe or cmd.exe) by just removing those apps from the list of those approved.
To run a scan against executables, start by right-clicking "Executable Rules" and choose to automatically generate rules. In the resulting wizard, select the drives and folders that you want to scan. For an RDS server, scanning its entire drive ensures that every application is captured. The wizard's second screen defines the type of rules you want to create. File-hash rules allow or forbid execution based on a hash of each executable. That's useful, but painful when executables change because of patching or software updates. The more powerful publisher rules interrogate executables for their digital signature, a certificate that most legitimate software vendors use to validate their software.
An entire system scan takes only a few minutes and quickly results in the entire list of applications to allow or deny. At this point, you can specifically restrict the apps you don't want running on your RDS servers by adjusting their rules. The same holds true for Windows Installer files and scripts.
All of this functionality is designed to scale throughout your network wherever Group Policy is applied. However, it fits better in tightly controlled environments like those typically enjoyed by RDS servers.
So, if you find that your RDS-published desktops are being overrun by users running unapproved applications, consider AppLocker's environment of "approved execution" as your next lockdown step.
ABOUT THE AUTHOR:
Greg Shields, MCSE, is an independent author and consultant based in Denver with many years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent book, Windows Server 2008: What's New/What's Changed, is available from Sapien Press.