Proper security structure for Single Sign on Server

Question

We are all used to how we design security structure for vCenter Server if you have had an existing VMware environment prior to 5.1.  Who should have administrative privileges in vCenter Server, what roles, permissions, and so on should be assigned to what users and groups - these questions have already been addressed in our current configuration.
Now Single Sign on introduces a significant new point of consideration for determining issues of access and authentication.
I'd like to get some ideas on how this should be handled.  For example, should previous VMware administrators by definition become Single Sign on Administrators? Should the administrators of the Active Directory domain now start to get involved with the Single Sign on Server?
For example, Single Sign on now forces VMware administrators to configure things like:
-Password Complexity Policy for SSO
-Password Expiration for SSO
-Lockout Policy
We already probably have these things tightly controlled in AD and locked down with group policy, but you can't apply group policy directly to an SSO server and make it receive a GPO from Active Directory.  (You can make the Windows OS that SSO is running on have a GPO applied, but it won't configure SSO itself, just the OS).
VMware admins are looking at a new set of questions relating to authentication and authorization.  Someone has to have written something or will be writing something to help us get the big picture of what is changing with SSO if anything and how we need to look at SSO from a security design and best practices.
Should we just make existing vCenter Server admins SSO admins or do we need to take a step back and reconsider?

Answer 1

Hello,
Actually, yes. SSO is fairly robust in 5.5. It has a few limitations around email of expired passwords, but that is mainly because some people do not use them. I use SSO to provide the usernames and passwords for all my VMware vCenter and related product service accounts. I.e. an account for vdp, Horizon, vCops, Log Insight, etc.  This is more about keeping systems segregated once more with no real need for AD for services. But AD via SSO is used by users.
Read the documentation, and determine how SSO fits into your current password policy and take a long hard look at your virtualization management environment. Is there a 1 service account per service talking directly to vCenter? If not, SSO can help you implement that. The key is to match its functionality to your security policy.
Best regards,
Edward L. Haletky
VMware Communities User Moderator, VMware vExpert 2009, 2010, 2011,2012,2013,2014
Author of the books 'VMWare ESX and ESXi in the Enterprise: Planning Deployment Virtualization Servers', Copyright 2011 Pearson Education. 'VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment', Copyright 2009 Pearson Education.
Virtualization and Cloud Security Analyst: The Virtualization Practice, LLC -- vSphere Upgrade Saga -- Virtualization Security Round Table Podcast