While the workaround below works well, I did find I ended up with couple other problems with AD user identification. Not sure if that’s another bug or not, but after the workaround, I was able to successfully log in to AD, so authentication was working, the user ID was not properly identified somehow and some permissions and access levels were not recognized. The original issue of the default tenant not working is apparently a known issue and should be resolved in SP1.
My 2nd tip of the day is for when it comes time to configure your default tenant vsphere.local after you have set up your vCAC appliance and your IaaS services.
First, make sure you login as email@example.com. This is a bit annoying, as there still exists firstname.lastname@example.org, which is what was perfectly fine to use when you were setting up the vCAC/IaaS components, and even your domain credentials as they flow through the SSO server, but when you want to do something other than simply login and see a nice pretty empty page, use email@example.com.
Once you’re logged in with that account, you’ll select the vsphere.lcoal default tenant under the, you guessed it, Tenants section of the Administration menu. In order to use anything other than that default firstname.lastname@example.org account, you’ll need to set up your Identity Stores, and then add in the users/groups you want to grant the Tenant and the Infrastructure Administrator roles. After selecting the Identity Stores tab, this is where I first encountered a big System Exception yellow warning box, and had nothing in my list. You can close that warning and continue, but trying to manually add your domains, whether you select Native or regular Active Directory types, gave me a failure to successfully connect to the domain.
I found the only way to make this work for me was to go back to SSO, which happily accepted my domain credentials, and check the Identity Sources (Don’t you love consistency in naming?) under the Single Sign On Configuration section. The domain I was trying to add to vCAC’s tenant config was there, but it was configured as an ‘Active Directory (Integrated Windows Authentication)’ source type, as opposed to ‘Active Directory as a LDAP Server’. Now, I’m not quite sure why that made a difference, but I definitely noticed some type casting of identity object types being attempted in the vCAC app server error logs when I tried to set up my Identity Store, which technically should have been inherited from SSO. So, to move on, I removed the existing Identity Source from SSO, which should have been automatically added when you setup SSO initially, and replaced that Identity Source with a manual configuration of my domain as the secondary type I mentioned earlier. Once that was completed, logging back into vCAC and editing the vsphere.local default tenant’s Identity Stores tab, I noticed the two domains I had configured in SSO magically appear. Further, I could go into the Administrators tab, and the search correctly searched my Stores for the user or group I was typing in.
I made sure to go back and test that fix by removing my now working Identity Source in SSO, and replacing it with the original Integrated version, and vCAC now showed the Identity Store, but trying to configure/edit those settings in the Identity Stores section yielded blank fields, and trying to add users/group in the Administrators tab yielded no results.
So, for my purposes, I will keep my ‘Active Directory as a LDAP Server’ Identity Source type in SSO, so I can correctly work with my AD Identity Store in vCAC.