Note: This blog post is several years old, and while it serves as a reference we also encourage you to review the current product documentation for the most up-to-date instructions & methods for configuring this feature. Thank you!
Introduction
This is Part 1 of a 2 part blog series. In this post we’ll talk about setting up RSA SecurID Authentication Manager, some architectural assumptions and what you’ll need to take with you to Part 2.
Two Factor Authentication
Two factor authentication (2FA) has become ubiquitous nowadays. For those of you still in the Dark Ages where you have your password written on a Post-It Note stuck to the bottom of your keyboard, 2FA is “something you have”, like a hardware or software token and “something you know” which would be a secret PIN.
Personally, I have a very large number of logins that leverage 2FA. One is a RSA SecurID token issued by VMware. It’s a software-based token on my phone. Almost all the rest of my 2FA tokens are Google Authenticator tokens that are managed using my password manager application. 2FA has become an accepted form of better identity security. Username and password just isn’t good enough anymore so we’re doing something about it.
The is the first implementation of SecurID for vSphere so there are a few caveats and setup issues. These blog articles will help document them. I’m hoping that this is a popular option so we can devote more time and resources to making the setup and administrative process better going forward. YOU are a part of that. Your feedback is essential!
I’ve already been asked “Will this work with any kind of 2FA or just RSA SecurID?”. vCenter supports two types of 2FA in 6.0 Update 2. SecurID and Smartcard. For these blog articles, I’m just going over SecurID. SecurID is deployed across a huge cross section of VMware customers and was a natural first attempt at implementing 2FA for vCenter. Smartcard authentication will be discussed in a future blog article.
Architectural Assumptions
I can’t cover every single permutation of how you’ll want to configure your environment, so I’m going to stick with something simple that covers a large number of readers environments.
One Platform Services Controller (PSC) running 6.0 Update 2
The PSC is external. I have not tested this with an embedded PSC. I highly recommend moving to an external-based PSC topology. You can move from embedded to external really easily by following this great blog article from Ryan Johnson.
In the example I’ll be using, the PSC will have 3 Identity Sources configured
Local OS
SSO – vsphere.local
Active Directory – demo.vmware.com
RSA Authentication Manager will also have Active Directory as an Identity Source. Active Directory will be the common Identity Source between VMware and RSA.
Configure RSA Authentication Manager
Caveat: I won’t be going into detail on every single task. There’s a reasonable assumption that you know how to do tasks like assigning tokens and configuring “stuff” in AuthMan. Where I WILL go into detail is in anything specific to configuring vCenter/PSC with AuthMan. Great, let’s get started!
The first thing we’ll want to configure on AuthMan is the Identity Source. As mentioned, we’ll use a common identity source for both the PSC and Authman and that’s the Active Directory domain “demo.vmware.com”
After the Identity Source, we’ll want to configure the Authentication Agent. An Authentication Agent is the resource you want to protect, like a website, VPN or vCenter.
When I was setting up AuthMan I wanted to test to ensure everything was set up successfully. So, before I even touched the PSC I installed the RSA Agent for Microsoft IIS on a Windows Server VM and enabled SecurID on the default web site that IIS was hosting. After following the instructions in the RSA Agent for IIS docs, I successfully authenticated with SecurID. Great, now I know I have a working SecurID solution. Any future issues, if there are any, shouldn’t be because AuthMan isn’t working. Yay basic troubleshooting!
Identity Source
Before configuring the Identity Source, you need a digital certificate that secures the communication between AuthMan and AD via LDAPS.
There’s a great article that leads you step by step that I used to do this. Once you have your certificate installed you can now configure the Identity Source.
To configure the Identity Source, you’ll log into the RSA AuthMan Operations web interface and select Add New Identity Source.
Unlike the PSC where you can have Integrated Windows Authentication or LDAP authentication, AuthMan only works with LDAPS so you’ll need to know all your base DN’s and other information. In my example, I have the following settings:
Identity Source Name: mgt-dc-1.demo.VMware.com
I used the name of my domain controller but you can use another more descriptive name if you’d like
You’ll need to remember it later on in the setup when we configure the PSC.
Directory URL: ldaps://mgt-dc-1.demo.vmware.com Directory User ID:CN=Administrator,CN=Users,DC=demo,DC=vmware,DC=com
You may want to create a service account on your domain for this function.
Always think of “least privilege”!!
Directory Password: password for the service account. In this example, the password for the [email protected] account
Click on Test Connection to see if it succeeds.
Now click on the Map tab before clicking on Save. You need to change some things there.
User Base DN and User Group DN have a value of: CN=Users,DC=demo,DC=vmware,DC=com User ID: This needs to be changed from sAMAccountName to userPrincipalName.
Why change to UPN? Because this will help the PSC to differentiate between between the two Identity Sources. If they both have users with the same name, they won’t be unique. e.g. [email protected] and [email protected]. The PSC needs to know which Identity Store to authenticate against and using a UPN facilitates that.
All other setting should be fine. Go ahead and click on Save. The Identity Source should be configured and you can now assign a token to an AD user. In my case, I have assigned a software token to [email protected] and I’m running it as an application on the desktop.
Note that [email protected] may not have had a default userPrincipalName set up. I went into ADSI Edit and fixed that. Subsequent users all had UPN’s.
Caveat: RSA Authentication Manager does not support the use of multi-byte usernames. This is clearly called out in the RSA Authentication Manager Adminstrators guide (Page 126 in the 8.1 documentation)
Authentication Agent
Now that we have our Identity Sources all configured and RSA and VMware are drinking from the same user pool, it’s time to create the Authentication Agent. In the Security Console of AuthMan, select Access>Authentication Agents>Add New>
You’ll be presented with the New Authentication Agent form. The important value to add here is the FQDN of the resource you are protecting, in this case the PSC. For my demo, I added mgt-psc-01.demo.VMware.com.
Note that if you have more than one PSC, you’ll need to add an Authentication Agent for each one in your environment. This ensures that whatever PSC your vCenter hits will be able to service the SecurID login. The Hostname used will be the name of the Authentication Agent. You’ll need this information later when configuring the PSC.
Just add the Hostname and click on Resolve IP and then Save. The PSC will be configured as a “Standard Agent”, not a Web Agent.
Now that we have the Agent configured in AuthMan, we have to generate an Configuration File. This file, sdconf.rec, will be uploaded to the PSC and is used in the configuration of the SecurID bits on the PSC. The file is a binary that contains information about the Authentication Manager configuration. Generate the Configuration file in the Security Console. Access>Authentication Agents>Generate Configuration File. Select the defaults and click the Generate button.
Unzip the zip file. We’re going to upload sdconf.rec to the PSC in the next blog post.
At this stage RSA Authentication Manager is ready for you to configure the PSC.
Stay tuned for Part 2 where we dive into that and RSA SecurID on your vCenter!
All other setting should be fine. Go ahead and click on Save. The Identity Source should be configured and you can now assign a token to an AD user. In my case, I have assigned a software token to [email protected] and I’m running it as an application on the desktop.
Now that we have the Agent configured in AuthMan, we have to generate an Configuration File. This file, sdconf.rec, will be uploaded to the PSC and is used in the configuration of the SecurID bits on the PSC. The file is a binary that contains information about the Authentication Manager configuration. Generate the Configuration file in the Security Console. Access>Authentication Agents>Generate Configuration File. Select the defaults and click the Generate button.
Unzip the zip file. We’re going to upload sdconf.rec to the PSC in the next blog post.
