Video Content [TBA]
Introduction to the Security Server
Version: Horizon View 5.1
What is the Security Server?
Despite the fact that Connection Servers offer an encrypted, certificates-based SSL Tunnel from the client to the virtual desktop, they are not appropriate for being deployed to a DMZ. This is for two reasons:
• They are members of the corporate Active Directory Domain, and as such have domain privileges to a private network
• Ports are open to allow Active Directory communication which a hacker could utilize to facilitate other attacks
As an answer to the problem, VMware View has the Security Server role – it can be left in a workgroup and does not require domain access. It only responds to 443 requests and allows the firewall administrator to only open (inbound) secure ports to the external firewall. As with installing a second Connection Server, installing a Security Server is very easy. It is possible to have more than one for availability, however, a Security Server has a relationship with only one Connection Server at any one time. As you might recall, there is no built-in load-balancing feature for either the Connection Server or Security Server from VMware, as such you will need some sort of third-party load balancing solution. View 4.6 marked a significant watershed for the Security Servers by VMware. Prior to this release customers needed to have a 3rd party VPN established to use PCoIP with Security Server. View 4.6 introduced a new “gateway” model that allowed PCoIP traffic to traverse the firewall and Security Server without a need for a VPN session to be established first. This greatly simplified the configuration of View for external Internet access, and should contribute greatly to increase adoption.
Before you consider deploying the Security Server you should really investigate the appliances that reside at the perimeter of your network. You may well find that your load-balancing and application delivery controllers are “VMware View Aware”, and can securely broker connections across your DMZ directly to the Connection Server. This can often eliminate the need for Security Servers in the DMZ.
The installation of the Security Server differs quite a bit from both a Connection Server and a Transfer Server. Firstly, during the installation you will be asked for a pairing password. This is a one-off session-based password that expires after a configurable period, and is used to ensure that Security Servers and Connection Servers properly trust each other. However, no SSL Key exchange or SHA thumbprints are used in this process, unlike when you add an ESX host into vCenter, for example. Having successfully completed this verification process, you will be asked to set the “External DNS” name of the Security Server. This is to mask the true identity of the Security Server. For example, my Security Server’s true FQDN is ss01.corp.com, but it will respond to the identity of view.corp.com. This external identity must be resolvable by public-facing DNS servers for it to work. Additionally, you will need to open the TCP/UDP ports used by PCoIP to allow inbound access.
Installing A Security Server
1. Start by creating a brand new Windows 2008 VM
IMPORTANT: DO NOT JOIN IT TO YOUR ACTIVE DIRECTORY DOMAIN
2. [Optionally] Add a second NIC to the VM, configure the first NIC to communicate to your internal firewall and the second NIC to communicate to your external firewall
This configuration assumes you will be using Microsoft NLB to do load-balancing, as this is generally best practice. However, if you not using Microsoft NLB then the Security Server only needs one NIC. If you are using a third-party load-balancer as would be the case in most enterprise environments - it is safe to skip this step.
3. Double click on the VMware-viewconnectionserver-N.N.N-NNNNNN.exe file
4. Accept the usual suspects of the Welcome Screen, EULA and the install path for the software
5. Select ’View Security Server’ from the list
6. After the installation completes, you will be asked to pair your Security Server to the Connection Server
Given the Security Server’s special role in the DMZ, you might find that internal name resolution fails for you. You can always use a host’s file for this purpose.
7. Once the software has been unpacked you will be prompted to type in the name of the Connection Server you will be pairing the Security
8. Next click the Commands button – and select Specify Security Server Pairing Password
9. In the corresponding dialog box – set your one-off pairing password – note the duration it takes before it expires!
This is a session-based password, and as such no complexity is enforced.
10. In the Connection Server password dialog box – type the password you set earlier
11. The final step is to set the External URL. This is the name that external clients will use to connect to the Security Server. Critically, it must be resolvable by your external DNS environment. This URL can be changed once the installation has been completed if needed.
The second field corresponds to the external IP address used by clients to connect to the Security Server. In our case this is a valid IP address for the Internet. An IP address must be entered here and not a name. This can cause problems for people wanting to use PCoIP for remote access to their home labs especially if your ISP leases you an IP address to your Wi-Fi router rather than a static IP address. A fellow vExpert, Gabrie Van Zanten has an interesting article that discusses how to use scripting to resolve this issue:
It’s also worth saying that this address can also be in the internal inbound IP address of your load-balancing system. The IP address we are using in the screen grab above is one that we will initially use with a Microsoft NLB Cluster. Later we will adjust this IP address to match our configuration of an F5 BIG-IP load-balancing system.
12. As with the Transfer Server, the Security Server is added to the View Configuration, Servers and Security Servers pane
From this location the edit button can be used to alter the external URL.
13. Despite this configuration – this on its own does NOT enable the “PCoIP Gateway” mode. This has to be manually enabled on the Connection Servers that have been paired with a Security Server. To enable this navigate to the View Configuration, Servers and View Connection Servers Pane then select the Connection Server, and click the Edit button. Below is a screen grab of what this dialog box looks like by default:
Notice how the external URL is the internal name, not the external one – and that the PCoIP external URL is still an internal not Internet address. Finally you can see the option to “Use PCoIP Secure Gateway for PCoIP connections to the desktop” has not been enabled. We need to change this configuration to make it all work together.
You can see in these dialog boxes that PCoIP listens on 4172. This is both TCP and UDP. So as such both TCP/UDP 4172 and 443 will need to be open for connections to work across a firewall. Remember the Security Server merely works as stateful NAT translator that brokers the client’s access to the desktop. PCoIP packets go directly from the Client to the virtual desktop and for this reason 4172 needs to be open on both the internal and external firewalls.
As with the Connection Server, after the installation you should be able to connect to the Security Server using the View Client. To do this you may need to re-configure your client for a valid IP address (in our case 80.81.82.x) and edit the “host” file on the client to allow the client to use the specified “External URL”. Of course in a production environment the client would be on the internet, and the URL would be resolved to a public DNS server.
Remember that as the Security Server is not joined to a Microsoft AD Domain there will be no automatic dynamic DNS update. As it is, the Security Servers are more likely to respond to external Internet IP addresses resolved by the public DNS system. If you wish to test the Security Server configuration you could use an IP address or a host’s file.
Secondary Security Servers are installed in exactly the same way, but two Security Servers are not allowed to be paired with one Connection Server. The pairing is a one-to-one relationship – one security server is paired with one connection server. In the case I have configured, ss01.corp.com is paired with cs01.corp.com and ss02.corp.com is paired with cs02.corp.com. As with the Security Server, having more than one Connection server is intended to deliver high availability to the environment, not fault tolerance. If a Security Server goes down or becomes unavailable, the user’s session to the virtual desktop will become disconnected. Additionally, this “PCoIP Gateway” mode blocks direct access to the Connection Server. If you do try to configure the View Client directly to Connection Server in “PCoIP Gateway” mode it will attempt to return the “external” address rather than its own internal address.
As you can see the configuration of a Security Server is incredibly simple. In fact one of the big selling points is the ease by which it can be configured and setup, compared to competing solutions. VMware does recommend that if you are working in a hybrid mode – where you have both inbound access from the Internet via the Security Server, and internal LAN based access via the Connection Server – that you configure dedicated servers to respond to internal and external. In this configuration you would have a group of Connection Servers with replicas (perhaps load-balanced) serving internal requests. The remaining Connection Servers would be paired to the Security Servers and made accessible to the external Internet users. Ideally, both environments should resolve to the same FQDN so users who move between both environments – as they work from home one day, and work from the office the next – only need to know a single URL for their vSphere Client.
Our next chapter concerns the use of SSL certificates to ensure that when users connect to the Security Servers the relationship is one where the end-user can rest assured that they are establishing a session with a fully trusted and recognizable system. As you have seen, View 5.0 introduces more rigorous requirements for certificates that are fully trusted and match the FQDN that users connect with. In previous releases organizations could “get away with” using the autogenerated certificates created during the installation. That’s no longer the case.
Previously we would have followed the chapter on Security Servers with a chapter on load-balancing. However, given that many load-balancers also need to handle secure SSL sessions as well, we decided it was best to deal with this issue of certificates first, so that when we setup a commercial load-balancer the certificate files would already prepared ready for its use.