Securing App-V Streaming with Secure RTSP

by [Published on 21 April 2010 / Last Updated on 21 April 2010]

Taking a look at why you should use secured RTSP protocol and how to configure it within your current App-V infrastructure.

Introduction

By default, Microsoft App-V (formerly known as Softricity or SoftGrid) uses the RTSP (Real Time Streaming Protocol) in order to stream the virtualized application to the App-V client. This protocol is using port 554 as default to set-up the connection, followed by the opening a random port between 1024 – 49151 between the server and the client.

The product allows for the possibility to use the RTSP protocol, which secures data sending with the RTSP protocol based on SSL certificates. In this article I’m going to discuss why you should use the secured RTSP protocol, followed by a look at how this is configured using a clean installation and how your current App-V infrastructure can be reconfigured in order to accommodate RTSPS.

Why using RTSPS?

Before implementing RTSPS you need to determine if you need the secure RTSP protocol in your environment. There can be several reasons, but the most common are:

  • To secure the data streamed - Although the data within the stream is not critical or sensitive in very secure environments, it is now allowed to send any data unencrypted over the network. So if the organization has this requirement RTSPS can be used to secure the dataflow between the App-V server(s) and clients.
  • Firewall between App-V server(s) and clients - In scenarios where the App-server(s) and the client are separated by a firewall, there is a need to specify on which ports traffic is allowed. A firewall administrator would not (logically) allow for the opening of such a big range of ports. By using the RTSPS protocol only one port is necessary (by default 322), so such a request will be honored by the network department.
  • Using a hardware load balancer between the App-V servers and clients - By default App-V does not provide an option to combine more App-V servers together for larger deployment scenarios. To accomplish such a load balanced infrastructure you can use Microsoft Network Load Balancing (NLB) protocol or hardware load balancer. While NLB does not require RTSPS, with the hardware load balancer the story is bit different. Most Load Balancers need to be configured individually (per port), on which traffic should be forwarded to the actual servers. Therefore RTSPS can be used so only one port needs to be configured.

What’s needed for RTSPS?

The requirements in order to use RTSPS are actually pretty easy: you need to have a computer based certificate on your App-V servers. The certificate used has several requirements like:

  • Certificate must be valid
  • Certificate must contain the correct Enhanced Key Usage (EKU) - Server Authentication
  • Certificate FQDN must match the server on which it’s installed (when App-V is used with a Load Balancer, the certificate will have to be configured with Subject Alternate Names)
  • Client (and server) needs to trust root CA
  • Certificate Private Key has to have permissions changed to allow App-V Service account access to certificate

Most requirements are default certificate requirements that apply to most certificate scenarios. The last one is really important and differs from the default certificate requirements.

With those requirements in mind you need to determine if you will use third party certificates or use an internal PKI environment. Most scenarios have their advantages and disadvantages. Just like other certificate deployments it depends on the situation which option is the best one. Important is that the root CA is trusted by the client, so that you choose a valid third party organization or an internal CA that’s known by all your clients. Microsoft wrote a good document about these requirements and scenarios, specific for App-v, which can be found on the Microsoft’s website.

Preparing the App-V servers for RTSPS

Most steps for using RTSPS are based on implementing the certificate. I will not discuss the creation of the certificate, because this is done by the third party organization or the PKI administrator (in larger infrastructures). Remember that the certificate has several requirements, especially when using a certificate for a load balanced App-V infrastructure.

We will start with importing the certificate on the App-V server(s). This is accomplished by starting the Certificates MMC (most time this is not available within the administrative tools, so you need to start a MMC and add the certificates snap-in. It’s important to choose to manage computer account on the App-V server). It’s important to import the certificate in the personal store.


Figure 1: Using the import function with the certificates MMC to import the certificate

As described in the requirements paragraph the private key permissions need to be changed to allow the App-V service account to use the certificate. On Windows 2008 (R2) servers this is easily done using the certificated MMC, by choosing the certificate and within the right mouse button menu choosing the option Manage Private Keys and add in the following windows the App-V service account to read the private key.


