The Microsoft Platform: Locking down your 2008 R2 RDS Farm

When it comes to setting up a RDS environment in general (whether it being RemoteApps or a full blown desktop) locking down your RDS farm must always be on your priority list. Reading this you must be thinking; okay, point me to the “Locking down RDS Guide” and we’re done. Well, it isn’t that easy I’m afraid. The way you lock down your RDS environment highly depends on the customer wishes, the applications used and the way you want to scale security against user-experience.

As Brian Madden (Microsoft MVP on RDS) wrote;

“...Do users really need to be able to execute programs from their home drives, temporary Internet files, or the Outlook attachment cache folder? Of course not!”

And I couldn’t agree with him more. Locking down you RDS is all about denying users from everywhere they don’t need permissions. This can be done in multiple ways, directly editing NTFS permissions, using Software restriction policies or AppLocker. The last one is new to Windows Server 2008 R2. Whatever method you choose highly depends on your environment.

We can all agree that directly editing NTFS permission for this purpose is just a lot of work and very inflexible. Software Restriction Policies (SRP’s) which have been around for quite some time can further help you in this. I won’t go into much detail here, you can find all the info you need on setting this up here: http://technet.microsoft.com/en-us/library/bb457006.aspx. Basically, a SRP consists of a security level and one or more additional rules. The security levels describe the methods and are available here:

Along with Windows Server 2008 R2 (and Windows 7) came AppLocker, and this is where it gets interesting. AppLocker has similarities with SRP’s but it is in fact a completely new feature. So what are the advantages? Besides the advantages like AppLocker rules can survive version upgrades and location path changes because they can be based on digital signatures, AppLocker rules are wizard-driven, so they’re easy to set up, AppLocker has Windows PowerShell support via AppLocker cmdlets I really like the following new feature:

Then you make exceptions to these using the additional rules that are available here:

User (or computer) Configuration | Policies | Windows Settings | Security Settings | Software Restriction Policies

This is a very powerful feature. It can be used to help you determine what the real affect is of the rules that you build. Everyone who has worked with SRP’s or any other form of locking down has been in the situation where you think you build the SRP correctly but somehow are not 100% sure about the real outcome. In environments where you don’t have an OTAP available that reflects the production environment you are forced to trial and error. Furthermore, when it comes to designing and building a new environment audit-mode really comes in handy as well. You can have test users operate on the new environment locked down with AppLocker, have them do whatever need and check the log later to see whether you have made your polices to tight and you get a good glance on what applications are used. For a guide on how to configure this see; http://technet.microsoft.com/pt-pt/library/dd723693(WS.10).aspx

When AppLocker rule collections are configured to user Audit Only mode, actions that the rules would have affected (both allowed or denied) will be logged in the Event log of the machine in question. To give an example; if a user tries to access the application Freek-Willem.exe on a RDSH server where AppLocker has a rule that denies this (in audit mode), the following will be found in the eventlog:

Event Id 8003: %SYSTEM32%\Freek-Willem.EXE was allowed to run but would have been prevented from running if the AppLocker policy were enforced.

To make it complete this is the list of events that you can expect:

Also, only using RemoteApp and no full desktop is not the same as locking down! This has to do with the way RemoteApp works. Although when a user gets presented a RemoteApp it might seem that it’s just an application, it’s still a session that has the same access to the environment that an application on a full desktop would have.

Nice quote from the RDS 2008 R2 Resource toolkit regarding locking down a RDS environment: J

“…We’re Star Wars enthusiasts. As Yoda might say, Ctrl+Alt+End leads to the Task Manager. The Task Manager leads to Run. Run leads to suffering.…”

With that all in mind, keep locking down in your priority list, and configure it to the needs of the environment in question. Keep in mind though that this post doesn’t describe everything you must do, just some locking down you can do. A full lock down involves more than just AppLocker.

To conclude, here’s some extra info:

ü What’s new:

http://technet.microsoft.com/en-us/library/dd378941(WS.10).aspx

ü Technical Documentation:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=025cf2e8-b0ab-4419-b5bb-86ab2d5eca83&displaylang=en

ü AppLocker FAQ:

http://technet.microsoft.com/en-us/library/ee619725(WS.10).aspx

ü AppLocker Walk-through demo (5 min. video)

http://technet.microsoft.com/en-us/windows/dd320283.aspx