Apr 01
In Part 1 of Two Factor Authentication for vSphere – RSA SecurID, we configured RSA Authentication Manager to get it ready for adding the PSC as an Authentication Manager agent. In this post, we’ll configure the Platform Services Controller (PSC) itself by uploading the sdconf.rec file and running the appropriate CLI commands to enable RSA SecurID. We’ll also talk about other authentication options you can enable or disable as you see fit.
Apr 01
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 (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.
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.
What I tested with:
In the example I’ll be using, the PSC will have 3 Identity Sources configured
RSA Authentication Manager will also have Active Directory as an Identity Source. Active Directory will be the common Identity Source between VMware and RSA.
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!
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
Directory URL: ldaps://mgt-dc-1.demo.vmware.com
Directory User ID: CN=Administrator,CN=Users,DC=demo,DC=vmware,DC=com
Directory Password: password for the service account. In this example, the password for the Administrator@demo.vmware.com 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. administrator@vSphere.local and administrator@demo.vmware.com. 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 administrator@demo.vmware.com and I’m running it as an application on the desktop.
Note that administrator@demo.vmware.com 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)
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!
If you liked these posts, please let me know! If you have comments, please reply here, to @vspheresecurity or @mikefoley on Twitter or via email to mfoley@VMware.com
Nov 09
For the past week or so, in my copious spare time, I’ve been re-building my vLab at work. It’s a cobbled together menagerie of hardware that makes me wish I had a healthier budget so I could spend more time on learning and less on reconfiguring, scrounging and breaking out the baling wire and chewing gum. Dealing with old hardware is distracting and takes your mind off this things that are critical for success. This happened to me. I know plenty of friends in the vCommunity that also have dealt with this. (I hear your heads nodding)
One of the things I’m playing with in in the lab is configuring VMware vCloud Director 5.1 with vCenter 5.1’s SSO functionality. I’m finding that this is one of those times when you really should RTFM and plan ahead more. But that’s ok, I like diving in without docs because then I get to learn more by breaking things and then I have something to share.
In vSphere 5.1 there is a new feature called Single Sign On. With the new vCenter client now being web based, SSO now allows VMware to leverage industry standards like SAML so that an admin can log once to vCenter and be automatically signed on to other resources like vShield Manager and vCloud Director. There’s a great overview of VMware SSO from Justin King here. You can read more about troubleshooting SSO here.
With vCenter and the SSO components up and running I installed the vCloud virtual appliance OVA and proceeded to set up federation between vCenter and vCloud. You can read more about federation in the Wikipedia article, but in a nutshell, it’s a way of linking identities. So, mike@foo.com and mike@bar.com can be linked. A trust relationship is set up so that if I log in from foo.com and hit a web page that needs my bar.com identity I get logged in using my bar.com account without having to provide the credentials.
Back to my lab, when I tried to do this, I ran into some trouble. I kept getting the following error.
Long story short, I had screwed up. I hadn’t been as diligent as I should have been with setting up my systems. The distractions I mentioned earlier had come back to bite me. Having recently added a couple of disk-less ESXi servers, I didn’t finish configuring them. I hadn’t been leveraging NTP as much as I should. What I now had was a number of systems trying to talk to each other but not agreeing on the time. And with SAML, time is critical. You are issued a token and part of that token is a timestamp. If vCloud thinks it is 9pm and vCenter thinks it is 8pm, the token with a short lifetime will come back as already expired. Just what happened to me.
I fixed the problem by setting all the ESXi servers to pull from an NTP server. In addition I also set up my vCenter, SQL server and domain controller to pull from NTP. Just like DNS has become a critical infrastructure component that just needs to be there, NTP is now jumped to the “required” list. Valid, consistent time stamps across your datacenter are needed for the operation of your infrastructure. They are also critical for security in things like authentication and log analysis, especially when you are trying to correlate lots of information!
NTP is critical to other vCloud operations as well. My friend Chris Colotti called this out in this blog article.
If you haven’t set up your datacenter with NTP, now’s the time. Oh, and DNS too. It’s time to ditch the hosts files. (yes, there’s still plenty of people using them!!) Going forward, more and more of your datacenter are going to rely on these key components. Ensuring that you use them consistently will help a LOT in troubleshooting large and complex installations.
Thanks for reading!
mike
You must be logged in to post a comment.