Figure 2: Adding the App-V service account to the private keys

When your App-V server is running on Windows 2003 the procedure is different, because the snap-in does not have this permission. You need to have to use the winhttpcertcf utility available in the Windows 2003 resource kit. The command line to accomplish the same result as displayed in Figure 2 is “winhttpcertcfg -g -c LOCAL_MACHINE\My -s lbappv -a vanbragt\svc_appv.

In both cases I have used a specific service account, it is also possible to use the default Network Service account, logically you need to add that account in the same way as described (for example winhttpcertcfg -g -c LOCAL_MACHINE\My -s lbappv -a NetworkService).

Now the certificate is imported and ready to use by the App-V infrastructure. I will continue with describing the necessary steps for a fresh installation, followed by the steps required to reconfigure an existing infrastructure.

Using RTSPS with a Fresh Installation

Enabling RTSPS with a fresh install is actually easy, because you can choose the option during the default installation. Within the installation wizard you will get a question if you would like to use Security Mode. By checking the option and selecting the corresponding certificate you are enabling RTSPS and in the next Windows selecting the RTSPS port you are done.


Figure 3: Enabling RTSPS within a clean install.

Reconfiguring your current App-V infrastructure for using RTSPS

For infrastructures where you already installed the steps depends which deployment scenario you selected, full infrastructure or steaming only. With a full infrastructure you also have the management service deployed and you can use that console to reconfigure the configuration. To accomplish this you need to select the (all your) server(s) within the Server Groups. Open the properties of the server and select the tab Ports. Select the Server certificate and follow the wizard to select the certificate. When the certificate is selected you can change the RTSPS port for communication. After the configuration you need to restart the App-V service.


Figure 4: Reconfigure a full infrastructure to use RTSPS

When you have the streaming only scenario you do not have a management console, so you can make these changes within a graphical interface. First you need to determine the thumbprint information of the certificate. Again you need the certificates MMC for this. Double-click the certificate and within the details tab find the Thumbprint and copy the value.


Figure 5: Determine the value of the Thumbprint field

Next you need to browse the registry to HKLM\Software\Microsoft\SoftGrid\4.5\Distribution server. Within this key you will find the key X509CertHash. Change the data to the just copied thumbprint value (without any spaces).


Figure 6: Changing the registy setting for reconfiguring streaming only to use RTSPS

The next step is to go to the RtspsPorts. In here you need to create a new DWORD value 322 with a data of 322 decimal (or 142 hexadecimal). Actually, you are configuring which port will be used for the RTSPS traffic, so if you would like to set an alternate port you need to change the values to the corresponding port. Restart the App-V services and your infrastructure is supporting RTSPS traffic.

Client and Sequencing Changes

Now the back-end infrastructure is configured in order to use RTSPS. The clients should also be able to communicate using this protocol to the server(s). By default this is specified within the OSD file and configured using the App-V Sequencer on the deployment tab. If you already have existing packages you can change the OSD (via the Sequencer or other utilities). If you already have sequenced a lot of application this can be pretty time consuming. You can specify via the registry or with the App-V ADM template delivered by Microsoft to overwrite the settings specified within the OSD. See my previous article about configuration App-V using GPO policies for more information.


Figure 7: Changing the application source root path.

Conclusion

In this article I described why you would use the RTSPS protocol, what the requirements are, how to configure the App-V infrastructure (both a fresh install as existing environments) and what changes are needed to the client and/or the sequences.

The Author — Wilco van Bragt

Wilco van Bragt avatar

After working for a couple of consulting firms as a senior technical consultant and technical project leader Wilco started his own freelance company VanBragt.Net Consultancy in April 2008. Wilco is certified n Citrix (CCIA, CCEE/CCEA, CCA), Microsoft (MCITP, MCTS, MSCE, MSCA) and Prince2 (Foundation). Wilco is also a RSVP (RES Software Valued Professional), Citrix CTP (Citrix Technology Professional) and a Microsoft MVP (Most Valuable Professional) on RDS.

Latest Contributions

Advertisement

Featured Links