How to enable Single Sign On with vCenter Server Appliance

[#1]

This week I've been spending time restructuring my lab environment to be ready to prepare for the VCP-Cloud which tests peoples abilities on vCloud Director and associated technologies in the vCloud Suite. It's a been a pretty major undertaking because I wanted to change the way I manage vCenter (from multi-vCenter to single vCenter), organize my hosts and clusters, storage and networking too! I'm fortunate because my personal lab environment is relative modest affair compared to large environments - but its sizable on the "home lab" front, so much so it isn't at home but at a colocation facility not far from where I live.

I decide the time was ripe to move over to using the vCenter Server Appliance especially as it feature parity with the "installable" Windows edition (albeit there is no "linked mode" vCenter Server Appliance). I wanted to setup the appliance to support Active Directory with the new Single Sign On feature. When you first setup the appliance the only logon to it is "root" with the password of "vmware". From their you can use the new "Web Client" to manage how the appliance speaks to AD.

1. After login into the applianace (in my case https://vcnyc.corp.com:9443)

2. Navigate to >Administration > Single Sign On and Configuration

3. Click the  + symbol to add in "Identity Sources"

4. In the dialog box enable the radio button for "Active Directory" and then fill in the fields relative to your domain

5. Once the domain is in the "indentity sources" list, it can be added to the "Default Domains" list below

Note: The "LDAP" field can use the format of ldap://dc01nyc.corp.com:portnumber to express if you want a non-secure or secure connection to Active Directory.

Once the identity source is enabled your ready add in groups or users to allow user accounts in Active Directory to have access

1. Click at the Home button or Home Navigator

2. Select >vCenter >vCenter Servers

3. Select your vCenter the Inventory

4. Select the Permissions tab

5. The + button can be used to browse for the domain, add a group and assign a role

[Erik_Bussink]

Many thanks Mike for the intro to SSO with the vCSA. Didn't try that combo yet.

I also recommend that once you have added the new ldap entry for your domain, that you "Add to the Default Domains" the newly entered settings.

Adding more than one Active Directory to the Default Domains section (bottom part of the screen) can get your accounts locked if they overlap.

I've even started using the SSO Users and Groups to create the accounts for the Service Accounts for vCloud Directory, vShield Manager, Syslog Service, Dump Service, Update Manager etc...

[Michelle_Laveri]

It's interesting that you say that. I must admit I was expecting the default domains to refresh to show my "CORP" domain, and didn't realise that its best practise to add in there as well. I'm a bit unsure about using the SSO User & Groups for service accounts - won't folks want those in AD as they might for other products/technologies. Still well done in seeing what our technologies are capable of!

[TedH256]

Sigh - I'm going to have to learn this whole SSO thing, I guess! But I'm cloudy (pun intended) about just what exactly this thing is. Does this statement capture it:

"SSO is a service provided by VMware that allows us to add create accounts that can be used by all vmware products. It leverages AD or other LDAP sources, but creates it's own "account pool" that links SSO accounts to AD/LDAP accounts, so that you can create accounts (and give them access rights) that either do -- or do not -- live in the AD/LDAP source"

Is the above about right?

Where does SSO live? can it (must it?) live on the vCenter server? Does it require windows? Is it an appliance?

[Erik_Bussink]

The SSO Service does not need to live on the vCenter. It also dos not install on a Domain Controller. Because I did not using an SQL Express install for the SSO. I decided to install it on my Microsoft SQL VM that also hosts the vCenter database. My SQL already had proper maintenance plans in place, so the SSO database is now also backed up. So far I have seen that the SSO tomcat engine gobbles up about 1.4GB of RAM on start with few AD/LDAP connection. My SQL server has enough memory to take care of it. Also the SSO does take a while to start. my vCenter vApp starts the SQL Server prior to starting the vCenter VM, so the SSO will be started by the time the vCenter Server starts up.

There are no Best Practices for SSO that I have seen yet, so I'm making these judgement calls on my short (10 days) experience with SSO (multiple deployements already).

I also ran into issues, which I have not yet solved, in gettng the JDBC connectivity from SSO to point to an SQL Instanced database. Only got it to connect to a MSSQLSERVER (Default) instance.

If you manually create the database in MS SQL customize the two VMware-VIMSetup-all-5.1.0-799735\Single Sign On\DBScripts\SSOServer\schema\mssql files : rsaIMSLiteMSSQLSetupTablespaces.sql and rsaIMSLiteMSSQLSetupUsers.sql

#HowIStoppedWorryingAndLoveTheSSO