Integrating RSA SecurID with VMware Workspace Portal

When I’m working with any new product I look for bloggers who have used the product in similar ways. What I’m finding with the Workspace portal is that there is almost nothing out there. I will try to document a few of the things I have done and found so others can have some confidence that things work.

Today’s job was getting Workspace to use two factor authentication for user’s connecting over the Internet while accepting username and password for users on the internal network. To proof it out I built the solution using my lab. For authentication Workspace supports AD password, Kerberos and SecurID. At this stage (version 2.1) there is no RADIUS support although I imagine it is on the to-do list.

1. Setup SecurID

The first task was deploying an RSA SecurID 8.1 server. We got a two user trial with two physical tokens. The SecurID server ships as a virtual appliance, in OVF format for easy import into vSphere. Nothing too complicated here, 104GB of vmdk files. I have cut the appliance down to one vCPU but could not reduce the RAM below 4GB without the appliance failing to start it’s Java components.

Once the OVF is deployed you follow the usual SecurID setup process to import a license and token seeds. I setup my SecurID server to use my AD for user accounts, check the documentation on how to set that up. Then I assigned a token to my userID and used the self-service portal on the RSA appliance to set a PIN.

The Workspace server needs to be setup as a new Authentication Agent. I entered the internal hostname of my workplace server, workplace.d.local, and used the Resolve IP button to ensure the RSA appliance was working with DNS correctly.

Then I used the Generate Configuration File menu item to create a config file. This is a zip file containing the configuration file sdconf.rec which we need to upload to workspace.

Now we move to the Workspace side. The SecurID setup is done in the Connector configuration, point a web browser at your workspace server on HTTPS port 8443 and select Connector Services Admin. The Auth Adapters as shown below, at this stage your SecurIDldpAdapter will show as disabled, click the Edit link.

I found that I had to enter the IP address of my Workspace server for both the Connector Address and Agent IP Address. The help seemed to think that I’d enter the DNS name as the Connector Address however this always lead to the connector failing so I entered the IP and all was well.

Now your Workspace server is setup to use SecurID for authentication. One way to check that the RSA server has seen the workspace server is to check that they have agreed a shared secret. In the RSA admin portal find the list of Authentication Agents, click your workspace and select Manage Node Secret, the Node Secret Set should say Yes.

Now we need to tell workspace when to use SecurID and when to use passwords.

2. Setup Network Locations

Logon to the Workspace portal with your administrative account, this is the AD userID that is used to bind for directory sync. Then go to the Settings tab of the Administrative Console and select Network Ranges.

This is where we define what subnets represent which locations. The ALL RANGES network range needs to be left alone, I have found bad things happen when you edit this range. I simply added a network range representing the internal network in my lab.

You can add multiple IP address ranges to one network range, my internal lab network is just one small subnet.

I have had inconsistent results with the handling of the View Pods settings, currently it seems that the All Ranges values are always applied. This lead me to try changing the All Ranges  network range and finding bad things happened (yet another a redeploy of Workspace, good thing it’s a lab).

Once we have the network ranges defined we can set some policies about how authentication works for clients in each location. Now got to the Policies tab and click Edit next to the default_access_policy_set.

This policy set defaults to two policies, one for devices and one for web browsers. Both are set to use the ALL RANGES network range and use only username/password.

I added a policy called Internal using the network range called Internal, by leaving the Client Type as Any this policy covers both apps and browsers. This policy will be the lower security for connections to workspace from inside my network. I chose to have a long TTL (Time To Live) since these are trusted people in a trusted location.

Now I need to make the security more strict for people connecting from the Internet. This is done by increasing the Minimum Authentication Score. Each authentication method has a score, the defaults are:

Workspace will choose the lowest scoring authentication method that is equal or grater than the Minimum. So the default is satisfied with username / password, this is fine for the Internal network but for everywhere else we need the Minimum Authentication Score to be 3 so that users are asked for SecurID credentials. I changed both the device policy and web policy to require SecurID. Remember to click Apply when you have the right settings.

Also the rules are processed in order, top down. The new rule for Internal was at the bottom of the list when it was first applied. I dragged it to the top of the list, if it was at the bottom the device or web policy would have matched internal users and forced them to use SecurID. That could be a real problem if your administrator account didn’t have a SecurID token. That was another redeploy of Workspace, by this stage I can deploy and configure Workspace in about an hour. Here’s the final policy set:

I still use plain username and password from my lab network:

But I get to use SecurID to logon from the Internet:

One of the surprises is that I don’t get asked for my domain password when I login with SecurID, I’m taken straight to my application list. The good news is that when I launch a View desktop I do get asked for my AD password, if that didn’t happen then my View connection would fail (I did manage to make this happen at one point) as there are no AD credentials to do View SSO with. Happily now that I have the build right all the required authentication happens.

I’ve learnt a few other things along the way, so there should be a few more articles appearing over the coming weeks.

© 2015, Alastair. All rights reserved.