– [Rick] In this video, I’ll explain some of the concepts and components involved with Single Sign-On. 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 login information is passed on to the vCenter Single Sign-On service 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 Windows session, they can simply pass those through. But either way, a set of credentials is going to hit the Single Sign-On service 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 take my word for it. 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’ll 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 into 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. The VMware documentation recommends no more than four, but it’s not really a hard guideline, and that’s valid for vSphere 6.5 or vSphere 6.7. You can have up to four vCenters connected to a Single Sign-On Server. 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 of 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 back up 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 of 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 they’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 Single Sign-On. So, in the next video, I’ll show you how to set much of this up in the vSphere Web Client.
- Zebra Mildliners vs. Milkliners | Review & Swatches + Giveaway!
- You can get PAID to test spas this summer