1. vCenter Single Sign-On (SSO) for vSphere 7
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, V Center 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 in that manner using an external provider. So I just want to mention right off the top here, before we get into SSO, that the Identity Provider Federation model is what VMware is encouraging us to use moving forward. So we have our Venter server, which I’ve named Venter One, and our Platform Services Controller. And so these are the two key components of single sign-on. And what we’re trying to do is have an administrator sign into the VSphere Web client. And when this administrator signs into the VSFA Web client, that login information is passed on to the VSFA single sign-on service that runs in the Platform Services Controller. Now the other possibility here is that the user might not actually be entering a username and password at all. They might be using the Windows session authentication option. So if this administrator is already logged into Windows, 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, which we’ll talk about on the next slide. But those could be things like Active Directory or Open LDAP. And so now let’s assume that this administrator successfully signs in, that his credentials are correct, and that the authentication is successful. What happens at that point is that single sign-on returns a token. It generates a token. Basically, what Single Sign On is doing here is 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 creating a token that is then returned to the Vsphere Web Client session. Now that the Vsphere Web client has that token, it can communicate with V Sounder. The vSFER Web client will begin to function. So at this point, all we’ve really done is authenticate to a single V Center instance. So, why is it referred to as “Single Sign-On” when we’re only signing in to one platform, the Visa Web Client, which is accessing a V Center instance?
Well, if there are other V Center 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 VCP servers, but regardless, once you successfully authenticate, that token now allows you access to 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 is the Vsphere Local Domain. So this is a built-in domain for 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 at Vsphere Local Account is a single sign-on account called 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 forced root domain. And this option works with both Windows vCenter and the VSA 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 utilise this identity source. If your VCenter server is not a domain member, we can leverage Active Directory over LDAP. Alternatively, if you’re attempting to support Single Sign on, that has been upgraded from Single Sign on version five. One, that is when this method is useful. 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 a kind of backup option. This is more complex to configure than Open LDAP, so Open LDAP is supported as well. If you are 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 deployments, where there are not multiple single-sign servers.
So how do we start to configure all of these identity sources? How do we set all of these up? To begin with, we’re going to do everything in the Vise for Webcline. The Vessel for Webcline is where we’re going to configure everything for this. But we have to have a single sign-on administrator in order to configure things like identity sources or our default domain. So essentially what you’ll do is sign into the Vsphere web client as an administrator at vsphere.local or as some other account that you have added as an SSO admin. Now, just be aware: a V Center administrator is not the same thing as a single sign-on administrator. If you want to give users these options, you must explicitly make them single sign-on administrators. So now that 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 Vsfair web client, if they do not specify what domain they want to login to, then they’ll be logged into the default domain. So for example, if our user John Doe just puts in his username as John Doe and his password as single sign-on, the system 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 up.So in the next video, I’ll show you how to set much of this up in the V SFA web client.
2. Demo: vCenter Single Sign-On (SSO) for vSphere 7
So here you can see I’m at the login page for the Vsphere client, and I put in my username and password, and I’m logging in as the single sign-on administrator. So in this case, it’s administrator at Vsphere dot local, and by default, that’s your single sign-on administrator. So that’s what I’m going to log in as and get into the HTML Five Vsphere client. So this is my single-sign-on administrator account. And since I am logged in as that administrator, I can navigate to Administration. And under Administration, I can see the configuration area for single sign-on. So I’ll just click Configuration under Single sign on. So because I’m logged in as the SSO administrator, I can go to my identity sources here and potentially add additional identity sources.
And you can see here that there’s one identity source that’s already been created, the Vsphere dot local identity source. This one is local to V Center. All the users and groups that exist within this Vspherelocal domain are built right into Vcenter itself. So this is a great way to kind of get the VCR server appliance up and running and have this built into single sign-on as an administrator. But it’s not really the ideal identity source on an ongoing basis. You’re probably going to want an Active Directory domain, open LDAP, or some other type of identity source present in your recent server appliance. So let’s go ahead and add an identity source. And again, this is something you can only do as a single-sign-on administrator. And for the identity source type, I’m going to choose Active Directory for Windows, integrated authentication.
Now here you can see I am unable to add a new identity source for ActiveDirectory because, at the moment, my VCenter single-signon server is not joined to any domain. So we’ll just click on this little link here to go to the Active Directory domain page, and I’m going to join Active Directory. And so I’ll fill up my domain, enter my username and password, and click on “Join.” And once this Active Directory join operation is complete, we’re actually going to have to reboot the Vcenter Server appliance in order to make these changes take effect. Okay? And so now we can see that my Vcenter server appliance has been successfully joined to the domain, so I need to reboot it in order to apply these changes. So I’m just going to go ahead and reboot my Vcenter Server appliance. So I’m going to launch the Vami, which you do by simply grabbing the address of the V Center server appliance. But instead of having all this Vista client stuff behind it, we’ll put a colon at 54 and 80. That will bring me to Vami. The Vcenter Appliance Management Interface I’ll log in there as root, and once I’m in, I can just go to Actions here and reboot the VCenter server appliance. So now I’ll just pause my recording while VCenter reboots.
And when it comes back up, we’ll resume. Okay, so now my VCenter Server appliance has finished rebooting. So let’s go back to identity sources. I’m going to click on “Add Identity Source.” I’m going to select this Lab Local domain and press the Add button. And so now we have an additional identity source available here. And these identity sources are really just repositories of users and their passwords. So if I want to create roles or permissions for a specific user or a group of users, now I can create those roles and permissions for users in my Lab Local Active Directory domain. Okay, so now that we’ve successfully added our identity source, let’s go to the Users and Groups view and take a look around. And you’ll notice here that we’ve got this domain that we’re currently viewing. This is the domain of the local V Center server. But what I really want to start by looking at is this Vsphere local domain. And look at this. Here’s the account that we’re signed in to right now: administrator at vSphere, local. This is my single sign-on account as an administrator. So that’s what we’re signed in as right now.
And if I wanted to, I could manually create more users inside of this VS for Local domain. I could give them roles and permissions inside VCenter. But I’m not going to do that. The way that I’m going to manage my administrative users is through their Active Directory domain credentials here in the Lab Local domain. So let’s pick one of these ActiveDirectory domain users to focus on. And I’m actually going to just choose this administrator account here. So let’s go to roles. And here are all of the built-in features of Fee Center. And one of those built-in roles is administrator. So I can see here that the administrator essentially allows you to do everything. And there are a few other built-in roles, like no access or no cryptography administrator. There are a few baked-in roles here that are built right into VCenter right out of the box. So I just wanted to take a quick look at those before we migrate over to the hosts and clusters view. And what I’m going to do is create a new permission on my training virtual data center. So I’m going to go to permissions here, and I’m going to create a new permission using one of my Active Directory domain users.
So here is the user: What domain is this user coming from? I’m going to choose my Active Directory domain at the local level. I’m going to choose an account administrator at Lab Local, and I’m going to choose which one of those built-in roles I want to give this user. So I’m going to give Administrator at Lab Local Administrator permissions, and I can choose to propagate them to children. So, if there were any hosts or anything else under this training virtual data center, This permission would be effective on all of those child objects as well. And I’ll just go ahead and click OK here. So now what I’ve essentially done is create a scenario in which I can start assigning administrative permissions to Active Directory domain users and groups. So now I’m just going to log out of the Vsfair client here and validate that the configuration that I just set up is actually working. So I’m going to log out as administrator at Vsvrdot Local, and I’m going to log in as administrator at Lab Local and just validate that the permissions that I just set up are actually functioning. And it looks like they are. I can see here that I navigated to the training data center. And so let’s try a little test here. I’ve got a couple hosts in my training software-defined data center. I’m just going to try to make a quick configuration change to one of these hosts.
So I’ll go to the first host and click on Configure, and I’m just going to add a port group to one of my virtual switches. So I’ve got my standard virtual switch here. Let’s just make a quick change. I’m going to add networking. I’m going to create a new port group. I’m going to choose my existing virtual switch. Just call the port group demo next to finish, and let’s make sure that my change takes effect. And yup, there it is. So moving forward, now instead of managing users inside of the Vsphere local domain, I can simply have a single set of credentials. My administrators can access the Vsfairclient by logging in with their Active Directory domain credentials. And so I can go ahead and assign permissions to them in the Vsfair web client based on those Active Directory domain credentials.
3. vCenter 7 Identity Federation
What is the purpose of the Identity Federation with ADFS? Well, number one, I just want to point out initially that this requires Active Directory and an ADFS server. And what we’re trying to do here is essentially replace single sign-on, but only in scenarios where you want multifactor authentication. So in a traditional single sign-on environment, you’re going to authenticate, and Venter is going to take your credentials and pass them to Active Directory. And then at that point, a token is generated, and the token is sent to your browser. And now you’ve got a token for a single sign-on, so you can do what you need to do. But Vcenter is basically acting as a go-between. It’s handling your credentials and passing them along to Active Directory with ADFS. And with this Identity Federation, when you attempt to authenticate, you’re just being redirected to ADFS, and you’re resending your credentials directly into ADFS. And, because ADFS is involved, we can configure a multifactor authentication configuration in our application group to force users to authenticate using MFA at that point.
And versus Fair OIDC and OAuth 20 are supported by Identity Federation. Those are industry-standard protocols. So the bottom line here is that Vcenteris does not directly integrate with Active Directory. We’re not necessarily going to set up Active Directory as an SSO identity source. So let’s take a look at how this authentication process actually works. Here we have a user, and the user is launching the Vsphere client. As a result, they would normally just authenticate to V Center at that point. They authenticate with v. Center after launching the vs. fair client. But in this case, I’ve configured an identity provider in Vcenter, basically pointing to my ADFS server. So now the credentials that this user is going to input are actually going to be redirected to ADFS before they’re put in those credentials.
V Center knows the URL of ADFS, and V Center no longer handles those credentials. The authentication process is being handed off to ADFS, and ADFS has to be configured with an application group. The application group has the uri of Vcenter. These are basically just little identifiers that we have to get and put into our ADFS application group. And when we finish this slide, I’ll show you where you can find those resources. So essentially, within ADFS, we’re going to create this application group, and the application group knows about the center. And so, therefore, this essentially allows the centre to use ADFS for authentication. At this point, One of two things will happen. ADFS is either going to just directly authenticate against Active Directory or ADFS has been configured with some sort of multi-factor authentication. It is dependent on how I have configured my application group and ADFS. So either MFA authentication is going to happen now or we’re just going to allow them to directly authenticate against Active Directory. And ADFS is tied to Active Directory, where my users and groups actually exist.
So once the users have logged in, a sample token is provided to the Vsphere client. And that’s basically just ADFS vouching for your Vsphere client session, saying that, yes, this user has now been successfully authenticated, at which point the Vsphere client is redirected back to V Center. And now, within V Center, we can start to create roles and permissions and apply them to Active Directory users very similarly to the way that we did with single sign-on. So, like I mentioned, there’s some documentation that can help you if this is something that you need to set up. And you can find a link to this documentation in the Udemy course resources that will walk you through the complete process of setting up an identity-provider federation in VCenter and configuring the necessary settings. And you’ll notice you need to find those Uris for V Center. This is going to tell you how to find those redirect URIs that you need to input into ADFS. And then you’ll go into ADFS and create an application group. There are separate knowledge base articles that will help walk you through that process. And then you’ll create an identity provider on the VCenter server and point it towards your ADFS server. And so those are the functional components, and this documentation will walk you through that process. If you want to do this in your own environment.
4. Demo: Roles and Permissions for vSphere 7
I’m going to just click on this little Vsphere client icon at the top left because that brings me to the home screen of my VSFare client. And from there, I’ll click on administration, and under Access Control, I’m going to go to Roles. So there are a few things to be aware of when it comes to roles. So by default, we’ve got a bunch of built-in roles that are automatically created here. And the first role that I want to focus on is the administrator role. So first off, let’s take a look at the description. This is full access rights.Basically, anybody in this role can do anything they want. And if I click on “Usage,” I can see who’s been granted this role. So I have one active directory domain user, labadministrator, that’s been granted that role, and a few other users that are granted this administrator role. And here are the privileges that those users get: They can basically do anything they want.
There’s also another role that’s very similar called the “no cryptography administrator” role that has a similar set of privileges to my administrator role. The only difference with the no cryptography administrator role is that this account does not have the ability to encrypt or decrypt virtual machine disks. So if you need to create an administrator account that is unable to carry out encryption or decryption tasks, that would be the “no cryptography” administrator role. There are a couple other prebuilt roles that are pretty intuitive. We’ve got a read-only role and a no-access role. And those two are pretty much read only.Grants read-only access; grants no access; no access So we can see here if anybody has been assigned to those roles and what the description of those roles is. So those are the major, prebuilt roles right there. And then you can also see that I’ve got a bunch of sample roles built right in here. And the sample roles are here to, basically, provide you with a template. So, for example, consider this sample role for a resource pool administrator. It has a set of privileges that are built into the sample role. And if I look at Network Administrator, this can assign networks to virtual machines.
So there are all these sample roles built right in here, each with their own set of privileges. And these are a great way for me to create my own new custom roles. So for example, if I click on “Virtual Machine Power User,” the sample role, I can then click on “Clone Role” here and I can create a copy of this role. So let’s say, for example, that I want to create a role called Helpdesk. And I know I want my Help Desk team to have all of the permissions from this virtual machine power user role that’s already created. And I’m just going to call this role HelpDesk and make that the description as well. And so now I’ve created a new role that automatically has all of the permissions of that virtual machine power user role. So I’ve created myself a new custom role based on an existing sample role that was already there. Then I can click on my Help Desk role, edit it, and select it. Hey, maybe I want to allow my HelpDesk team to do things like change the configuration of virtual machines, create new virtual machines, or create virtual machines from existing inventory. Move the virtual machines. Remove virtual machines.
I can pick and choose which privileges they should actually have here. And I can drill down into any of these areas and choose whether they should be able to assign networks, configure, move, or remove networks. If it’s my help desk team, I probably want to give them access to alarms and give them the ability to acknowledge and create alarms and do stuff like that. Maybe I want to let them browse the contents of my data store, maybe I want to let them remove files from a data store, so we can pick and choose which privileges they should have and create our own custom role here with the permissions that this Help Desk Team requires. And this is a much better approach than simply giving them the administrator role. I don’t want to just give out that administrator role to all sorts of people. I want to be really careful about who gets that role. So creating a new custom role is a great way to really limit the permissions that we give certain administrators. OK, so now I’ve created my own new custom role called Helpdesk. Let’s use it. Let’s go create a permission using this role. So I’m going to click on my VSFare client icon there at the top left and go to Hosts and Clusters. And then I’m just going to click right on my VCenter server here in my inventory and go to permissions. And I’m going to create a new permission at the VCenter server level.
And so I’m going to pick one of my Active Directory domain users, and I’m just going to choose Allen as my user. So Allen lives close to the lab. I’m going to give Allen the help desk role. Allen is part of my Help Desk team. So I’m going to give Allen the Help Desk Role at the VCR level, and I’m going to propagate this permission to child objects, meaning that Alex will have this Help Desk Role and all of the permissions within it on my VCenter server, in the Training Virtual Data Center, and on any hosts that are under this inventory as well. So I’ll just hit OK here, and here we can see the new permission that I’ve created at the VCenter level for this object and its children. And if I browse down to this ESXi host and look at permissions, There’s the permission that I just created, so that permission is effective on this ESXi host because I chose to propagate it to children. So that’s how we define roles and permissions in the Vsphere client. And you just want to bear in mind that roles are simply collections of privileges. That was the role of the Help Desk that we created. It was simply a collection of privileges. That way, we can grant those privileges to specific users and choose where we want to grant them. We granted it at the Vcenterlevel in our case, but we could be much more granular if we wanted to. Bye.
5. Demo: VM Encryption
In this video, I’ll show you how to secure virtual machines and harden them against attack. And what I’m actually going to start with is some VM storage policies. So here I am on the home screen of the Vista A client. I’m going to click on VM storage policies, and you’ll notice we have a policy here called VM encryption policy. So let’s go ahead and edit this policy. And it’s called the VM encryption policy. Here’s a sample storage policy for virtual machines where we want to enable the encryption of our virtual machines and virtual disks. And so here within the storage policy, I’ve already enabled host-based rules, and I’m going to click on Next. And under encryption, I can choose whether or not I want to actually enable encryption on a group of virtual machines. So this is a storage policy that basically applies to any virtual machine that has this storage policy identified and assigned to it.
The virtual discs for that VM are going to be encrypted. So now I can simply go back to the homescreen of my Vsfair client, choose a virtual machine, right-click it, go to VM policies, and edit the storage policies for this virtual machine. And I can enable this VM encryption policy to ensure that the contents of this virtual disc are encrypted. And I’m going to go ahead and hit OK here. And now I notice it’s giving me an “operation failed” error. So let’s talk about why that is. So the reason I’m getting this error is because I’ve skipped a prerequisite step here. So, if I go to my ESXi host and click on the configure tab, this is the host on which that version of the machine is running, and scroll down to the security profile for this host, I can see that host encryption mode is currently disabled on this particular ESXi host. So I’m going to set the encryption mode to “enabled” and hit OK. And again, I’m getting another error. So the problem I’m having now is that I haven’t built some of the prerequisite components in order to enable encryption on virtual machines. So let’s take a moment to look at the documentation at Docs vmware.com.And here are the virtual machine encryption components that are required. I’ve got my VC server and my ESXi host, which are two of the required components.
But I also need a third-party key management server, and I haven’t created that yet. So what I need to do is create some sort of key management server from a third-party solution and associate that with my VCenter server. And only after I’ve set up a default key management server am I ready to enable VM encryption on individual virtual machines. So, here are some of the different key management servers that VMware actually supports. And we can deploy any of these key management services and integrate them with Vsphere in order to enable encryption on our virtual machines. So I don’t have one of these key management servers deployed in my environment. And that’s the reason why I’m getting the errors that I’m getting. Another handy way to find these key management servers that are applicable to your exact version of Vsphere is to go to the VMware compatibility guide and look under Systems and Servers. I’m going to look for key management servers.
And so here you can see all of these different partners that can potentially provide key management servers for VM encryption. I’m going to update this and view the results. And here we can see a whole bunch of different key management servers that we can potentially utilize. So the process is going to vary depending on which one of these key management servers you choose to implement in your environment. So once you’ve got that key management server successfully deployed, here you can see I’m in the Vsphere client, I’m in the Hosting Clusters view, and I’ve clicked on my Vcenter appliance, and if you’re comfortable with this process in Vsphere Six Seven, this is really where it starts to become a little bit different. Vcenter Seven’s configuration process is different than that of Vsphere six Seven.So far, pretty much everything has been the same. But in Vsphere 7, I’ve got, under the configure menu for my Vcenter Server appliance, this little section under Security called Key Providers. And under Key Providers, we are going to add our KMS instance here. Now you can add multiple KMS instances from the same vendor to this one key provider.
So here I’ve clicked on “Key Provider.” Let’s click on “Add.” Standard key provider And you can see that I can give this a name; I’m just going to call it Kms. And you can add multiple key management servers here. So right now it’s just showing me one. But I can add multiple key management servers here. And these multiple instances need to be set up to synchronise keys amongst themselves. And how you do this depends on which KMS vendor you’re utilizing. And it’s important to keep in mind that once we’re done with this, we’re going to have a bunch of virtual machines that are going to have encrypted disks. If I want to be able to decrypt that data, I have to have access to the keys in order to do so. That’s the whole point of encryption: once that data is encrypted, it’s useless to me without the key. And I can’t get that key without having my key management server up and running. And that’s why it’s so important to have multiple Key Management server instances and have them sync keys across all of those instances.
And you really want to carefully plan out that deployment. Don’t put all of your key management servers on the same storage system; don’t have them all running on shared physical hardware. Do your best to eliminate any single points of failure so that your key management servers won’t all be down simultaneously down.So once I’ve got this key provider added and all set up, then I can go ahead to my ESXi host, I can change the host encryption mode, I can allow encryption, and then I can start encrypting the virtual machines and virtual disks. And if you want to dig deeper into this, you can find it all in the Vsphere 7 documentation at docs vmware.com.Simply search for “additional KMS to VCenter server.” You’ll be able to find the appropriate documentation for whatever version of the sphere you’re working with. But just bear in mind that this process is going to vary significantly depending on the type of key management server that you are deploying.
6. Demo: Secure Boot and Encrypted vMotion
The next setting that I want to take a look at is Secure Boot. So the purpose of Secure Boot is essentially validation. The virtual machine is running a legitimate operating system that has not been compromised prior to booting up. So I’m going to right-click this virtual machine here and go to Edit Settings. And on this virtual machine, I’ve got an operating system that supports UEFI Secure Boot. And all of the components of that boot software are signed with certificates.
So there are Microsoft certificates that are here for booting Windows, for example. And the virtual machine’s configuration includes a certificate that is used to authenticate those requests when the virtual machine boots. So it’s basically validating that all of the boot components are legitimate. So under Edit Settings for this VM, I’m going to go to VM Options, and I’m going to expand boot options. And you can see here that the option under “Firmware” is currently set to BIOS. I’m going to change that to EFI. Now, before we make this change, we want to make sure that the virtual machine is on hardware version 13 or later and that the operating system supports UEFI Secure Boot. So now that I’ve changed the boot option to EFI, I can choose whether I want Secure Boot enabled or not.
And now, next time when the virtual machine boots, only components with valid signatures are going to be allowed, and the boot process will stop with an error if it encounters any components that have either an incorrect or an invalid signature. So here I am one more time at the VMware documentation, and this is some of the documentation specific to UEFI Secure Boot. And I just want to focus on these prerequisites for a moment. So in order to enable Secure Boot on a virtual machine, it has to be virtual hardware version 13 or later. And it has to have an operating system that supports UEFI Secure Boot. In order to enable this setting, the virtual machine must be turned on. So I have to validate that my operating system actually supports UEFI Secure Boot before I enable this feature. Now another option that I want to look at while we’re here in our VM Options screen is under VMware Tools. I want to go to the VMware Tools installation options here. And you can see here that I can check the box next to Tools Upgrades. So what this is going to do is ensure that every time this virtual machine is powered on, it checks for the latest version of VMware Tools and ensures that the latest version is installed.
And so this is really handy because some VMware Tools upgrades require a reboot. Well, if I’m already rebooting, I may as well go ahead and install the latest version of VMware Tools. So unless you have some sort of change control policy that forbids this, it is a good option to turn on VMware Tools upgrades every time you power on a virtual machine. And the final option that I want to take a look at while we’re at this screen is encryption. So I want to talk about encrypted Vmotion a little bit here. When you V-motion a virtual machine, you are migrating it from one host to another, as well as moving all of the contents of its memory. And now, with things like long-distance movement, you may potentially be moving those contents of memory over an untrusted network. That’s why encrypted virtualization is important to protect the contents of memory for that virtual machine as it’s migrated over a potentially untrusted network. So, you can see here that encrypted Vmotion is currently set to Opportunistic. And if you click on the little information icon, it will explain the three options that you have here.
Opportunistic is really the most flexible. So if both the source and destination hosts are configured for encrypted V motion, it will happen. The V motion operation will be protected with encryption, but let’s say that the source host supports it but the destination host does not. Then the virtual machine will still be vMotioned, but it’ll be vMotioned in an unencrypted format. The other option here is required. So, this means that V motions will only be successful if an encrypted V motion can occur. This means that both the source and destination hosts must be configured to support encrypted Vmotion. Or I can simply turn off encrypted vMotion. But opportunistic is really the ideal setting in most scenarios, because if encryption can occur, it will. If encryption can occur, the V motion will still work. But if you’re in a highly secure environment, you can also enable the required encrypted Vmotion setting to ensure that only encrypted Vmotions can successfully occur. So that’s how you enable encrypted V motion on a virtual machine.
7. Demo: Working with ESXi 7 Host Firewall and Services
I’m going to start by clicking on hosts and clusters here in my V spare client. And you can see that I have an ESXi host. And on that ESXi host, I’ve clicked on the configure tab. And the configure tab is where you’re basically going to configure everything for this host. So storage, devices, networking, VM kernel ports, physical adapters, and security are all involved. And we’ve got these three areas here that are very important for security.
So at the moment, I want to focus on the firewall and services areas of security. And so, first off, let’s think about the firewall here. This is the ESXi host firewall. It’s built right into the ESXi host. The one most important thing to understand about this firewall is that it doesn’t have any impact on virtual machine traffic. I can have a bunch of virtual machines running on this host. It doesn’t matter what rules I create here in this firewall; they are not going to protect my virtual machines at all. This is a firewall specifically for the ESXi host itself. So if I look at these different types of connections, the ESXi host has a DHCP client where it can automatically get an IP address. The ESXi host might have a VM kernel portmarked for fault tolerance, and it might communicate with other ESXi hosts for fault tolerance, logging, or SNMP. Maybe I have SNMP hosts in my environment. Maybe I have the motion configured so I can migrate VMs from one host to another. So this is all the traffic that the ESXi host itself is generating or receiving.
And that’s what I’m trying to control—the traffic of the ESXi host itself. And so you can see here that I’ve got incoming and outgoing connections where I can control all of this traffic. So let’s focus on SSH. You can see here that I’ve created an allowed IP address range for SSH. By default, everything is set to allow all traffic. Let’s take a look at the SSH rule that I’ve created. So if I click on the SSH server by default, this box is usually checked to allow connections from any IP address. But I’ve actually overridden that, and I’ve specified a certain IP address range here that is going to be allowed to connect to the SSH server of this ESXi host. So let’s go ahead and test it out. I’m going to quickly open up a command prompt here and just type in the IP configuration command. And here you can see the IP address of my computer. So my computer is in this address range, so it should work. So what I’ve done now is launch a very common SSH client called Putty. And I’m going to go into Putty and attempt to connect to this ESXi host over SSH port 22 SSH.I’m going to validate that my firewall is properly configured here, and I’ll go ahead and hit open, and I’m in. So now I’ve got a command prompt open for this ESXi host. I can do things like run ESX top or other commands from the command prompt. I’ve established a valid SSH connection to this ESXi host.
And so that’s the purpose of this firewall. is basically to say, “Hey, the only people who should be opening a command-line session to this ESXi host are in this management network.” Let’s change the network just for the purposes of testing. So I’m changing the network to one that my computer is not a part of. My computer is on the 192.168.8.199 network. I’m changing it. So now if I hit OK here and I launch Putty, I shouldn’t be able to connect to this host anymore. So let’s see what happens. Let’s see if my firewall change successfully prevented me from connecting to this host, and if it can no longer connect to this host via SSH. So that’s the onboard firewall here, and I’m just going to go back into this rule and modify it one more time to fix it. There we go. So now my computer should be able to connect to this ESXi host using SSH, no problem. And as you can see here, there’s all of this type of traffic, so we can really lock this down. For example, this host has a DHCP client. It should be really easy for me to identify my DHCP servers here, or even just the network that they’re on. Fault tolerance: what network are my other ESXi hosts on? Those are the only networks that fault-tolerance traffic should be going to.
What network are my SNMP hosts on? What networks should we be broadcasting to? So this is an important configuration task, and to truly harden my ESXi host, I need to come in here and lock down these firewall rules to permit the appropriate traffic to the appropriate networks. That being said, some of these services may not be necessary at all. So let’s focus on SSH again. But let’s click on the services option here. As you can see, SSH is currently active. This is actually not the default. SSH is stopped by default. So let’s take a look here. Number one, I could simply stop the SSH service if I wanted to. So I’m going to go ahead and stop that SSH service. I’m going to launch Potty one more time. Let’s see what happens here. Am I going to be able to connect to this host via SSH? Nope, the connection was refused. The SSH service is not running. If I go ahead and start the SSH service back up, then it should work just fine. So let’s give it a shot. There we go. And we’re able to connect, no problem, once the SSH service is running. And I can also edit the startup policy for this SSH service so I can say, “You know what? I only want this to be started and stopped manually by default.” Maybe I’ll go ahead and say I want to stop this service.
And I’ll configure the startup policy to say that this should only start and stop manually. So if I reboot this ESXi host, SSH isn’t going to automatically start up. There are other services, like the DCUI, that automatically start and stop with the host, and that’s fine. Certain services, like DCI or load-based teaming for my distributed switches, I want to automatically start whenever my ESXi host boots up. But there are other services that pose a security risk, like the ESXi shell and SSH, and I only want those services to be available if they are manually started. So those are the different services that I can modify here. And if there are any services that I do not intend to use, such as SNMP, I will simply disable them. If I’m not going to join this host to an Active Directory domain, I’ll just leave Active Directory stopped. If I’m not going to use NTP on this host, I’ll simply leave it turned off. Any services that I am not intending to use should be turned off.
8. Demo: Configure Lockdown Mode on an ESXi 7 Host
In this video, I’ll demonstrate how to configure lockdown mode. So with lockdown mode, what we’re hoping to accomplish is that we want to ensure that all of the management traffic that is hitting an ESXi host is coming from Vcenter. Now, there are a few different ways that you can connect to an ESXi host. I can connect to this host using the host client, so I can point my browser to the IP address of this host. I can put in my root credentials, log in, and do all sorts of management tasks locally on this ESXi host. And so that’s one way that I can manage this host. And I’m basically going around V Center; I’m going around V Center, and I’m managing this host directly. SSH is another option that I have. So if I have the SSH service enabled on this ESXi host and I have my firewall properly configured, I can launch an SSH client and connect to this ESXi host. And if I successfully authenticate now, I can manage all sorts of settings on this host from the command line as well.
So what I may want to do is enforce that everybody go through V Center. And the reason that I may want to do that is because the centre gives me permissions and roles and all sorts of granular configurations that I can set up here to ensure that only the correct people are doing the things that they’re allowed to do. And the other thing that VCenter gives me is an audit trail to give me the ability to understand who’s done what and when. So in certain scenarios, turning on lockdown mode may be a great option for me. So I can just right-click this host and go to settings. I could also go to the Configure tab and look under System. Here we see the security profile for this ESXi host. And at the moment, lockdown mode is currently disabled. So let’s take a look. I can enable lockdown mode in normal mode. And so in this scenario, the host is only going to be available if I’m physically sitting at the local console or if I’m connecting to it through the V Center server. So I’m going to go ahead and enable normal lockdown mode. And here I am at my host client one more time, and I cannot log into this host from the host client. Let’s try putty. Let’s see if we can SSH into this host. I’m going to enter myhost’s IP address and try to open a PuTTY session. So I just put in my credentials, and it’s telling me that access is denied. So lockdown mode is working. If I want to modify this ESXi host, I must now use VCenter. Let’s click Edit one more time in lockdown mode. Now, under normal lockdown mode, I can also specify some exception users.
So I’m going to go ahead and add an exception user, and the exception user that I’ve added is root. So let’s go ahead and hit okay here and look at this. Now that my host client is accessible again, I’ll put in my root username and my credentials, and I can get into the host client. If I put in my IP address into Putty, I’ll try and open up an SSH session, put in my root username and my password, and I’m in. So that’s the beauty of having exception users: in the scenario in which Vincent is down, there are still certain users that have the ability to access this ESXi host locally. And that’s really important because if VCenter is down and I haven’t enabled any exception users, the only way that I can manage this host is by physically sitting at the local console. So having those exception users baked in is a really handy thing. OK, so now there’s one other thing that I want to demonstrate. Under normal lockdown mode, the DCUI is still accessible. So here I am at the console of the ESXi host. I’m going to put in my root username and password, and I have the ability to go in here and modify settings like the management network or even reconfigure and potentially disable lockdown mode. I can still do that at the DCUI, the direct console user interface. OK, so now let’s enable lockdown mode. in strict mode. Prior to this, I had enabled it in normal mode. Let’s take a look at the differences in strict mode.
Now, the biggest difference in strict mode is that the DCUI is disabled. So here I am again at the console of my ESXi host, but when I try to login, it’s giving me an authentication denied. So now, even if I’m physically sitting in front of this ESXi host with a keyboard and monitor, I can’t get in. I cannot make any changes here. How about my exception users? What if I try to log into this host using the host client with my root account? Look at that. It still works. I can still get in using my root account that I’ve enabled as an exception user. If I go back to Putty, let’s try and establish an SSH session to this ESXi host and see what happens; I can still get in. So having those exception users defined gives me a little bit of a back door in case VCenter is down. Even in strict lockdown mode, those exception users can still get in and modify that ESXi host and can potentially turn off lockdown mode if I want to do so. If I didn’t have exception users built into the system, say I didn’t have an exception user here and my virtual server went down and I couldn’t get it back up and running, I’d lose access to that ESXi host for good. I couldn’t get to it through the DCY, and I can’t get to it through SSH. It’s inaccessible. And basically, at that point, I’m rebuilding that host from scratch. So be careful with strict lockdown mode. And if you are going to enable strict lockdown mode, I recommend building an exception user in there just in case the centre is down and you need to disable lockdown mode on an ESXi host.
