What’s New in vCloud Suite 5.5: vCenter Server SSO
VMware has announced its latest update to version 5.5 of its global virtualisation powerhouse, vCloud Suite.
To read the updates for all the suite components, see my post: What’s New in vCloud Suite 5.5: Introduction
vCenter SSO gets one of the major updates. This is welcome news to anyone who installed SSO in vSphere 5.1 which was plagued with an overly complex and restrictive design. SSO in 5.1 was apparently an OEM component which VMware customised. SSO in 5.5 has been completely rewritten from the ground up internally.
Evolving vCenter is a major undertaking as it was originally built as a monolithic platform with everything included in one place. VMware’s strategy is to pull out all the core central services from vCenter and have them run stand-alone.
In the future, vCenter may not in fact be the only management option. I can think of other future management options such as OpenStack or even Microsoft System Center or some other partner management ecosystem, all obviously at cloud scale. Today SSO has been re-built to scale serving vCloud Director, vCenter Orchestrator and Horizon View.
What’s New:
The whole architecture has been redesigned with a multi-master model with built-in replication both between and within sites. There are no longer primary and secondary SSO servers. Site awareness is part of the design, you can add new sites and SSO can be aware of the original site.
There is no more traditional database which makes things far simpler so you don’t have to worry about making an external database component highly available. The data is stored and replicated internally as part of SSO. This also means the manual installation task of setting up the database is no longer required.
Deployment
There is also now only one deployment model for all scenarios, you simply select one of the three options:
- vCenter Single Sign-On for first or only vCenter server
- vCenter Single Sign-On for an additional vCenter server in the same site
- vCenter Single Sign-On for an additional vCenter server in a new site (Multisite)
vCenter 5.5 SSO is really geared for multi-site SSO deployment. When you add additional SSO servers, there is automatic detection and federation of the SSO data. SSO users and groups are now automatically replicated so there is no need to export and import as with 5.1.
This federation means SSO now uses a single authentication domain, vsphere.local across all your SSO instances in multiple sites however each site acts as an independent entity compared to SSO in 5.1.
VMware strongly recommends upgrading to vSphere 5.5 SSO to take advantage of the new architecture.
They also recommend using a single VM for all vCenter Server core components (SSO, Web Client, Inventory Service and vCenter Server) or use the appliance rather than splitting things out which just add complexity and makes it harder to upgrade in the future. vCenter 5.5 on Windows supports up to 1,000 hosts and 10,000 VMs with many performance improvements in the database and overall system. The vCenter Appliance has also been beefed up and with its embedded Postgress database supports 500 hosts and 5000 VMs or with an external Oracle database supports the same as Windows.
There are still the the choices of a simple install as well as the custom install to segregate out the SSO install from vCenter if you really need to.
A full suite of diagnostic and troubleshooting tools has also now been included.
Identity Sources:
There are four identity sources supported with SSO 5.5
1. Native Active Directory
SSO now has a much improved AD authentication system with Kerberos based Integrated Windows Authentication. This is much more efficient than using native LDAP to connect to Active Directory especially when searching large directories which can be very slow. Something like 95% of all SSO installations authenticate using AD.
With Native Active Directory, your SSO instance joins AD as a computer account (there is an option to use a SPN) and then can use native AD search which is much quicker. This means you can now only have one AD domain as an identity source as you can’t be a member of multiple domains but it does mean you can authenticate with an AD account anywhere in the domain’s forest, a trusted forest or a trusted domain rather than setting up separate LDAP identity sources for every domain.
If you install SSO on a Windows Server and it is a member of a domain, the domain will automatically be added as an identity source.
If you deploy Active Directory, this really should be your identity source.
2. Active Directory as an LDAP Server
Active Directory as an LDAP Server is being kept as an identity source only for backward compatibility with 5.1 and is not likely do be supported post 5.5. You can treat your AD domain as an LDAP server as it’s a pretty complete LDAP implementation but this has limited functionality and searching can be slow . You can do simple LDAP connections and read users and groups but from a single domain only, so no forest or trusted domain support. You need to enter multiple LDAP identity sources for multiple domains.
3. OpenLDAP
This will be the only true LDAP option going forward allowing you to connect to many LDAP directories. If you do need to authenticate against separate AD domains that don’t trust each other you will have to add the secondary AD domains as LDAP identity sources.
4. LocalOS
This is used for vCenter on Windows using the SAM account database or using the /etc/passwd file on the vCenter Appliance.
Installation
As a prerequisites, the SSO Server hostname needs to have a FQDN and be DNS resolvable both forward and reverse. This is because the SSO server in most cases will be joined to Active Directory and so relies on DNS being available. This may cause issues for people who have used only IP addresses or had vCenter/SSO behind a NAT/segregated network zone.
The installer provides several core components for Single Sign-On installation and the installation steps have been dramatically simplified:
- Accept License agreement (EULA)
- Prerequisite check summary
- Edit default port number 7444 (if required)
- Select Deployment placement
- Provide Administrator@vsphere.local password
- Provide a site name or select a previous site name
- Edit destination directory (if required)
- Summary
- Installation Complete
Upgrade
When you upgrade from vCenter Single Sign-On 5.1 the old deployment models (Basic, High Availability, Multisite) are fully maintained. During the upgrade you can easily migrate to the new architecture.
If you are running SSO externally to your current vCenter, you can upgrade the SSO component to 5.5 and still have your 5.1 vCenter authenticate against SSO 5.5 although VMware recommends again to have everything on the same server.
When you configure your vCenter Server, make sure to set the vCenter Administrator as admin@vsphere.local which now replaces the previous 5.1 system authentication domain. Do NOT set the vCenter Administrator to be a Local OS account as this doesn’t federate.
When you upgrade vCenter SSO from 5.1 you can update your SSO connectivity to Native Active Directory and migrate the user permissions, roles, groups and certificates to the new architecture. The 5.1 SSO admin@System-Domain account will also be migrated to admin@vsphere.local and an alias created for admin@System-Domain for backward compatibility.
If you had multiple AD domains as identity sources, the primary domain based on your vCenter domain membership will be migrated to Native Active Directory and the others will be configured as LDAP. If any of your other AD domains are members of the same forest as the primary domain, you can go and remove them from the LDAP configuration as Native Active Directory has you covered.
Web Client single view
One of the things that you lose with the new SSO in 5.5 is the single view of multiple vCenter Servers within the Web Client when multiple vCenter Servers are linked to the same SSO server. To be able to view multiple vCenter Servers you will now need to have Linked Mode configured. This is an interesting move and I hope a temporary solution. Linked Mode is only available with a vCenter install on Windows as it runs Active Directory Application Mode (ADAM) which is a cut down AD implementation for its synchronisation so can’t be used with the vCenter Appliance. Linked mode replicates licenses, permissions and roles across multiple vCenter servers.
VMware’s strategic direction is to move everyone over to using the vCenter Appliance so requiring Linked Mode to view multiple vCenters in the Web Client is going to mean anyone with more than one vCenter isn’t going to be using the appliance, unfortunately perhaps a bit of an own goal from VMware for now.
Hopefully in the future the licenses and roles and permissions syncing can be pulled out of vCenter or done differently so any requirement for ADAM based Linked Mode isn’t required.
Availability
To make your SSO instance highly available you can still rely on vSphere HA for host recovery or use vCenter Heartbeat on Windows to protect your entire vCenter instance or any component.
Federation of data is not the same as HA. If you lose an SSO instance users within a site will not be able to use SSO in another site. This is one of the reasons VMware is recommending having all vCenter components together to not split availability.
vCenter is still not really designed from the ground up as a highly available federated management platform. I’m hoping the steps VMware is taking to at least simplify and fix SSO are a move in the right direction to deliver the management capability all the other components require.
vCloud Director, Horizon View, vCenter Operations, any other VDI broker, management/monitoring applications rely heavily on vCenter. I’m looking to a future when the critical parts of vCenter are automatically replicated and federated between multiple instances either within or across sites with a shared nothing architecture. This would allow vCD, View etc. to see what VMs are available and manage their power states.
All the rest of the non-critical stuff vCenter currently does can be pulled out. Performance data could go directly to vCOPS, events could be logged directly to say Log Insight. vCenter would be lean, replicating just the critical host and VM state information. vCD, Horizon View, etc., even ESXi hosts could be configured with say a primary and secondary vCenter (or another management application) to connect to and that would be it.
Recent Comments