Review the single sign on (SSO) troubleshooting process using the page 46 reference in the vSphere Security Guide and break down the tasks shown in that document.
- [Teacher] In this video, I'll review the Single Sign-On troubleshooting process and I'll reference the vSphere Security guide and breakdown some of the tasks that are shown there. And so if we scroll down here a little bit, I'm in the vSphere Security Guide. And on page 46, it walks you through all of the steps for troubleshooting vCenter Single Sign-On. So what I'd like to do is go, take a quick look at this section of document, and then I'm going to walk you through some of the tasks that you might need to perform to actually complete the troubleshooting of vCenter Single Sign-On.
So here we can see a few different potential causes of Single Sign-On not working properly. In one of the most common causes of problems with Single Sign-On, is unsynchronized clocks. So it's important that all of the clocks on machines running vCenter Single Sign-On, the vCenter Server and the vCenter Web Client are synchronized. We want to ensure that all of our clocks are set to the same time. And we want to just control this using NTP so that we really never even have to think about it.
Now we can also have some problems related to Active Directory Domain Authentication. So with Single Sign-On, you have the ability to add identity sources, and these identity sources are simply repositories of user credentials such as Active Directory. We have a whole bunch of users who have accounts in Active Directory and we're going to add that as an identity source to Single Sign-On so that these users can log in using their Single Sign-On credentials.
Well we kind of have problems related to Active Directory identity sources as well, such as users not being able to log in to the vCenter Server. And one of the most common problems is number one, we have to make sure our clocks are synchronized, but we might also want to change the default identity source. So by default, if a user attempts to authenticate into the vSphere Web Client for example, the identity source is not Active Directory.
It's a built-in identity source that comes with Single Sign-On. So we might want to just go in, modify that default identity source and point it towards Active Directory. That way when people try to log into vCenter, and they use their Active Directory credentials, they will work by default. So now I'm going to log into my vSphere Web Client, and I'm going to sign in as a Single Sign-On administrator. In this case, I'm going to be email@example.com, and I'll put in my password.
Now it's very important that you're actually signed in as a Single Sign-On administrator. Just because you're an administrator with your vCenter roles and permissions doesn't make a Single Sign-On administrator. That's a different thing. So we have to make sure that when we sign into the web client to make these sorts of changes, we're signing in as an SSO administrator. And while my login is being completed, I'm going to maximize my console window here, and I'll hit F11 to go full screen in the browser.
And once this comes up, we're going to go into our Single Sign-On configuration. In the vSphere Web Client, I'll browse to Administration and under Administration, we'll find the options to modify Single Sign-On. So we can modify our users in groups in our default domain, but I don't want to do that. I want to go to Configuration, and here you can see the identity sources that currently exist. I can add a new identity source by clicking on this green button, and maybe create an active directory identity source if I want to do so.
But in this case, I just want to show you how to configure the default identity source. So let's assume we already have an Active Directory Identity Source created here or really any type of identity source that we want to make the default identity source. Well right now, we can see that the local OS is the default identity source for our Single Sign-On server. Maybe I want to change it to my vSphere.local domain. So I'll just go ahead and click on that domain and then we have a little button here that says Set as Default Domain.
So I can simply click on this button and it'll give me a little warning saying this is going to alter the current default domain, do you want to proceed? I'll go ahead and hit Yes. And now my default domain is vSphere.local. So the next time I log into the vSphere Web Client, I can just put in Administrator instead of Administrator@vSphere.local and by default it'll push that login attempt to the vSphere.local domain. Let's give it a try.
So my user name is just going to be Administrator, and my password does not change. And that'll get me back in, and I'll be logged in again as a Single Sign-On administrator, and I'll be able to go back in and change that default domain back if I want to do so. So let's browse to Administration one more time and under Single Sign-On Configuration, we can see vSphere.local is still set as the default domain.
- Using vRealize badges and alerts
- Troubleshooting CPUs for memory contention
- Working with lab environments
- Using performance charts and metrics
- vCenter monitoring, maintenance, and connectivity
- Troubleshooting SSO
- Working with esxtop and installing VMware tools
- ESXi management agents, diagnostics, and host health
- Troubleshooting resource contention
- Creating a vSphere distributed switch
- Working with vMotion, NIOC, PVLAN, DRS, and COMA
- Troubleshooting common upgrade issues
- Troubleshooting clusters
- Configuring an HA network