Anilrgowda

How access to your applications can be secured within a Terminal Server infrastructure.

Introduction

On a Terminal Server many applications are installed on a single server. Probably there are more applications available on the server then a single user needs to have access to. Because of license issues and confidential data companies would like to guarantee that users only use the applications they need for their daily work. In this article I would like to describe how access to your applications can be secured within a Terminal Server infrastructure.
Not Necessary when using Published Applications

Because I’m using Published Applications in my environment securing access to the applications is not necessary. Users can only start the Published Applications when they are granted access to that Published Application. Of course assigning users or (even better) groups to the Published Application is the first step to securing access to your applications, but it is not enough to guarantee that the users cannot start other applications. Lots of applications have some kind of back-door which makes it possible to start other applications. Of course when using Published Applications not all suggestions are needed, but you should certainly add more security than only the access option within the Published Application properties.
Hiding the server drives

The first logical step is to hide the server driver from the end user. Although this setting is one of the primary steps there are still a lot of Terminal Servers farms where users can see the drivers within their explorer. The best way to accomplish this is via Group Policy Objects. Within User Configuration – Administrative Templates – Windows Components – Windows Explorer two settings can be found called Hide these specified drives in My Computer and Prevent access to drives from My Computer. Within the default configuration of these two settings you can hide all drives and several local drives with the drive letters A through D.

f your server has remapped drives you should create your own customized ADM template. Below you will see an example of how to create this custom ADM template. Hiding is done via a numeric value. So if you would like to create the template with your own specified drives this value should be calculated as described in the article Freeware tools for the Terminal Server infrastructure Part 2.

POLICY "Hide these specified drives in My Computer" #if VERSION >= 3 EXPLAIN "Hide these specified drives in My Computer_Help" #endif PART "Pick one of the following combinations" DROPDOWNLIST VALUENAME "NoDrives" REQUIRED NOSORT ITEMLIST NAME "Restrict M,N and O drives only" VALUE NUMERIC 28672 NAME "Restrict Q,R and S drives only" VALUE NUMERIC 458752 END ITEMLIST END PART END POLICY ; Hide these specified drives in My Computer

Figure 2: Custom ADM Template for hiding drives NTFS Rights

With the hide drive option enabled users cannot browse to the executables but there are still several ways of starting an application. The most effective way of preventing this behavior is to secure access to the applications with NTFS Rights.
This can be done on folder or file level. I normally use only file level security, just in case an application has a shared DLL (especially for applications with more programs in one folder) with another application. In the executable remove the authenticated users group and add a group where the users, which are allowed to start the application, are specified.

Figure 3: NTFS Rights on Adobe Acrobat Reader 7
Of course adding these settings manually is not the best way of keeping your servers equal (as described in Terminal Server Environments). So when creating a application package you should also add a script line which changes the default security rights.
With xcacls this can be scripted very easily. For example to accomplish Figure 3 the syntax would be:
xcacls <> /C /Y /G "System":F "Administrators":F “VANBRAGT\APPL_LG_AdobeReader7”:rx.
More information about XCACLS can be found at the Microsoft Support site.
This security permission option allows access to your applications by authorized users only. However you should also prevent users from seeing the applications if they are not authorized for those applications.
Creating a personalized start menu

If you are offering a Full Desktop to your end users, you can create a personalized start menu for each user based on the assigned applications for each user. This can be accomplished with a simple folder structure and (again) NTFS rights.
On a file share create a structure based on how you would like the start menu to be visible to your end users. Add all application shortcuts to this structure. To prevent the shortcuts from pointing to one machine (link tracking) you can use the tool shortcut.exe to remove such information from the shortcut file. Shortcut.exe is a Microsoft Resource Kit tool and can be downloaded from here. During initial enrollment you could also use scut.exe which can use wildcards.
Next you should ensure that the structure is copied to the user session during logon. The best way to arrange this is to use a mandatory profile (or do not add the start menu in the roaming profile) with no application shortcuts in the start menu folder.
Using for example the logon script you should add a script line that copies the content of the newly created start menu structure to the user's profile.
To ensure that not all shortcuts are copied we are going to use NTFS rights and assign read permissions to the application group on the shortcuts. In our earlier example above we will give the read rights to group APPL_LG_AdobeReader7 to the Adobe Reader Shortcut. Of course everyone or authenticated groups should be removed from the security permissions. This way only the application shortcuts which users have access to are copied.
Because copying small files over the network is relatively slow, you can create a mechanism where the source is also locally available on the server. You can also create a script for every application that copies the shortcuts for that specific application.
Send To / Create New

There are several applications that add a shortcut to the Send To option and/or the new option within the explorer menu when you click your right mouse button. Logically only shortcuts in both menus should be shown for applications every user is allowed to use.
When packaging applications the creation of these shortcuts should be monitored. If unwanted, shortcut creation should be removed from the package. Send to shortcuts are saved in %userprofile%\Send To location. The new object shortcut is created through the [HKCR]\.\ShellNew key. By removing the ShellNew key the shortcut is not published anymore within the explorer menu.
File Associations

When using NTFS permissions users do not get any warning if they access one of the executables they do not have permission to access. So users can get a little bit confused when using file associations to open a file. My advice is to check your current file associations and if needed change associations to applications everyone is allowed to use. If changes are needed you should script the change of the file associations.
Software solutions

Several management products are available to prevent access to applications. Powerfuse, Appsense, Tricerat and Provision Framework allow the creation of a personal start menu per user and deny access to the local drives.
Also all of the above products can block unauthorized access to applications several ways. For more information about these products, see the reviews on my website.
Also Microsoft Software Restriction Policies can assign access to application executables.
Conclusion

For licensing reasons, confidential information, or abuse of applications , access to applications needs to be secured in such way that only assigned users can use the specific application. In this article I described how this can be arranged using NTFS permissions. Secondly we configured the user environment in such way that they also cannot see that application. Some software applications are mentioned which can also accomplish the same.