Welcome back to vSphere 8 in the real world, and now we're going to discuss single sign-on.
So, single sign-on is used to authenticate users into your vSphere environment,
but not using local accounts that are in your vSphere, you know, single sign-on environment
that was created when you installed vCenter.
It's going to allow you to use your single sign-on services to configure a third provider.
In addition to the vSphere single sign-on service that's installed with vCenter, another provider.
For example, the most common one that's very often used would be Active Directory Directory Services.
So, we can actually have our vCenter server join our Active Directory Directory Services,
become a member of that, and then start using user accounts for that vCenter server.
So, we can use our local single sign-on.
We can create users in our single sign-on, our vCenter single sign-on environment.
We can create groups.
We can assign roles to it.
We can give it access to different, you know, resources or systems.
We can say, I create a user.
User gets a role.
The role has certain privileges associated with it,
and then I can assign that role and say it, you know, has this level of access to a cluster
or to a host or to a single VM.
And whatever that role has privileges to do, it can do on that cluster or that host
or that VM or a resource pool or whatever you're assigned it to.
We can do the same thing and create users in Active Directory.
And in Active Directory, we can create groups, and we can put the user into a group.
And then we can use our vCenter environment and take those users
and groups that we created in Active Directory
and assign them to roles in my vCenter single sign-on.
So, then I can say, okay, the roles that we have here, manage VMs,
and my Active Directory admins, you know, VM admins group,
by creating Active Directory will be a member of the manage VMs role in my vCenter server.
So, it allows me to use the same name and password that I use to log into my workstation
when I need to do administrative tasks and things like that.
Hopefully not the exact same name and password.
Hopefully we have a separate one for administration.
But it allows me to use that domain account that I use for administering my domain
or for administering my servers and things like that to also manage my vCenter server.
So, I don't have to worry about remembering two different usernames and two passwords
and changing passwords here and changing them there.
I just do it all in one place.
It's really convenient.
So, if we're using our vCenter single sign-on, then, you know, we're using the VMCA
and using certificates that are provided to us through our VMCA.
If we are using our single sign-on services and connecting to, like, Active Directory accounts,
then we're using SAML tokens.
And SAML is really just a language, a way of formatting tokens that is accepted by a lot of different,
you know, organizations or a bunch of different companies that make different types of products, right?
VMware, for example, is one.
And you might, you know, have noticed that when you log into your Office 365 account
and you can access certain things with your company.
And then you go to another company's website, and you can use that same credential just to log in there.
And sometimes you don't even have to log in.
It will say, oh, this is your username, and your SAML token goes over.
It says, oh, you're already authenticated, and it lets you into that website, into this website.
So, SAML is a way of creating tokens that are trusted by different organizations
because they trust your single sign-on environment or your directory service, okay?
So, it administers things like, you know, user identity, what the identity store is going to trust or not trust, okay,
and then the single sign-on domain, for example, your Active Directory domain.
So, how do we add a single sign-on service?
Okay, so this is to create a user for our single sign-on.
We're going to log into our vCenter environment.
And once we're in our environment, we can go to Home Administration.
We're going to find our single sign-on tab, the tab that's over on the left, right?
We're going to select Users and Groups, choose the Users tab, set the domain.
So, by default, when you first go in there, if you haven't done anything else,
if you haven't added Active Directory, you'll see that default vCenter single sign-on domain.
And so, normally, it's vSphere.local, right?
That's the one that creates by default.
You can change that name.
In our lab environment, ours is stormlab.local, so vSphere.local.
But almost everyone, by default, is using the vSphere.local for the vCenter single sign-on domain.
And so, you're going to choose the domain, and then you can go through.
So, you want to create a new user.
You can see your users that are in there.
If you say Add, you can go in there and create the user and then click, you know, done, you're finished with that.
So, we'll walk through a demo here shortly, and I'll show you how to do that.
So, adding a single sign-on identity.
So, we can add an Active Directory domain.
We can also add some other identity-type tools in there.
So, again, we can just go in to click the little hamburger, go to Administration.
Once we're in Administration, we're going to go down to our Single Sign-On tab,
and we'll see our single sign-on different tools in there.
We can go in, select it, and say we want to add an Active Directory domain.
And then it'll ask us for the domain we want to join this vCenter to,
and then a domain admin that is allowed to join computers to it, right?
And we'll walk through how you would do that.
So, security best practices.
So, single sign-on can help protect your environment,
because it basically forces users to use credentials to authenticate
and hopefully secure credentials, because you have configured your Active Directory
to require secure names and secure passwords and complex passwords,
and you need to change them every so often.
And all those policies that you've configured with Active Directory that you trust,
you now can use with your vCenter environment.
So, how can single sign-on be secured?
So, keep password expirations in mind.
So, you want passwords to expire, right?
You want your user's passwords to expire.
You want them to expire in a reasonable amount of time.
Six months is not reasonable.
Usually it's like somewhere between 60 and 90 days is considered to be pretty reasonable.
All right.
Default time is 90 days.
If a password expires, then you can't log in anymore, right?
You must change that password before you can log into it again.
And so, ensure passwords are changed often.
Now, what that means is, just because it expires in 90 days,
and let's say my password was password123, a really secure password,
and I said, oh, I have to change it.
Fine.
What's my old password?
Password123.
What's my new password?
Password123.
Confirm password123.
I didn't just change my password.
I just kind of reset the timer on it.
So, another option that you can do with your AD environment is, say,
passwords must be unique.
You can only reuse a password every so many times,
and you can make that number be pretty high.
So, maybe the last 10 or the last 60, right, have to be unique.
So, that way users can't just keep recycling the same password,
the same two or three passwords over and over and over.
Another thing is you might want to make sure, you know,
you set a policy that's a little bit harder to enforce through Active
Directory by default, but that they don't use the same password as last
time with a different character.
Password123 start.
And then, oh, now I've got to change it.
Password123 dollar sign.
Oh, now I've got to change it.
Password123, you know, exclamation point.
So, that's not really making your password very secure either, is it?
So, make sure that users know they need to really change their passwords
when it comes time to change their passwords.
And then NTP.
NTP is very important when you're discussing single sign-on because,
again, the machine you're signing in from,
its clock needs to be within, you know,
no greater difference than five minutes between your clock,
the vCenter clock, right,
and the domain controller you're trying to authenticate against.
So, if it's more than a five-minute variance there,
what's going to happen is it'll say, oh, you know,
your clocks are out of sync and I don't trust this packet you sent me
because it looks like it's really old and it won't accept it.
So, use NTP to keep, you know, your clients, your vCenter servers,
your Windows domain controllers,
all these different systems to keep all their clocks within at least a
five-minute difference of each other.
So, securing single sign-on best practices.
Authentication by adding users, identity sources,
and so this is quickly reviewing here.
Single sign-on is used to authenticate users, right?
We can add users into our single sign-on domain.
We can also use our Active Directory domain.
Basically, we are going to trust the source of this authentication, right?
Either we're using the vCenter single sign-on,
and we're saying we trust that,
or we're using our Active Directory single sign-on,
and we're saying we trust this database over here.
We have established a relationship,
a trust between vCenter and our Active Directory directory services,
and we have certificates and stuff in place so we can authenticate each
other and, yep, we know our communications are secure.
And then you want to follow best practices.
Like, for example, you want to follow password exploration best practices.
You want to follow uniqueness best practices and things like that.
But now that we discussed single sign-on,
let's go ahead and go back into our demo environment,
and I'll show you how you can set up and configure user accounts,
roles, and how to configure single sign-on.
So, here in our demo environment, I'm going to click on our hamburger here,
and I'm going to go to administration.
And in administration, you see here I have last time I had open,
I had these roles, global permissions.
First, let's go down to single sign-on, and let's go to configuration.
So, here we can configure identity sources, right?
We also can see our rules, our policies for local accounts, right?
Our single sign-on domain name is stormlabs.local.
Here I have policies for, like, minimum length and, you know,
character requirements, things like that, maximum length, minimum length.
Something that's kind of interesting, let's just say, for example,
I say I need to have at least one uppercase character here.
If that uppercase character is the first character in my password,
it doesn't count as the uppercase character.
I have to have an uppercase character someplace else in my password.
And if I say that I have to have at least one numeric character,
if that numeric character is the last character in my password,
it doesn't count as a numeric character.
I need to have an uppercase character somewhere else in my password
and a numeric character someplace else other than the end in my password.
An uppercase character someplace else in the beginning
and a numeric character someplace else other than the end.
So just keep that in mind if you go in and say,
well, okay, my password's 10 characters long and it has to be at least 8,
so not more than 20.
Ten fits that bill.
And I have an uppercase character and I have a numeric character
and I have all these things.
Why is it not working?
Maybe put another uppercase character someplace other than the beginning
and put a number someplace other than the end,
and that might help you there.
All right, just a little something to keep in mind.
So here's our lockout policy.
So also we can configure a message so when someone logs in,
they get a banner that gives them some kind of corporate warning
about only authorized corporate users.
It might be something you get from your legal department
or something like that,
or something you've got GBT fed you that you asked it for.
Okay, so if you want to configure Active Directory,
here we can go and say we want to join AD.
I'm going to give it the domain name, right,
optional organizational unit name,
an Active Directory directory services username,
and my password for my Active Directory directory services.
I'm going to say join.
It's going to have to do a reboot of this system,
and then when it comes back up again,
I should be a member of Active Directory,
and now I can start using Active Directory accounts.
So under users and groups, like I can say here,
I want to use my stormwindlabs.local.
This is my vSphere single sign-on domain.
If my corporate Active Directory directory services domain
was stormwinds.local or stormwinds.com,
then that domain would show up here also.
So if I want to create users for my vSphere single sign-on domain,
I can click on add, and I can give this a name.
I can just call this demo01.
I'll give it a password.
All right.
Oh, it's probably not.
Okay, let me just try that and that.
Okay, there we go.
And I can just say it is a – I can put in things like email addresses
and descriptions if I want to.
I can go in there and change these things later also,
except my username I can't change.
So if I were to say add here, I have my demo account.
I can check it.
I can say I want to edit, and I can go in there and edit the password,
change this password, change first name, change last name,
modify the email address, modify the description.
I can't change the username.
That is kind of set in stone there.
All right.
Any other options?
I can disable the account.
If it's just locked out or, you know, disabled, I can enable it.
Now, another thing I can do is now that I've created this demo account,
I can go to my roles, and I can go in and say, okay,
I want to make this user a virtual machine administrator, right?
I just want them to administer virtual machines.
So I can scroll, and I can see I have my virtual machine power user, right?
Here's the virtual machine power user, and here's the virtual machine user.
I can click on this and say, well, what can this user do?
And all these different things, they can cancel tasks,
they can create tasks, modify tasks on the VM, right?
They can acquire a disk lease, add an existing disk, add a new disk,
add or remove a device.
Here's a list of all the things that this power virtual machine user can do.
What about a regular virtual machine user?
What can they do?
They can create tasks, right?
But they have a lot fewer things down here they can do.
This list is a lot shorter than the power user.
What if I wanted something in between this user and this user?
Well, you know, you don't want to go in and modify your default roles.
Those are always to be left alone.
And notice how it says sample, kind of help you know that these are kind of,
you know, some of the ones that are sample roles
that we can mess with a little bit.
What I can do is I can say I want to clone this, right?
And I can say, maybe I can say storm winds virtual machine power user
and get rid of that sample.
And here I can say custom storm winds VM power user.
So, I just know this is not the default one that comes with it, right?
And I can say okay to this.
And now that I have created my storm winds one,
I've got to find an outward to place it.
Right here.
Now I can go into this guy, and this is one that I should not mind editing,
and actually I want to edit it because this is going to give me the ability,
you know, to make those changes I was looking for, right?
So, I can say, all right, so what can this machine do?
So, let's go down.
I want to look for virtual machines.
You can tell something in this is selected,
and all these things are related to that, right?
But there's nothing related to create data set and, you know, delete data set,
things like that, right?
Edit inventory, create new.
Maybe I want to be able to create a new one, right?
Or maybe I don't want the users to be able to change CPU or change memory.
I don't want those.
I don't want them to change any settings at all, right?
They can modify some of these other things, right,
but not the settings and not CPU and memory.
Or maybe okay with settings, but, you know, not CPU and memory.
So, now I have customized this storm winds virtual machine power user group
that I created, and I can save that.
Under these global permissions, I can go in, and I can say I want to add,
and at my storm winds lab, I'm going to find my group,
and I'll just call this demo one.
And then I'm going to find my storm winds virtual machine power user.
To have it jump there, I hit S on my keyboard,
and it kind of jumped into that first instance there.
So, now this user is going to be in this role.
And when I say propagate to children,
what that means is that I want this to propagate to other resources
in my environment as well.
So, it will probably get down in the chain to, like,
subfolders and things like that when I assign it to resources.
So, okay to that.
And so, now that storm winds user is in the global permissions.
Global means it's going to be assigned to everything, right?
I can also go in to my inventory, and I can choose, like, for example,
a data center or a cluster, and say I want to add permissions.
And, again, I can say, okay, now to just this data center,
choosing the domain, if I had AD integration configured,
I could choose my Active Directory domain.
I could say what user.
I have one in here called test group.
And I want test group to have that storm winds
virtual machine power users ability.
So, test group has a storm winds virtual power user ability only in that DC.
So, now if I put a user in that role, they are in this DC.
They now can, you know, manage virtual machines with the privileges I created
for that unique role that we just set up.
So, again, administration.
We can configure our single sign-on through our single sign-on configuration.
We can manage users.
We can manage groups, right?
So, I can create a group for my demo group.
Let me take that one out.
And we're going to look for my demo user, demo 01.
So, now demo 01 in that group.
And that group is already in my storm winds virtual machine power users role.
And so, now this new user I just created or that new group I just created,
right, in that role.
So, it's pretty easy to see how we can quickly manage.
So, now if I need to hire another person or bring another person on,
I can just create a user account for them, add them to my demo group,
and they'll automatically have all the same rights
and permissions as the other people that are in that same demo group
and what roles they're applied to.
So, it makes it really easy to manage your vSphere environment.
You don't have to create users
and then go manually assign them to all these things.
If we have certain job functions already defined,
we can use our users and then groups and assign them to roles,
and they'll start inheriting it from their group.
And that is single sign-on in users and groups.