You are in the VMware company grocery store where each isle displays a VMware product, shelves fully and neatly stocked with product. You wonder over to the isle labeled ‘SSO 5.1’. To your horror you see a huge mess: SSL certs lying all over the floor, incorrectly configured OUs values, dazed and confused vSphere architects, JDBC connectors missing their SSL wrappers, and an angry mob of customers with a wide assortment of frightening medieval weapons.
You quickly find the store manager, Pat, and tell him “Cleanup on isle 5.1 needed, ASAP.” Magically a person named Justin appears wearing protective gear, a vSphere 5.5 shirt, and asks in British accent, “How may I help you?” You walk over to the mayhem on isle 5.1. Justin pulls out a VMware branded Harry Potter magic wand, and says a proper English incantation. Instantly you are transported one year into the future, the isle is restored to order, customers are cheering and the architects are building vast vSphere 5.5 empires. You suddenly wake up in night sweats and wonder…was that a dream or reality?
The New Reality
Since the SSO service was the center of attention this past year this blog post will highlight some of the issues with 5.1, and how VMware has addressed them in 5.5. The dream sequence above is not too far off from reality….SSO is all new, and dramatically improved. I think this is important to understand, which is why I’m including it the installation series. Think of it as required reading prior to starting the install process.
SQL 2012 AlwaysOn Failover Cluster for vCenter
vSphere 5.5 Install Pt. 1: Introduction
vSphere 5.5 Install Pt. 2: SSO 5.5 Reborn
vSphere 5.5 Install Pt. 3: vCenter Upgrade Best Practices and Tips
vSphere 5.5 Install Pt. 4: ESXi Upgrade Best Practices and Tips
vSphere 5.5 Install Pt. 5: SSL Deep Dive
vSphere 5.5 Install Pt. 6: SSL Certificate Template
vSphere 5.5 Install Pt. 7: Install SSO
vSphere 5.5 Install Pt. 8: Online SSL Minting
vSphere 5.5 Install Pt. 9: Offline SSL Minting
vSphere 5.5 Install Pt. 10: Update SSO Certificate
vSphere 5.5 Install Pt. 11: Install Web Client
vSphere 5.5 Install Pt. 12: Configure SSO
vSphere 5.5 Install Pt. 13: Install Inventory Service
vSphere 5.5 Install Pt. 14: Create Databases
vSphere 5.5 Install Pt. 15: Install vCenter
vSphere 5.5 Install Pt. 16: vCenter SSL
vSphere 5.5 Install Pt. 17: Install VUM
vSphere 5.5 Install Pt. 18: VUM SSL
vSphere 5.5 Install Pt. 19: ESXi SSL Certificate
What is the SSO service?
vSphere 5.1 introduced the SSO service, and it wasn’t just because VMware wanted to write more code and complicate our lives. In fact, it was designed to simplify life and provide common authentication services to the vSphere platform. It NOT a replacement for existing single-sign-on products, and is only for VMware products. The vCenter SSO service creates an authentication domain where users are trusted to access available resources. You no longer directly log into the vCenter service, rather the SSO service first authenticates you. Some products like SRM and vCOPS don’t utilize SSO today, but will in 2014.
Challenges with vSphere 5.1 SSO include:
- Did not work effectively in multi-forest/trusted domain environments
- Did not scale well in environments with more than 15,000 users
- Limited administration
- Database complexity and insecurity (lack of SQL SSL support, used SQL authentication)
- Extraordinary complex SSL certificate replacement process (no tool at GA)
- Difficult to change and update
- No clear VMware deployment architecture guidance
- Non-existent diagnostics
vSphere 5.5 SSO Rays of Sunshine
This is not a What’s new in vSphere 5.5 post, but I will focus on one key improvement that is fundamental to the installation experience in vSphere 5.5. The infamous (OEM’d RSA) SSO service was given the boot and VMware wrote a brand new SSO service from scratch. Yes, SSO is still required, but its been fundamentally re-architected. Changes include:
- No longer requires an external database, such as SQL server
- Built-in multi-master replication for simplified deployments (no scripting required)
- Greatly enhanced Active Directory support (no longer treats AD as a simple LDAP server)
- Fully supports multiple forests and two-way trusts
- Site awareness – Only supports grouping of objects (e.g. production and DR sites) in this release…exciting roadmap though
- One deployment model (very different from vSphere 5.1)
- Full suite of MMC snap-in management and diagnostics tools
- Backwards compatible with vSphere 5.1 (important for upgrades)
- Simple install vCenter scales up to 1,000 hosts and 10,000 VMs
- SSO scale is not limited by hosts/VMs, since AD lookups are offloaded to AD
So yes, VMware listened to customer feedback and really went back to the (much needed) drawing board. The real proof in the pudding will be testing it in the real world and see how many “features” (aka bugs) crop up. I was recently quoted in a TechTarget article regarding some early issues found with vSphere 5.5. KB article on the issue is here.
SSO Design Considerations
- Your DNS infrastructure must be rock solid and fully functional. vCenter relies on Kerberos and the easiest way to break it is by bad or non-existent DNS. This is an enterprise solution, so make sure DNS is enterprise grade.
- Must use Windows Server 2008 x64 SP2 or later (WS 2012 IS supported WS2012 R2 is NOT)
- If natively authenticating Windows users the vCenter/SSO server(s) must be a member of the same AD domain
- Make sure you set your vCenter administrator as email@example.com, NOT a local OS account
- Locate all vCenter services, including SSO, in a single VM
- Do not install multiple SSO servers in a single site, or attempt to load balance multiple servers
- If you have multiple vCenter servers around the world, install a local SSO server in the same authentication domain as all other vCenters
- See “Monster Deployments” below if you have a dozen or more of vCenters
There’s a nuance to “native” Active Directory support and treating AD as a simple LDAP server. SSO 5.5 only supports a single “native” Active directory domain, the one the SSO server is in. Native support is new to SSO 5.5, and addresses the complex AD topology limits in 5.1, and other related issues. Treating AD as an LDAP server brings with it all the issues of SSO 5.1, so that is not recommended. So yes a SSO server could technically use multiple AD domains/forests for authentication, but only one of them will enjoy full native capability.
- Native Active Directory (STRONGLY recommended) – Only one native source allowed
- Active Directory as an LDAP server (for 5.1 backwards compatibility and NOT recommended) – Multiple sources allowed
- Local operating system accounts (NOT recommended)
- Single sign-on users (replicated)
Here’s a screenshot from the Web Client Identity Source configuration screen:
- Automatic replication between each SSO server in the same vSphere authentication domain
- MMC snap-in allows you to review/add/remove/edit replication partners
- Supports geographically separated SSO sites, and the ability to setup bridgehead servers
- Each site is independent (no authentication failover)
- Does not provide a single pane of glass view
- Replicates SSO users and groups, SSO policies, identity sources
- Site awareness but limited functionality in 5.5 (big futures on the roadmap)
For service providers or monster corporations that have dozens or even 100 vCenter instaces (yes they DO exist), having 100 SSO servers all replicating is probably not ideal. For the limited use case of 6 or more vCenters connected via high speed LAN/MAN, VMware would like you to consider a dedicated SSO VM with a local web client install. All of the vCenter instances then leverage this centralized SSO service, reducing complexity and replication traffic. They hinted that on the road map are big changes to this architecture in the future, so it will be fun to see what 6.0 holds for us next year.
This architecture is NOT for a globally distributed company where vCenters are scattered all over the world. You should have local SSO servers, but they should all be a part of the same authentication domain.
If you run vCenter as a VM (recommended) you can use the usual data protection tools including snapshots, and backup to disk and tape. VMware vDP now supports restoring directly to an ESXi host, so you could recover a vCenter VM. Like Active Directory, which is also features multi-master replication, you have to be very careful about restores.
Prior to vSphere 5.1 in combination with Windows Server 2012, USN rollback (which is extremely bad), can occur in AD if a snapshot is reverted or improper VM restore methodology was used. SSO 5.5 does not support the hypervisor GenerationID feature that Windows Server 2012 uses to protect against AD USN rollback problems. So in an environment with multiple replicating SSO 5.5 servers, you must be careful and ensure database integrity. Should you have an ‘oopsie’ moment and cause a SSO “USN rollback” like issue, the SSO database can be zeroed out and re-replicated.
The SSO service is here to stay, and it’s unavoidable if you are using vSphere 5.1 and later. VMware saw the customer pitchforks coming their way and addressed head on the major issues people had with 5.1. SSL certificates, covered in depth in an upcoming post. They are still complex and didn’t undergo major implementation changes (still need seven certs, etc.). But VMware has dramatically refined the tools (such as adding the SSO MMC snap-in), released the vCenter Certificate automation tool at GA time, and now their documentation actually matches the GA’d code. Even though much of the complexity is still there under the covers, it’s a very different world in terms of tools and documentation, which is huge.
Now that you’ve gotten a little background on the all new SSO service, I hope you are excited to see the new and improved version in action. Next up? In Part 3 learn about vCenter 5.5 upgrade best practices and tips.