One of the first steps generally in setting up vCloud Automation Center or vRealize Automation would be to deploy the identity appliance, however you can also use an existing vSphere SSO implementation. In fact, VMware has gone so far as to publish a technical white paper on how to configure vSphere SSO for high availability for use with vCloud Automation, now I won’t be doing that just yet but know its possible.

Here is the support matrix for currently supported authentication providers for vCloud Automation Center 6.1, as you can see vSphere SSO 5.5 U2b, U1c and U1b are all certified and supported. A quick check on the vCenter server version (vSphere Web Client >> vCenter >> vCenter Servers >> vxprt-vc01; Version Information portlet) shows that the vCenter Server Appliance that was deployed is 5.5.0 build 2183111; cross reference on the VMware KB (1014508) shows that the build number correlates to vSphere 5.5 Update 2b - certified to work with vCloud Automation Center / vRealize Automation 6.1

Given we are running in a lab environment with limited resources, I am going to go ahead and use the vSphere SSO implementation bundled with the vCenter Server Appliance. If you would like more information on deploying the vCloud Automation Center / vRealize Automation Identity Appliance, check out Emad Younis’ post on his blog.

Whether or not to use your vSphere SSO implementation for production deployments would have several factors (if resource constraint is one of them please talk to your boss about why you’re deploying vRA in the first place). For enterprise deployments it may make sense to leverage an existing vSphere SSO deployment since your employees are likely to share a common Active Directory already. Yes it becomes a single point of failure for both vCenter and vCloud Automation Center / vRealize Automation (unless you deploy the HA solution referenced above), but if SSO for vSphere is down, or the identity appliance is down, you’re still not getting much done until that is restored. It may make sense to simplify support in that regard.

For organizations supporting external users, you may want to separate the authentication domains so they are not co-mingled, creating a separate security domain. Another reason may be politics - maybe one group manages vCenter and another vCloud - if that is the case, again please talk to your boss.

I’d love to hear some of your pros and cons for separate identity appliance or using vSphere SSO. Up next we’ll deploy the vCloud Automation Center / vRealize Automation appliance.

Related Posts

So you’ve got vCenter up and running and hosts added, it’s time to enable the cool things vCenter can do - namely vMotion, HA and DRS. I’ve gone back and forth on how I wanted to present vMotion and networking in the home lab. On one hand many existing deployments are likely running 1Gbps, though newer ones are likely to start with 10Gbps as prices have dropped. After a quick Twitter chat I decided to move forward as I would if I had 10Gbps networking and not have separate physical interfaces in my host for different traffic types.

In order to provide shared storage to my home lab, I am going to use a Synology DS1513+. In my lab I have my DS1513+ connected to a switch, which is connected to my home router, this allows me to use http://find.synology.com to start configuring my DS1513+.