Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

Securing Access to your Applications

Introduction

On a Terminal Server lots of applications are installed on one 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'm going to describe how access to your applications can be secured within a Terminal Server infrastructure.




No necessity 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 secure access to your applications, but it is not enough to guarantee that the users can not 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 then only the access option within the Published Application properties.

Hiding the server drives

The first logical step is to hide the server driver for 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. To hide the server drivers the best way to accomplish that is via Group Policy Objects. Within User Configuration - Administrative Templates - Windows Components - Windows Explore 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 tow settings you can hide all drives and several local drives with the drive letters A through D.

Image
Figure 1: Prevent Access to drives

If your server has remapped drives you should create your own customized ADM template.

Below you will see an example part 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 

NTSF Rights

Although with the hide drive option users can not browse to the executables but there are still several options to start an application. To prevent this behavior the most effective way 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 which more programs in one folder) with another application. On the executable remove the authenticated users group and add a group where the users are specified, which are allowed to start the application.

Image
Figure 3: NTFS Rights on Adobe Acrobat Reader 7

Of course adding these settings manually is not the right way to keep your server equal (as described in the Terminal Server Environments article) <<LINK to article>>.  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 easy. For example to accomplish figure three the syntax would be: xcacls <<executable>> /C /Y /G "System":F "Administrators":F  "VANBRAGT\APPL_LG_AdobeReader7":rx. More information about XCACLS can be found at Microsoft Support site.

With this security permission option access to your applications by authorized users is now accomplished. But you would also accomplish that users do not see the applications if they are not authorized for that application. In the next paragraphs I'm going to show you how you can arrange that easy and quickly.

Creating a personalized start menu

If you are offering a Full Desktop to your end users, you would like to create a start menu personalized for each users based on the assigned application to the user. This can be accomplished with a simple folder structure and (again) NTFS rights.

On a file share create a complete structure how you would like to show your start menu to your end users. Add all applications shortcuts to this structure. To prevent the shortcuts are 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 for example here. During initial enrollment you could also scut.exe which can use wildcards.

Next you should arrange that the structure should be copied to the user session during logon. Therefore the best to arrange this to use a mandatory profile (or do no 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 just created start menu structure to the user profile of the user.

To arrange that not all shortcuts are copied we are going to use NTFS rights. On the shortcuts we are assigning read permissions to the application group. 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. In this way only the shortcuts are copied of the applications the users have access to it.

Because copying small files over the network is relatively slow, you could create a mechanism where the source is also locally available on the server. Also you could create a script for every application that copies the shortcuts for that application only. By assigning the read permissions already on the script for the application group will also speed up the process a little.

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 these 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]\.<file association>\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 is they are accessing one of the executables they do not have access to. So users can get a little bit confused when using file associations to open a file. The 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.

Another way using software products

To prevent access to application also several management products are available to arrange (partly) this behavior. Powerfuse, Appsense, Tricerat and Provision Framework have possibilities to build up a personal start menu per user and deny access to the local drives.

Also all products can block unauthorized access to applications can be arranged in most of the products on several ways. For more information about these products, see the reviews at my website.

Also with Microsoft Software Restriction Policies assigning access to application executables can be arranged.

Conclusion

For licensing reasons, confidential information or abuse of applications it can be required that access to applications need to be secured in such way only assigned users can use the specific application. In this article I described how this simply can be arranged using NTFS permissions. Secondly we managed the user environment in such way they also can not see the availability of that application. In the last paragraph shortly some software applications are mentioned which can also arrange the same result.

Article previous published at MSTerminalServices.org.