Technical Introduction to VMware Access Point for Secure Remote Access
In this post I will give an overview of Access Point, the new VMware virtual appliance introduced with VMware Horizon 6.2. I will describe the main features and then drill down a little into deployment, security, high availability (HA) and scalability.
What Is Access Point?
Access Point is a virtual appliance primarily designed to allow secure remote access to VMware end-user computing resources from authorized users connecting from the internet. Initially, Access Point provides this secure connectivity to desktops and applications that are either cloud-hosted through VMware Horizon Air or on-premises in a customer data center through View in Horizon 6. Access Point is also an integral part of the forthcoming Project Enzo.
A connection from a Horizon Client or browser on the internet, whether to on-premises or cloud-hosted end-user computing resources, presents a security challenge. An enterprise needs strong assurance of the identity of the user, and also needs to precisely control access to their entitled desktops and applications.
Figure 1: A Single Access-Point Appliance Deployed in a DMZ
For those of you who are familiar with View security server, Access Point in this first version provides very similar functionality.
Access Point virtual appliances are typically deployed in a network demilitarized zone (DMZ), and they ensure that all traffic entering the data center to desktop and application resources is traffic on behalf of a strongly authenticated user. Access Point virtual appliances also ensure that the traffic for an authenticated user can be directed only to desktop and application resources to which the user is actually entitled. This level of protection involves specific inspection of desktop protocols and coordination of potentially rapid changing policies and network addresses, and so on, to be able to accurately control access.
The main difference from View security server is that Access Point is implemented as a hardened, locked-down, preconfigured Linux-based virtual machine, as opposed to software running on a general-purpose Windows operating system. Access Point also scales differently; the restriction to pair it with a single View Connection Server has been removed. You can connect Access Point to an individual View Connection Server, or you can connect it through a load balancer in front of multiple View Connection Servers, giving improved high availability. It acts as an enforcing man-in-the-middle between Horizon Clients and backend View Connection Servers, and because deployment is so fast, it can rapidly scale up or down to meet the demands of fast-changing enterprises.
Is Access Point New?
Yes and no, Access Point is new, but not new! We actually released Access Point earlier this year to provide the same level of protection in Horizon Air for cloud-hosted desktops and applications. For on-premises View desktops and applications in Horizon 6, Access Point is new for Horizon 6.2. Some of the protocol security components used in Access Point are actually tried and tested components that have been widely deployed in View security server and that have evolved over many years. Other components represent a completely new architecture appropriate to a broader set of product requirements and for more dynamic end-user computing needs in a potentially fast-changing hybrid cloud environment.
How Is Access Point Deployed?
The short answer is that Access Point is deployed very quickly and very easily! Access Point is packaged in Open Virtualization Format (OVF) and is deployed onto a vSphere ESX or ESXi host as a pre-configured virtual appliance VM that is locked down and set up for production operation on first boot.
Figure 2: Deploying the Access Point OVF Template in vSphere Web Client with vCenter
As shown in Figure 2, a basic install, where settings can be specified in a deployment wizard, can be performed through the vSphere Web Client with vCenter using the Deploy OVF Template option and selecting the Access Point OVA virtual appliance image file. You are prompted for some basic settings such as its IP addresses, management interface passwords, and a forwarding URL, and Access Point is then set up. This method is useful if you just want to set up Access Point in an internal lab environment to test it.
A more advanced deployment can be scripted using OVF Tool, where additional settings can be applied, such as customized TLS version support, cipher suites, and External URL settings, and even a Certificate Authority (CA)-signed SSL/TLS server certificate can be installed as part of the initial deployment. This advanced deployment can be a long and complex command line, but the Access Point documentation describes each setting and gives a useful example. The scripted method with OVF Tool ensures that Access Point is “Ready for production use on first boot“. For Windows administrators, PowerShell can be used to deploy Access Point automatically. Refer to Using PowerShell to Deploy VMware Access Point for details of a sample script. Using a script which calls OVF Tool in this way is a fully supported method of deploying Access Point.
With either method, the deployment takes approximately a minute, depending on your hardware and storage performance. After Access Point is deployed and started, there is no additional administration needed.
One of the unique features of Access Point is the almost zero level of ongoing management required. All of its dynamic configuration settings and access-control security rules are automatically determined from the backend server systems, such as View Connection Server, so that it immediately adapts to changes in entitlement policies. Access Point does support a full management REST API for getting and setting static configuration values, but the general approach is to deploy it with all configurations applied at the outset. You deploy it, and apart from monitoring it, you just leave it alone.
Syslog-based monitoring is supported with Access Point. You can use any syslog environment to capture Access Point events, and full vRealize Log Insight integration is supported.
For production environment deployments, I would certainly recommend using the scripted, unattended deployment method using OVF Tool. This gives you a predictable and repeatable deployment for all Access Point virtual appliances and takes care of any advanced settings you need to specify. On first start-up, you then know it is fully configured, fully secured, and immediately ready to operate. The scripted deployment method also makes it easier to deploy upgraded images as they become available. The script can be re-used and altered to reference a newer Access Point OVA image. The original can be destroyed, and a newer replacement can be quickly deployed, and all the exact same settings will be applied.
How Does User Authentication Work?
User authentication is very similar to View security server. Supported user authentication methods in Access Point include
- Active Directory domain password
- Kiosk mode
- RSA SecurID two-factor
- RADIUS via a number of third party, two-factor security-vendor solutions
- Smart card, CAC, or PIV X.509 user certificates
These authentication methods are supported in combination with View Connection Server. There is no requirement for Access Point to communicate directly with Active Directory. This communication is proxied via the View Connection Server, which can directly access Active Directory.
After the user session has been authenticated according to the authentication policy, Access Point is then able to forward requests for entitlement information, and desktop and application launch requests, to View Connection Server. Access Point is also able to manage its desktop and application protocol handlers to allow them to forward only authorized protocol traffic.
Access Point handles smart card authentication itself. This includes options for Access Point to communicate with Online Certificate Status Protocol (OCSP) servers to check for X.509 certificate revocation, and so on. Note that the smart card support in this initial version of Access Point is provided as a technical preview only.
It is expected that in the future we will continue to expand the user authentication options supported. In part, this is because a common authentication component from VMware Identity Manager is built into Access Point as part of a unified authentication and identity strategy for all VMware products. This will result in additional future options to perform a wide variety of “edge authentication” methods within the DMZ and improved single sign-on integration with EUC solutions.
What About Scalability and High Availability?
One of the features of View and Horizon Air is that deployments can avoid any single points of failure. Access Point virtual appliances scale horizontally so that as traffic load requirements increase, you add more Access Point appliances behind a general-purpose load balancer. If an Access Point appliance goes down for any reason, the load balancer becomes aware of this through health monitoring and directs traffic to the other Access Point appliances. This response also serves to spread load across all available appliances.
Figure 3: Multiple Access Point Appliances Deployed Behind a Load Balancer
Access Point is also able to communicate with backend View Connection Servers via a load balancer, so if a View Connection Server is down for any reason, this does not reduce the capacity for desktop and application protocol handling within the DMZ.
Access Point supports roughly the same number of concurrent sessions as View security server does. This is up to 2,000 sessions. The actual number depends very much on the display traffic used by each user. If 2,000 sessions underperform, or place high resource demands on the appliance, then the load can be spread to approximately 1,000 sessions on each of two appliances, or even 500 sessions on each of four appliances. Because Access Point is quick and easy to deploy, you can increase or reduce the number of Access Point appliances according to demand and monitored use.
There really is no limit to the number of Access Point appliances that can be deployed because there is no communication between them, and they are therefore all independent of one another.
How Is This Different from a VPN?
If you choose to use a Virtual Private Network (VPN), View fully supports remote access to desktops and applications via a VPN. A VPN can certainly meet the requirement of ensuring that traffic into the internal network is forwarded only on behalf of a strongly authenticated user. In that respect, Access Point and a commercial-grade VPN are similar. There are some considerations, though, that should be pointed out.
- Access control management. Access Point applies access rules automatically. Access Point has the additional benefit that it recognizes not only the user’s entitlements, but also the addressing needed to connect internally, which can change quickly! To some extent, a VPN can do the same, because most VPNs allow an administrator to configure network connection rules for every user or group of users individually. At first, this works well with a VPN, but usually involves significant administrative effort to keep up with the required rules. Quite often this is too much for an administrator to manage, and either too many authorized resources end up blocked, or unauthorized resources end up being allowed. The easy response for a VPN administrator is to allow unchecked access to any resource on the internal network; authenticate to the VPN, and you have complete access to the corporate network as though you were on the internal network. This is easy for the administrator, but usually a concern for corporate security. Not all, but many, VPN administrators will adopt this low-cost operational approach.
- User interface. A VPN often requires that the end user first set up the VPN software and authenticate separately before launching the Horizon Client. This may be secure, but users do not like this extra step. Access Point does not alter the straightforward Horizon Client user interface at all, and eliminates the extra (VPN) step. The user launches the Horizon Client, and as long as the authentication is successful, they are into their View environment, and have precisely controlled access to their desktops and applications.
- Performance. Not all, but many, VPNs are implemented as SSL VPNs. These certainly meet security requirements and, with Transport Layer Security (TLS) enabled, are usually considered secure, but the underlying protocol with SSL/TLS is just TCP-based. With modern video-remoting protocols exploiting connectionless UDP-based transports, the performance benefits can be significantly eroded when forced over a TCP-based transport. This does not apply to all VPN technologies, as those that can also operate with DTLS or IPsec instead of SSL/TLS can work well with View desktop protocols. Access Point is specifically designed to maximize security and maximize performance. It does not have to be a compromise between the two. With Access Point, PCoIP, HTML access, and WebSocket protocols are secured without requiring additional encapsulation, and so Access Point gives the best possible user experience.
I am not saying that you should not use a VPN with View desktops and hosted applications, although with Access Point it is unnecessary. What I am saying is to make sure the administrative effort, the user experience for setup, and the desktop protocol performance are all considered before using VPN technology with View. The first concern about accurate access controls can be addressed by using VPN technology in combination with Access Point. The performance degradation with a VPN can be significantly reduced by using VPN technology that efficiently handles UDP. These are typically DTLS or IPsec-based instead of SSL/TLS-based.
Does Access Point Replace View Security Server?
No, Access Point does not yet replace View security server. View security server remains fully supported in Horizon 6 version 6.2. If you have deployed View security server in your on-premises View environment and are planning to upgrade to Horizon 6 version 6.2, you should probably continue to use View security server as before.
As I have mentioned earlier in this article, Access Point in this first version offers very similar functionality to View security server. What we do expect, though, is that with significant research and development investments in Access Point, we are rapidly developing improved capabilities, and this will eventually mean that View security server will probably be phased out or at least deprecated. Dates for this have certainly not yet been decided.
If you use View security server with smart card authentication, you must continue to use it, as Access Point support for smart card authentication is only a technical preview in this first version and should not be used in any production deployment.
For the Horizon Air use case with cloud-hosted desktops and applications, View security server cannot be used, and therefore Access Point must be used. It is built into Horizon Air, anyway.
For the non-smart-card use cases with View desktops in Horizon 6 version 6.2, you really have a choice as to whether to use Access Point, which is a hardened Linux-based virtual appliance, or View security server software on a Windows Server operating system, to address your remote-access needs.
Where Can I Get More Information About Access Point?
For more information, see Deploying and Configuring Access Point.
By Mark Benson, Senior Architect and Senior Staff Engineer, End-User-Computing CTO Office, VMware