- [Rick] In this video, I'll explain some of the concepts
and components involved with single sign-on.
Now before we get started here, I just want to mention
we're about to learn about things like identity sources
and how we can use these with the vSphere client
to get logged in.
But starting in vSphere 7,
vCenter supports federated authentication.
And VMware is encouraging us to use
this model moving forward.
And so what I'm showing you here is the single sign-on
documentation on the VMware website for vSphere 7.
And as you can see here in the documentation,
single sign-on is coming after
this federated identity provider authentication model.
So as we move on in the course here,
we're going to have a lesson explaining this new way
of doing federation and authenticating with that manner
using an external provider.
So I just want to mention that right off the top here
before we get into SSL,
is that now the Identity Provider Federation Model
is what VMware is encouraging us to use moving forward.
So here we see we've got our vCenter server.
I've called it vCenter1.
And our platform services controller.
And so these are two key components of single sign-on.
And what we're trying to do is we have
an administrator who is signing into the vSphere web client.
And when this administrator signs
into the vSphere web client,
that logging information is passed
onto the vCenter Single Sign-On servers
that runs in the platform services controller.
Now the other possibility here is the user might not
actually be putting in a username and password at all.
They might be using the Windows session
authentication option.
So if this administrator is already logged into Windows
and is a domain member and has domain credentials already
in their Window session, they can simply pass those through.
But either way, a set of credentials is going to hit
the single sign-on servers
of the platform services controller.
And those credentials are then checked
against an identity source.
Identity sources, we'll talk about on the next slide,
but those could be things like
Active Directory or OpenLDAP.
And so now let's assume
that this administrator successfully signs in,
his credentials are correct,
and the authentication is successful.
What happens at that point is single sign-on
returns a token, it generates a token.
Basically what single sign-on is doing here is it's saying,
"This is a good guy, I'm going to vouch for him.
"I'm going to say that, yeah, he's okay,
"you can my word for him."
And what it's doing is it's creating a token
that is then returned to the vSphere web client session.
And now that the vSphere web client has that token,
it will be allowed to communicate with vCenter.
The vSphere web client will be in the function.
So at this point, all we've really done is authenticate
to a single vCenter instance.
So why is the name single sign-on?
We're only signing in to one platform,
the vSphere web client accessing a vCenter instance.
Well, if there are other vCenter instances
or other VMware solutions
that are part of this single sign-on domain,
this user will be authenticated to those as well.
So that's why we call it single sign-on.
There could potentially be multiple vCenter servers.
But regardless, once you successfully authenticate,
now that token allows you access into all of these systems.
So what are some of the identity sources
that we can leverage with single sign-on?
Well, first on the list
we have the vsphere.local domain.
So this is a built-in domain to your single sign-on server.
When you set up single sign-on, it comes with a domain.
You're going to have a local domain there
that you can leverage.
Now this local domain isn't really the one you want to use
for all of your management of users and administrators,
but it's a good way to kind of get things started.
And the administrator or vsphere.local account
is a single sign-on admin,
which we'll actually talk about in just a moment.
We have Active Directory 2003 or later.
So you can specify Active Directory as an identity source.
And our Active Directory domain can have child domains,
or it can be a forest root domain.
And this option works with both Windows vCenter
and the vCenter Server Appliance.
So we can have Active Directory
as an identity source for either of those.
But for this particular option, the vCenter system itself
has to be an Active Directory domain member.
So whether you're running vCenter on Windows
or whether you're running the vCenter Server Appliance,
it has to be a domain member
in order to utilize this identity source.
If your vCenter server is not a domain member,
we can leverage Active Directory over LDAP.
Or if you're trying to support single sign-on
that's been upgraded from single sign-on version 5.1,
that's when this method is important.
The vast majority of the time, you'll simply specify
an Active Directory domain as the identity source.
But if you need to, you can also configure Active Directory
over LDAP as kind of like a backup option.
This is more complex to configure.
Then we've got OpenLDAP.
So OpenLDAP is supported as well.
If you're using that as your identity source
for your organization,
you can support that with vCenter.
And then last but not least,
we've got Local Operating System users.
So these users are local to the operating system
where single sign-on is installed.
This is only possible in basic single sign-on deployments
where there are not multiple single sign-on servers.
So how do we start to configure
all of these identity sources?
How do we set all of these up?
Well, number one,
we're going to do everything in the vSphere Web Client.
The vSphere Web Client is where we're going to configure
everything for this.
But we have to have a single sign-on admin
in order to configure things like identity sources,
or to configure our default domain.
So essentially, what you'll do is you'll sign into
the vSphere Web Client as administrator vSphere.local,
or as some other account that you have added
as an SSO Admin.
Now just be aware, a vCenter administrator
is not the same thing as a single sign-on admin.
You have to explicitly make users a single sign-on admin
if you want to give these options to them.
So now once you've got that done,
you can add identity sources.
You can specify one of your identity sources
as the default for the domain.
So for example, we could say that we want
Active Directory to be the default domain
for this single sign-on server.
What that means is that when a user tries
to log into the vSphere Web Client,
if they do not specify what domain they want to log into,
then there'll be logged into the default domain.
So for example, if our user John Doe
just puts in his username, John Doe, and his password,
single sign-on will assume
this is John Doe at the Active Directory domain
and go ahead and authenticate him
against that default domain.
So once you're configured as a single sign-on administrator
or logged in as a single sign-on administrator,
you can go ahead and configure the default domain
for a single sign-on.
So in the next video, I'll show you how to set
much of this up in the vSphere Web Client.