VMware View 5.1 RADIUS Authentication Setup

VMware View 5.1 RADIUS Authentication Setup

Mark Benson - Senior View Architect - VMware End User Computing CTO Office

We have extended View to support RADIUS authentication as an option in our latest View release.

This short RADIUS Setup and Troubleshooting Tips video covers the basics. There is also a more in-depth video shown at the bottom of this article.

This RADIUS feature in View 5.1 will serve two main purposes:

  1. View 5.1 can immediately support a wide range of alternative two-factor token based authentication options.
  2. View 5.1 provides an open standard extension interface to allow third party solution providers to integrate advanced authentication extensions into View.

During the development of this feature, we worked with a number of two-factor authentication security vendors and many of them have produced specific setup guides for View 5.1. There are lots of security vendors that will support View 5.1 with RADIUS so you should contact them for specific setup information. I've listed some of them here.

The types of two-factor authentication we support are those that require username and passcode text entry in the View client. This is similar to the way SecurID authentication works where the user is required to enter their username and passcode (usually a PIN followed by a tokencode read from a hardware or software token). We will also support a specific RADIUS challenge/response that is often used in authentication solutions where the user first enters credentials in the View client and an SMS text message (or e-mail or other out-of-band mechanism) is then sent to the user’s cell phone with a code that is then entered in the View client to complete the authentication. This specific RADIUS Access-challenge from the RADIUS server should contain attribute 18 and 24.

In View 5.1, RADIUS authentication can be configured on each Connection Server in a similar way to how RSA SecurID is configured in this and earlier releases. It may be that RADIUS authentication is just needed for remote access users in which case just the externally facing Connection Servers would be configured for RADIUS.

This document describes the basic setup of View 5.1 Connection Server to support RADIUS authentication.

The minimum setup for View RADIUS authentication is a single View 5.1 Connection Server, a single RADIUS server and a single View Client as shown in the diagram below. A secondary RADIUS server, View Security Servers and replica Connection Servers are optional.

View+5.1+RADIUS+Diagram+1.png

  • Setup a RADIUS server or use an existing RADIUS server in your environment. Follow the vendor's specific configuration guide and make sure it is setup to allow RADIUS authentication from the View Connection Server. You'll need to note its hostname or IP address, the port number on which it is listening for RADIUS authentication (usually 1812), the Authentication Type (PAP, CHAP, MS-CHAPv1 or MS-CHAPv2)  and the shared secret.
  • From a Web browser, access View Administrator on the View 5.1 Connection Server using https://hostname/admin and log in.

View+5.1+RADIUS+Admin+Diagram+1.png

  • Under View Configuration > Servers > Connection Servers select the Connection Server and select Edit. Under Authentication > Advanced Authentication, set the 2-factor authentication option to RADIUS and under Authenticator select Create New Authenticator. [If the above screenshot is too small in your browser, click on it to make it readable].

View+5.1+RADIUS+Admin+Diagram+2.png

  • Where possible, obtain these settings from your security vendor. Complete the configuration for the RADIUS server and select Next.
  • If your RADIUS server doesn't support RADIUS Accounting or you are not sure, set the Accounting Port to 0.
  • If there is a secondary RADIUS server then complete the settings for the secondary server and select Finish.
  • If there are replica Connection Servers they can also be setup for RADIUS authentication and can re-use an existing RADIUS authenticator configuration.
  • Test this from any View Client. Clients with RADIUS support will show the appropriate token label in text prompts. Older View clients will still work, but will refer to RSA SecurID in text prompts. If possible, use a Windows View Client 5.1. At the View Client login prompt, the label in the text prompt will show the label configured in View for this authenticator.

View+5.1+RADIUS+Client+Diagram+1.png

