Home > Blogs > VMware vSphere Blog > Tag Archives: authentication

Tag Archives: authentication

Two Factor Authentication for vSphere – RSA SecurID – Part 1


This is Part 1 of a 2 part blog series. In this post we’ll talk about setting up RSA SecurID Authentication Manager, some architectural assumptions and what you’ll need to take with you to Part 2.

Two Factor Authentication

Two factor authentication (2FA) has become ubiquitous nowadays. For those of you still in the Dark Ages where you have your password written on a Post-It Note stuck to the bottom of your keyboard, 2FA is “something you have”, like a hardware or software token and “something you know” which would be a secret PIN.

Continue reading

Project Lightwave Now Available

Project Lightwave Now Available

Today, we are happy to announce that Project Lightwave, an identity and access management project for cloud-native apps, has been released as a free, open source project and is now available via GitHub and JFrog Bintray. Project Lightwave was originally introduced last month (read the news release).

What is Project Lightwave?

Project Lightwave is made up of the following key identity infrastructure elements:

  • Lightwave Directory Service – standards based, multi-tenant, multi-master, highly scalable LDAP v3 directory service enables an enterprise’s infrastructure to be used by the most-demanding applications as well as by multiple teams.
  • Lightwave Certificate Authority – directory integrated certificate authority helps to simplify certificate-based operations and key management across the infrastructure.
  • Lightwave Certificate Store – endpoint certificate store to store certificate credentials.
  • Lightwave Authentication Services – cloud authentication services with support for Kerberos, OAuth 2.0/OpenID Connect, SAML and WSTrust enable interoperability with other standards-based technologies in the data center.

When paired with Project Photon, VMware’s lightweight Linux operating system for cloud-native apps, Project Lightwave helps to assure that only authorized objects can run in the infrastructure.

Continue reading

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. Continue reading

vCenter Single Sign-On Part 1: what is vCenter Single Sign-On?

Confused with what vCenter Single Sign-On is?

I was until I dived in and found answers which I will do my best to explain here.

vCenter Single Sign-On is a new feature of vSphere 5.1 that is not just an authentication broker but also a security token exchange providing a more secure way of accessing your vSphere solutions. What that means is that when you previously logged into vCenter Server, you were authenticated with the provided username and password against the Active Directory configured for vCenter Server. With vSphere 5.1 and vCenter Single SIgn-On you no longer log directly into vCenter Server but with a security domain defined by your vSphere environment. When logging in to vSphere 5.1 you actually pass authentication to the  vCenter Single Sign-On server which can be configured with multiple identity sources like Active Directory and OpenLDAP and on successful authentication, your username and password is exchanged for a security token which is then used to access the vSphere components like vCenter Server and vCenter Orchestrator etc.


Although vCenter SIngle Sign-On is an additional component in the vSphere suite, a critical component that is required before any other vSphere 5.1 component is installed or upgraded, it actually doesn’t necessarily mean you need to re-architect your vSphere environment. You can use vSphere just as you have been from years past and vCenter Single Sign-On will fit right on in just as an additional service local too or separate from vCenter Server.


Where some of the confusion comes from I believe is with the added benefits that vCenter Single Sign-On can bring  when administering multiple vSphere environments. When installing vCenter Server you have the choice to specify or install a vCenter Single Sign-On server providing the ability to add multiple vCenter Servers and their components to a centralized vCenter Single Sign-On source. This provides a single pane of glass view across all vCenter servers, 5.0 and higher for administration as well as the ability to define queries that can be searched across multiple vCenter Servers without the requirement of Linked Mode used in the past.

Now this maybe seen as a single point of failure, a critical one at that when talking authentication but vCenter Single SIgn-On can be configured in a clustered or multisite deployment to help with availability.

Clustered deployments are with multiple instances of vCenter SIngle Sign-On are deployed, one is defined as a primary instance the remainder as slaves and all share a single database instance and placed behind a third party load balancer can provide redundancy or high availability of the vCenter Single Sing-On solution. This typically is local to a single site however if geographical sites are used with multiple vCenter servers, you can still utilize a central clustered environment, however a multisite configuration is recommended.

Multisite deployments are  where a local replica is maintained at remote sites of the primary vCenter Single SIgn-On instance. vCenter Servers are reconfigured to use the local vCenter SIngle SIgn-On service and reduce authentication requests across the WAN. Multisite deployments do drop the support of single pane of glass views unless Linked Mode is utilized and multisite deployments are actually required to maintain Linked Mode configurations where roles, permissions and licenses are replicated between linked vCenter servers. Linked mode will re-enable single pane of glass views across multisite instances.

I hope this was informative

vCenter Single Sign-On – Part 2: Deployment Options
vCenter Single Sign-On – Part 3: Availability
vCenter Single SIgn-On – Part 4: Pre Install Requirements