Home > Blogs > VMware vSphere Blog


vCenter Single Sign-On – Part 2: Deployment Options

Now you understand what vCenter Single Sign-On (SSO) provides, as you start to design or upgrade to your vSphere 5.1 environment, particular attention needs to be given in the planning stages around the placement and configuration of the SSO server. This will always be the first component to be installed; regardless of fresh install or upgrading from a previous version. The SSO server can be deployed in a number of configurations and I will explain these options and too why you may use each option.

During the installation process you will be presented with the below screen which is a key decision on which deployment method of SSO you would like to deploy. It is very important that you have planned your SSO deployment as changing this configuration later is possible but not an easy achievement. The two main configurations presented here are:

Basic vCenter Single Sign-On:

  • Most common deployment option (VMware recommended)
  • This is a single standalone instance of the SSO server that supports the connectivity of Active Directory, OpenLDAP, Local Operating System and SSO embedded users and groups.
  • This typically would be local to the vCenter Server
  • Used by the vCenter Server Simple Install option.
  • Preinstalled with the vCenter Server Appliance

When to use basic vCenter Single Sign-On:

  • If you have a single vCenter server of any supported inventory size (up to 1,000 hosts / 10,000 VMs).
  • If you have multiple geographically dispersed locations each with a local vCenter servers and have no requirement for a single pane of glass view provided by vCenter Linked Mode.
  • You are using the vCenter Server Appliance (VCSA).

Basic Node configuration of vCenter Single Sign-On server will meet the requirements of most vSphere 5.1 customers and typically maintains the same architecture of previous vCenter server environments.

Create a Primary Node for a vCenter Single Sign-On Installation:

  • This is a single SSO server instance configured as a Primary within an advanced configurations like vCenter Single Sign-On server High Availability (SSO HA) or same SSO security domain placement in geographically separated locations (SSO Multisite).
  • Requires the installable version of SSO (Windows Only).
  • Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
  • Only one Primary node can exist in a single SSO environment

The Primary configuration allows for further configuration options to support the vCenter Single Sign-On high availability and remote site architectures.

High Availability

  • This is a SSO server instance that connects to an SSO primary server and provides local failover of the SSO server when both the primary server and high availability. servers are placed behind a network load balancer (e.g. Apache HTTPD or vCNS).
  • Supports Failover only, does not load balance requests between SSO nodes.
  • SSO HA can only support the primary SSO server or SSO Multisite server with one HA Backup server.
  • Requires the installable version of SSO (Windows Only).
  • Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
  • High availability backup nodes share the same database as configured when installing the primary node.
  • Does not provide failover or redundancy of SSO database

When to use the High Availability Backup vCenter Single Sign-On server

  • If you have multiple vCenter servers within the same physical location and plan for a centralized SSO environment.
  • High Availability of the vCenter Single Sign-On server is required and does not plan to use vSphere HA or vCenter Server Heartbeat (preferred).

I have found the SSO HA configuration to be complex, with the updating of certificates, using a third party network load balancer for failover and then provide no protection for the database to why I do not recommend it when discussing with customers. A standalone basic SSO service with vSphere HA or vCenter Server Heartbeat will provide a simple centralized solution with added functionality of database protection (if local to the standalone SSO server) in this scenario.

Multisite

  • This is a single SSO server instance that is used to provide a local copy of the primary SSO server instance at remote sites for local authentication. WAN authentication is not recommended with SSO.
  • Requires the installable version of SSO (Windows Only).
  • Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
  • Does not provide site redundancy of the SSO solution, if one SSO site fails you do not get redirected to another site for authentication.
  • Manual export/import of the database tables is required (scripts provided) between all SSO Multisite instances to manually maintain database synchronization. This is required whenever an update of any SSO Multisite server instances receives SSO configurations, SSO policies or embedded users/groups updates. This typically is not an everyday or every week task.
  • Local Multisite SSO server instances must be a member of the same Active Directory / OpenLDAP domain that the primary SSO server is a member of and have a local domain controller available.
  • By default SSO Multisite will only provide local resource visibility, and not a single pane of glass view across multiple vCenter Servers that are geographically separated and running SSO Multisite.

When to use the Multisite vCenter Single Sign-On server

  • If you are using Linked Mode.
  • If multiple vCenter Servers require the ability to communicate with each other.
  • If you are required to have one single vCenter Single Sign-On server security domain throughout your organization.

In general SSO Multisite removes the risk of slow WAN based authentications however with all the manual steps required to maintain SSO synchronization, I would only recommend the use SSO Multisite if you are using vCenter Linked Mode of which SSO Multisite is a requirement.

I hope this information has helped you understand the different configurations of vCenter Single Sign-On and to when you would use each configuration.

vCenter Single Sign-On – Part 1: What is vCenter Single Sign-On?
vCenter Single Sign-On – Part 3: Availability
vCenter Single SIgn-On – Part 4: Pre Install Requirements

 

34 thoughts on “vCenter Single Sign-On – Part 2: Deployment Options

    1. Justin KingJustin King Post author

      Thanks Thomas, I want to emphasize the criticality on planning the SSO architecture. You should not need to change the configuration if planned correctly although I understand changes to environment can occur, however SSO HA is not a recommended configuration for reasons stated, and Multisite for inheriting/creating a linked mode vCenter server which also as stated, is possible to re-architected at a later stage if necessary, we have KBs on this process and I’ll blog this at a later date to help.

      Reply
      1. MEL

        Hi Justin,

        I made a decision to install Basic instead of Multisite. Main reason is because of SRM considerations. Now a Linked Mode is needed (for DR and PROD) Management thus I need to convert Basic to Multisite. Would you be able to post the link for the KBs on this process as you mentioned above? I have upgraded VCenters on both sites. I would like to covert SSO before I upgrade SRM.

        Thanks,
        Mel.

        Reply
  1. John Braner

    It makes sense to install a SSO server as a primary, rather than use the simple install – for future proofing
    BUT

    in a SRM environment, where you need multiple VC servers – I’m thinking that either you’ll install basic SSO/VC servers at each site – or set up multisite.
    If you go with the “independent” SSO/VC Servers, and wanted to change your mind later – you’d need to point them all at each other – so everything would need to be reconfigured (the hard way, by uninstalling/reinstalling)

    It seems that setting up a primary node at each site (to future proof) would be a waste of time, as you probably wouldn’t want independent cluster/multisite configs – you would want to point them to each other as *one big* mutisite config. This would require tearing apart one of the “independent” primary SSO servers anyway.

    So unless I’m missing something – it’s hardly worth installing multiple “primary node” SSO servers.

    - 1 primary node (for future proofing) makes sense
    - independent basic installs (for SRM) can make sense
    - a multisite setup (for SRM) can make sense (let’s forget HA for now)
    - installing a primary node at each site of a multisite setup (for SRM) doesn’t make sense

    Does this sound right?

    Reply
    1. Justin KingJustin King Post author

      you don’t want to install multiple independent primary SSO servers as this will also lead to reconfiguring as you mention but even a single primary is only necessary if you plan to use linked mode which that decision would have/should have already been made before architecting the SSO component.

      Your headed down the right path though

      Reply
    1. Justin KingJustin King Post author

      to have single pane of glass you will need to use Linked Mode which will require the multisite SSO configuration. Then ask yourself if the single pane of glass view is worth the manual steps required to maintain multisite SSO which ultimately depends on the change factor around SSO embedded users/groups, SSO Polices and identity source configurations. This will be relatively static unless any of the four items change which will require a manual export/import

      Reply
  2. Andy

    You mention that SSO in HA mode can be load-balanced by vCNS. How might one go about this?

    Especially since vCNS requires vCenter and you don’t install vCenter until after you get SSO up and running.

    SSO Primary –> vCenter/Inventory/Web –> vCNS –> add SSO secondary? If you do that then wouldn’t you have to reconfigure vCenter/Inventory/Web to all use the VIP for SSO and that doesn’t sound fun.

    Thinking out loud here..

    Reply
    1. Justin KingJustin King Post author

      you’ll need to deploy SSO/IS/VC/Web Client first, then deploy an edge device (vCNS), setup a VIP for fail-over, update certs to VIP and re-point IS/VC/Web Client to the VIP and then add second SSO HA server into the mix. I have a great document that I can turn into a blog from one of our professional services guys but to be honest SSO HA is not the right direction if seeking SSO availability.

      Reply
      1. Andy

        Thanks Justin. I think a blog post may be worth it for those who don’t have a hardware load balancer, apache experience or Heartbeat but want something more than HA to protect SSO.

        Reply
  3. Pingback: vCenter Single Sign-On Part 1: what is vCenter Single Sign-On? | VMware vSphere Blog - VMware Blogs

  4. Niall

    Hi, In my environment we are using vCenter Heartbeat (LAN for local high availability). Is it possible to install SSO on my vCenter and therefore protect it with Hearbeat. Can you point me to any doco. Have been putting the upgrade off due to a lack of understanding on my part.

    Thanks.

    Reply
  5. Ian

    Is HA really the only option if I have multiple vCenter servers, within the same physical location, and want them to all use the same SSO server?

    It looks like that may be the case but then under the HA section it says, “A standalone basic SSO service with vSphere HA or vCenter Server Heartbeat will provide a simple centralized solution with added functionality of database protection (if local to the standalone SSO server) in this scenario.”

    Almost makes it sound like I can install SSO on its own server, in basic mode, and associate all the various vCenter servers to that? Is that true or is HA my only option?

    Thanks!

    Reply
    1. Justin King

      I have to explain SSO HA but it is not something I would ever use, for a centralized SSO environment (same location) then running the appliance or standalone windows box with SSO (maybe web client too) is my recommendation and you can provide availability with vSphere HA or vCenter Heartbeat. You can also keep the db local as it will not grow or change much post install.

      Reply
  6. Paul Hardy

    Thanks Justin a great post to help make sense of the multisite requirements. The manual replication that’s required if any changes are made to SSO at each site seems painful, very tempting to have a single SSO even in a multisite situation.

    Reply
    1. Justin King

      single SSO at each site or single centralized SSO server? the later will affect response times as they will be now across the WAN and not recommended, first option recommended if you do not need single pane of glass view.

      Reply
  7. Pingback: vCenter Single Sign-On – Part 3: Availability | VMware vSphere Blog - VMware Blogs

  8. Pingback: vCenter Single Sign-On – Part 4: Pre Install Requirements | VMware vSphere Blog - VMware Blogs

  9. peter jakobs

    Thanks Justin, good post, but I still have some doubts for my implementation.
    I’m having on my primary site 3 virtual centers (1 x management, 1 x vcloud director and 1 x general vcenter with 4 different clusters) and on my DR site I have one vcenter. They are all in linked mode and I have srm between the general vcenter and the dr site. vcloud director is connected to 4 different AD domains. (View is oncluded in the general vcenter). Any idea’s how many SSO to install and in what mode?

    Reply
    1. Justin King

      your best bet is to use two SSO instances, one a separate to the vCenters, standalone SSO primary instance at the prod site, you can also add web client to same SSO server and then two as you have linked mode you will need to use multisite for the DR site

      Reply
  10. Hung

    Thanks Justin for all the wondering information on your blog about SSO HA. We are planning to implement SSO HA using vCNS as the load balancer. I was wondering if I can get a copy of document from one of your professional services guys about SSO HA that you have mentioned you have access to from one of your blog reply.
    Reply ↓

    Reply
    1. Chris P

      I whish VMware would had been smarter when forcing customers to implement half working solution. To me, SSO implemented like this, is not the way to keep your customers happy. I have been advocated for, implemented and used VMware since 2004, but lately it seems that locking customers and pushing political agenda is above the customer needs to have a simplfied life and management that VMware promised to provide. OpenStack and other will keep gaining market everytime when you make bad decisions like this. I am very dissapointed on the whole SSO design and features available…..

      Reply
  11. Cristian Salgueiro

    Hi Justin. I have a single vcenter server 5.0 and I want to migrate to 5.1. In my laboratory I was able to do this, I had to install a basic SSO server. But in the production enviroment I need to provide a HA scenario for SSO because is a single point of failure. But you wrote this:
    “I have found the SSO HA configuration to be complex, with the updating of certificates, using a third party network load balancer for failover and then provide no protection for the database to why I do not recommend it ”
    I was thinking to install a SSO in HA with Windows NLB. What is your recomendation to resolve this need?
    Thanks!!
    Thanks!!

    Reply
  12. Pingback: vCenter Single Sign On aka SSO, what do I recommend?

  13. porn

    Remarkable issues here. I’m very glad to peer your article. Thanks so much and I am taking a look ahead to touch you. Will you please drop me a mail?

    Reply
  14. Pingback: Multiple vCenter Servers, SSO, and How To Design for Failure « Virtualization.BlogNotions - Thoughts from Industry Experts

  15. Pingback: DR/BC Site, SSO & AD Authentication | vStratus

  16. marketing print materials

    Hey there. I ran across your blog post making use of ask. That is a genuinely logically created document. I’ll ensure that you bookmark the idea obtainable to get more information of your beneficial facts. Basically submit. Let me definitely comeback.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>