Notes:

  1. After authenticating to RADIUS, you may get another prompt if the RADIUS server responded with a supported Access Challenge. Full generic RADIUS challenge/response is not supported, but a limited access challenge for a string token code is supported.
  2. In the admin configuration of RADIUS authentication under Advanced Authentication, if Enforce 2-factor and Windows user name matching is ticked then the Windows login prompt after RADIUS authentication will force the username to be the same as the RADIUS username and the user will not be able to modify this. This feature is the same as is done for RSA SecurID authentication.
  3. Similarly if Use same username and password for RADIUS and Windows authentication is ticked then the user will not be prompted for Windows credentials after RADIUS authentication if the RADIUS authentication used Windows username and password. This feature is used in cases where the initial RADIUS authentication uses Windows authentication which triggers an out-of-band transmission of a tokencode which is used as part of a RADIUS challenge. This then avoids the need for the user to re-enter the Windows username and password after RADIUS authentication. This feature will not work in Windows View clients older than 5.1.
  4. To disable RADIUS Accounting requests being sent from View, set Accounting port to 0. If your RADIUS server does not support accounting messages it will most likely ignore these and this will result in a delay in authentication while these messages are retried. Only set this port to a non zero value if you want to enable RADIUS accounting and if your RADIUS server supports it.
  5. If a Realm prefix string is specified for the authenticator, this will be put at the begining of the username when it is sent to the RADIUS server. If the username entered in the View Client is "jdoe" and a Realm prefix of "DOMAIN-A\" is specified then a username of "DOMAIN-A\jdoe" is sent to the RADIUS server. Similarly if a Realm suffixstring of "@mycorp.com" is specified instead then a username of "jdoe@mycorp.com" is sent to the RADIUS server.

For more information on this you can watch this 45 minute video which goes through the setup of RADIUS with View 5.1 in a lot more detail and also covers troubleshooting steps.

VMware View 5.1 RADIUS Authentication Setup from Mark Benson on Vimeo.

Comments

Hi Mark, great write-up and very clear and complete.

I have one design question, why is it not foreseen to specify a Radius authentication server on the Security servers ? Isn't it more logical to do the authentication as soon as possible when a user comes in from the Internet ?

Our VPN gateways are set up like that.

Now the Radius authentication has to come from the paired Connection servers, and those are located in another site. The Security server - Connection server connection runs over the company backbone from the site that hosts the DMZ to the site where the View servers run.

Luc

Thankyou for your comments Luc.

In View, Authentication is performed by the Connection Server. Some people do set up View to perform authentication in the DMZ by putting Connection Servers in the DMZ, but this does require that they can connect directly to authentication servers from the DMZ (RADIUS, AD, ...).

The more common approach is to have the Connection Servers in the green zone perform authentication so that DMZ components don't have to have access to authentication servers.

If you want to ensure that authentication is performed in the DMZ, then you can put the Connection Server in the DMZ and ensure that it has access to your authentication servers. You can still have the virtual desktops in the green zone.

Some peope also have a double DMZ where Security Servers are in an outer DMZ and the Connection Servers are in an inner DMZ.

If you want to follow up with a discussion on this, post a follow-up message on the discussion forum.

Thanks!

Is it possible to expose as to RADIUS what the View client's IP address is?

Not in View 5.1. You can send me a message directly if you want to follow up.

Mark

Hi Mark,

Thought I'd give Horizon View 5.3 a spin in my home lab with Azure Multi-Factor Authentication. (Previously Phonefactor). Set up is very similar but I have found that when i tick the box to use the same username and password for RADIUS and Windows authentication I first get my SMS which works correctly but this is followed on by a "General Authentication Failure" dialog in the view client. If I click OK, it passes me through to login with my windows credentials so i think the passing of credentials is failing somewhere. If I untick the box, I get prompted twice for AD credentials as expected and this works fine.

Thinking back, if I remember, phonefactor sent a PIN to enter in the old client whereas the Microsoft one I am currently testing requires me to reply with my PIN to a text.

Have you tried using Azure MFA yet with Horizon View? Would like to hear your thoughts.

John

Another simple option for MFA with RADIUS is with NetIQ's Adavanced Authentication Framework that supports a wide range of Multi-Factor Authentication options including, voice, sms, smartphone app, soft or hard tokens, USB key tokens like yubi keys, and much more.  Gives you lots of options beyond the traditional hard token.

Mark

I created a how to on SMS PASSCODE. Here the link for setting up SMS PASSCODE with VMware Horizon View:

http://www.ivobeerens.nl/2015/04/14/tested-sms-passcode-multi-factor-authentication-with-vmware-hori...

Latest version of TekRADIUS supports VMware View RADIUS two factor authentication. See https://www.kaplansoft.com/tekradius/Docs/VMware.pdf for more details.

Version history
Revision #:
1 of 1
Last update:
‎05-16-2012 06:35 AM
Updated by: