6.2

NOTE If Horizon Client is not configured to support any cipher that is supported by the virtual desktop
operating system, the TLS/SSL negotiation will fail and the client will be unable to connect.
For information on configuring supported cipher suites in Horizon Clients, refer to Horizon Client
documentation at https://www.vmware.com/support/viewclients/doc/viewclients_pubs.html.
Replacing the Default Self-Signed SSL Server Certificate
A self-signed SSL server certificate cannot give Horizon Client sufficient protection against threats of
tampering and eavesdropping. To protect your desktops from these threats, you must replace the generated
self-signed certificate.
When View Agent Direct-Connection Plug-In starts for the first time after installation, it automatically
generates a self-signed SSL server certificate and places it in the Windows Certificate Store. The SSL server
certificate is presented to Horizon Client during the SSL protocol negotiation to provide information to the
client about this desktop. This default self-signed SSL server certificate cannot give guarantees about this
desktop, unless it is replaced by a certificate signed by a Certificate Authority (CA) that is trusted by the
client and is fully validated by the Horizon Client certificate checks.
The procedure for storing this certificate in the Windows Certificate Store and the procedure for replacing it
with a proper CA signed certificate, are the same as those used for View Connection Server (version 5.1 or
later). See "Configuring SSL Certificates for View Servers," in the View Installation document for details on
this certificate replacement procedure.
Certificates with Subject Alternative Name (SAN) and wildcard certificates are supported.
NOTE To distribute the CA signed SSL Server Certificates to a large number of desktops using the View
Agent Direct-Connection Plug-In, use Active Directory Enrollment to distribute the certificates to each
virtual machine. For more information see: http://technet.microsoft.com/en-us/library/cc732625.aspx.
Authorizing Horizon Client to Access Desktops and Applications
The authorization mechanism that allows a user to access desktops and applications directly is controlled
within a local operating system group called View Agent Direct-Connection Users.
If a user is a member of this group, that user is authorized to connect to the virtual machine-based desktop,
an RDS desktop, or applications. When the plug-in is first installed, this local group is created and contains
the Authenticated Users group. Anyone who is successfully authenticated by the plug-in is authorized to
access the desktop or applications.
To restrict access to this desktop or RDS host, you can modify the membership of this group to specify a list
of users and user groups. These users can be local or domain users and user groups. If the user is not in this
group, the user gets a message after authentication saying that the user is not entitled to access this virtual
machine-based desktop or an RDS desktop and applications that are hosted on this RDS host.
Using Network Address Translation and Port Mapping
Network Address Translation (NAT) and port mapping configuration are required if Horizon Clients
connect to virtual machine-based desktops on different networks.
In the examples included here, you must configure external addressing information on the desktop so that
Horizon Client can use this information to connect to the desktop by using NAT or a port mapping device.
This URL is the same as the External URL and PCoIP External URL settings on View Connection Server and
security server.
When Horizon Client is on a different network and a NAT device is between Horizon Client and the
desktop running the plug-in, a NAT or port mapping configuration is required. For example, If there is a
firewall between the Horizon Client and the desktop the firewall is acting as a NAT or port mapping device.
Chapter 2 View Agent Direct-Connection Plug-In Advanced Configuration
VMware, Inc. 15