Introduction
These days Desktop Virtualization is a hot topic. Many service providers, system integrators and other companies provide some way of Desktop Virtualization to their end-users. This can be done by providing a set of Remote Applications (RemoteApps) or full desktops on Virtual Desktop Infrastructure (VDI) or Remote Desktop Service (RDS) environment or even a mix of these technologies. When it comes to publishing a full desktop (whether it is VDI (Desktop Virtualization) of RDS (Session Virtualization) you would want to have a method to allow users to only run applications that you authorized them to. Although this is absolutely important for both VDI and RDS scenarios you can imagine that enforcing such a policy is especially important in a RDS environment as you are sharing servers with multiple users.
History
Before we dive into the most current technology available inside Windows Server 2008 R2, let’s quickly look at the previous version. Before Windows Server 2008 R2, you had Software Restriction Policies (SRP) available to you. SRP’s where implemented using Group Policy Objects (GPO). SRP’s would check every instance of software launched by a user and run in through the SRP set of policies. A SRP always consists of two parts, a security level and a set of rules. The security level defines the overall method from loosely to very strict (unrestricted, basic or disallowed). After defining this overall security level, you start to make exceptions on the rule to explicitly deny or allow certain applications to run. This can be based on a hash, path, certificate or network zone. That would make up your SRP. A good set of tools to make your Remote Desktop Services environment (or in fact Terminal Services, since this was before R2) more secure, but let’s look at what Windows Server 2008 R2 adds to this functionality.
Today
In Windows Server 2008 R2 (and Windows 7) AppLocker got introduced. AppLocker supersedes SRP and although SRP’s can still exists, you will most likely find yourself using AppLocker instead of SRP. In this chapter, we’ll see why.
- Scoping
A big advantage of AppLocker compares to SRP is the scoping you can perform on an AppLocker rule. In SRP, you could define an exception rule on your security level, but this exception would be applied to all users that would access that server. In almost every Remote Desktop Scenario you have different types (or sets) of users that you (or your customer) would (for different reasons) like different software restrictions to be applied on. With SRP, this was not possible. With AppLocker, you can assign a policy to an active directory security group and thus create different rules for different groups of users to be applied on a single Remote Desktop Session Host or farm. You can imagine that this gives you much more flexibility.
- Auditing
Another big improvement with AppLocker is the ability to audit your rules. With SRP there was no way to audit your rules. When SRP’s are applied, they are operational and enforced. Testing your SRP’s before bringing them into production was time-consuming task. You had apply your SRP’s in a test environment and have users perform that day to day tasks on that test environment to get a good feeling of the results. With AppLocker you have two options, you either have your rules enforced or audited. Selecting enforced of course means that the rules are applied and will actively start to deny users to access applications accordingly. When you select audit only as the policy, AppLocker will still run every launched application through the set of rules to define whether the users in question is allowed to run that application or not, but it will not actively deny access to that application. Instead, AppLocker will create an event in the event viewer for every application that is launched and will include in that event whether the application would have been allowed or denied. The event in the event viewer will look something like this
Event Id 8003: %SYSTEM32%\easteregg.exe was allowed to run but would have been prevented from running if the AppLocker policy were enforced.
Look for the events in the following location:
Application and Services logs \ Microsoft \ Windows \ AppLocker \ EXE and DLL
You can imagine that this option gives great flexibility as you can never predict that your AppLocker set of policies are 100% correct the first time you set them up. You can actually have some key users of a particular application test the rules by performing their day-to-day tasks on the Remote Desktop Session Host and collect and analyze the results taken from the event viewer.
- The publisher condition
In addition to being able to define rules based on the path of the application and the hash in SRP, AppLocker allows you to specify a publisher. A publisher rule allows you to create a rule based the publisher of the application. The nice thing about this is that such a rule can survive an application upgrade or application move to a different folder. While setting up the publisher rule using the wizard (the wizard itself is also new to AppLocker) you have 4 options so make the policy as strict as you like.
Publisher – This would cause the rule to allow all applications containing a specific publisher
Product name – This would cause the rule to allow all applications containing a specific product name
File Name – This would cause the rule to allow all applications containing a specific file name
File Version – This would cause the rule to allow all applications containing a specific file name
You don’t have to enter these values manually of course. You can select an application on the Remote Desktop Session host during the wizard, and the wizard will collect all the information from the executable. For example, selecting winword.exe within an installation of Office 2010 causes you to be presented with the values below.
Selecting these values will only allow a user to run the application if all of the properties match the specified values. If you would raise the bar one level up you would exclude the File Version and AppLocker will only check based on Publisher, Product name and file name. This way you can make your policy as strict as you would like. You also have the option to select custom values which would allow you to change the values itself according to your needs.
- Other improvements
Other (smaller improvements) are the fact that AppLocker organizes file formats into separate collections (executable, installer, script and dynamic-link library) to allow you to build multiple rules that together can result in more detailed restrictions. Furthermore, AppLocker also supports PowerShell, which improves the flexibility even more.
Conclusion
As you can see there many advantages in implementing AppLocker compared to Software Restriction Policies. I cannot think of any option that was possible with SRP that was deprecated in AppLocker, so the general word of advice, if you’re not using any method of restricting software on your RDS environment today, start using AppLocker today and make use of the auditing policies to see what AppLocker can do for you! If you’re still running SRP on Windows Server 2008 R2, take a look at the possibilities AppLocker could offer you on top of what you already do with SRP.
