Two-factor Authentication for vCenter is now Essential

More than ever, organizations need to focus on security in their environments. New cybersecurity threats are endless, and the bad guys are constantly trying new ways to hack into your network, business-critical services, and applications. One of the most common age-old ways cybercriminals compromise networks, and business-critical data is by compromised credentials.

If you think about it, if an attacker gets possession of a privileged user account, it is game over. Instead of needing to find an obscure vulnerability or zero-day attack, they can simply walk in the front door of your environment using stolen credentials. VMware vCenter is the heart of VMware vSphere implementations. It is a crucial piece of the vSphere infrastructure. If compromised, attackers essentially have the heart of your vSphere environment and your workloads.

Setting up two-factor authentication to protect user credentials, especially administrator accounts, is a great way to bolster the overall security of your user accounts. Is it possible to configure two-factor authentication on your vCenter Server? How is this accomplished, and what considerations need to be made?

Passwords Alone are not Enough

The traditional username and password have been around for decades now. Users have long had a username that is usually a combination of their first and last names, either truncated or full names with a period in between. A password is a string of characters that is not viewable or known by anyone but the user.

Despite decades of security evolution and much more powerful applications and enterprise services, surprisingly, the classic username and password are still primarily the way systems are secured today. Why is this worrisome? As mentioned, compromised credentials are one of the most common ways attackers get into environments today.

In the IBM Cost of a Data Breach Report 2021, it noted the following statistics regarding compromised credentials:

• • Compromised credentials initially cause at least 20% of breaches

• • It represents the most common initial attack vector

• • Breached caused by stolen/compromised credentials took the longest number of days to identify

• • Compromised credential breaches took 250 days to identify and 91 days to contain

Why are passwords so easy to compromise? It is due to many different reasons. However, end-users generally tend to choose weak or easily guessable passwords. In addition, many users choose passwords they can easily remember, and they may use this same password everywhere.

Today, this problem is magnified as organizations have users create logins to a myriad of services, both on-premises and in the cloud. Unfortunately, human nature being what it is, users often choose a password they can reuse across the services found in their digital workspace.

It leads to weak user logins associated with business-critical data used across many services. Even though administrators better understand why security is essential compared to normal end-users, they are also guilty of choosing weak passwords and reusing them across their privileged accounts in the environment, including VMware vCenter Server. In many environments, network segmentation is either poorly designed or non-existent, leading to attackers having easy lateral movement to compromise vCenter, ESXi, and other infrastructure.

Phishing and brute force attacks

Attackers are very cunning and use sophisticated ways of compromising credentials. The most common types of password attacks are:

• • Phishing attacks

Although one of the older types of attacks, phishing attacks are still surprisingly effective. Attackers craft very legitimate-looking emails and masquerade these as being from legitimate or known vendors or businesses the users are familiar with. The phishing email may request the user enter their current password to review their security information.

Once the user enters the current password, the attacker now has access to a legitimate password for a particular service or solution associated with the organization. Phishing attacks can easily harvest credentials used by an organization and then use these for malicious purposes.

If you manage Microsoft 365, a dedicated email security service is vital for companies to provide the most effective level of security. Hornetsecurity is the leading cloud email security provider and offers a free trial of its product range.

• • Brute force attacks

Brute force attacks try many different passwords against a user account to compromise user accounts using common passwords, easily guessed passwords, or even breached passwords. Breached password lists exist on the dark web and even from legitimate channels that contain passwords that have been obtained in actual breach events.

Attackers know that even different users think alike. Therefore, breached passwords are often tried against other user accounts to find accounts using the same passwords. If enough user accounts are scanned, attackers generally will have success in finding other user accounts using the same character transformations, phrases, and strings.

• • Password spraying

Password spraying is another form of password attack where attackers choose a few common passwords and spray these against multiple accounts, even across different organizations. These attacks are often highly successful and do not trigger safety mechanisms such as account lockouts in Active Directory since they attempt very few passwords for each user account.

VMware vCenter Server Access is Often Linked to Active Directory

Attackers often target Microsoft Active Directory, the most popular enterprise directory service in use today. Microsoft Active Directory typically houses all the usernames and passwords used on-premises or federated to cloud environments. Linking services and solutions to a centralized identity directory has many advantages from a management perspective and security benefits, such as centralized password policies, etc.

IT admins commonly connect vCenter Server authentication with Active Directory. This approach allows one set of credentials to be used, both for Windows logins and accessing vCenter Server, among other services. However, the downside is if attackers compromise legitimate Active Directory credentials, they now have access to all the services using Active Directory authentication, including vCenter Server.

Also, instead of using role-based access where credentials have only the access needed in vSphere, admins may grant their Domain Admin account administrator privileges in vCenter Server. Attackers who compromise an account with both domain admin privileges and vSphere administrator permissions have the “keys to the kingdom.” Active Directory users delegated high-level permissions inside vSphere sweeten the deal for attackers who compromise their accounts.

Linking vSphere with Active Directory user accounts in itself is not necessarily a bad practice. Rather, it is the lack of following other best practices when doing so. These include role-based access, not using domain admin user accounts in vSphere permissions, and failing to enable multi-factor authentication.

Initial Access Brokers (IABs) and Ransomware

An extremely alarming trend on the dark web is a new sinister entity – the Initial Access Broker (IAB). What is it? The Initial Access Broker is a new criminal entity that specializes in selling legitimate and valid credentials to ransomware gangs and other hackers looking to launch a ransomware attack.

Initial Access Brokers take the “leg work” out of finding compromised credentials or infiltrating a network and doing this the hard way. Instead, IABs provide credentials for sale on the dark web. The credentials offered may include credentials to:

• • Virtual Private Network (VPN) connections

• • Remote Desktop Services (RDS) servers

• • VMware Horizon connections

• • Citrix

• • Cloud services

• • VMware vSphere

The IAB will carry out the operation of infiltrating networks or using phishing campaigns to harvest credentials. These credentials are then posted with the offer online, stating the type of access and the user’s privilege level. IAB operators usually base the price charged for the access credentials based on the privilege level of access and the company’s revenue.

These pieces of information are essential for an attacker looking for the next target of a ransomware attack. Additionally, the size and revenue stream of the targeted organization will help determine the ransom demanded after a successful ransomware attack and the likelihood the business will be able to pay the ransom.

The IAB provides the credentials needed for an attacker to carry out the end goal – a ransomware attack. Ransomware is an increasingly dangerous plague for businesses today as attacks are increasing, and the damage they can bring is unprecedented.

Like IABs, there is another development on the dark web that is helping to facilitate the increase in attacks. Ransomware-as-a-Service (RaaS) has commoditized ransomware for criminals across the board. In the past, carrying out and operating a successful ransomware attack took a certain level of skill and prowess in first developing the malicious software, then carrying out the attack, and finally, collecting the ransom.

You can think of Ransomware-as-a-Service (RaaS), much like Google Workspace or Microsoft 365. It is Software-as-a-Service, except in the case of RaaS, it is malicious software. Nevertheless, the principle is the same. With RaaS, attackers who buy into the RaaS service don’t have to know the ransomware’s inner workings or all the technical details. These are handled by the ransomware group operating the RaaS service. Instead, the affiliate attacker can simply carry out an attack with proven, mature ransomware. The ransomware group receives a percentage of the ransom payment if the attack is carried out successfully.

Both the IAB and the Ransomware-as-a-Service (RaaS) development on the dark web has led to the proliferation of ransomware attacks seen today and the increase in successful attacks. Is VMware vSphere really vulnerable to a ransomware attack? How can a ransomware attack be carried out on a VMware vSphere environment?

Ransomware That Attacks VMware vSphere

It is no longer just a “theory” that ransomware can attack VMware vSphere environments. Undoubtedly, you may have started to see in the news, Reddit, and other places where vSphere admins have started to see firsthand ransomware that attacks VMware vSphere environments.

A thread that popped up last year on Reddit that received countless views and comments from concerned vSphere admins is found here:

• • Witnessed my first ESXi ransomware. Crypts VMs at datastore level. : sysadmin (reddit.com)

The post mortem to the above ransomware thread can be read here:

• • The ESXi ransomware postmortem. : sysadmin (reddit.com)

If you read through the post mortem of the above-mentioned ESXi ransomware account, you will find on step 3 of the attack post mortem:

• • Attackers gained access to hosts that had access to ESXi’s management subnet. They already had AD admin privileges.

In the attack, we can assume that the hackers had admin-level domain accounts with admin-level vSphere permissions, based on how the attack was carried out. Sophos also recently detailed this type of attack on ESXi servers. In details of the attack, Sophos noted:

• • The attackers broke into a computer using a compromised TeamViewer account

• • The computer was running under a domain administrator account

• • 10 minutes later, the attackers used Advanced IP Scanner to scan the network for targets

• • The SSH shell was running on the ESXi hosts

• • They installed Bitvise

• • Then, using a Python script, the virtual machine disk files (VMDKs) were encrypted at the datastore level

While the attacks noted made use of direct access to ESXi hosts, VMware vCenter Server makes a perfect target since through vCenter Server, all ESXi hosts are vulnerable to an attack if vCenter is compromised. Additionally, it emphasizes the importance of protecting user accounts across the entire landscape of your infrastructure. Going back to the post from Sophos, they gave the following security advice:

“Administrators who operate ESXi or other hypervisors on their networks should follow security best practices. This includes using unique, difficult to brute-force passwords and enforcing the use of multi-factor authentication wherever possible.”

For years now, vSphere has not been on the radar of ransomware groups. However, it seems in the past year or so, vSphere environments have moved up quickly on the radar of ransomware groups and attackers in general. It often represents an easy target with poor password practices and other factors at play.

What is Two-Factor Authentication (2FA)?

First, we need to understand what two-factor authentication is and why it helps secure user accounts. Two-factor is one variety of multi-factor authentication (MFA). Multi-factor authentication (MFA) refers to an authentication scheme that requires more than one factor of information to authenticate. For example, a password is a single factor used to authenticate a user as being who they say they are.

Common password factors generally include three types:

• • Something you know

• • Something you are

• • Something you have

A password is something you know. A fingerprint is something you are. A one-time password delivered or generated using a smartphone is something you have.

The problem with a single factor is it only requires a single piece of information to establish and verify user identity. Enabling multi-factor authentication on a user account makes compromising the account exponentially more difficult as it requires multiple components of information to establish identity.

Two-factor authentication (2FA) is the most popular form of multi-factor authentication and effectively bolsters account security by combining two factors. Two-factor authentication requires something you know, a password, and something you possess, a one-time passcode. With two-factor authentication, you need the one-time passcode in addition to the correct password to authenticate successfully.

The most common implementation of two-factor authentication involves using a smartphone to provide a one-time passcode received through text message or generated using an authenticator app. The key benefit when using two-factor authentication is an attacker who compromises a user account password does NOT have all the required factors to complete a successful authentication. Without successfully authenticating, an attacker is limited in what they can do.

Just about any best practice guidance available today detailing how to bolster cybersecurity will include implementing two-factor authentication across your user accounts. With two-factor authentication enabled, the possibility of a successful ransomware attack is dramatically reduced. While it is not the only cybersecurity measure that needs to be taken to protect against ransomware, it is one of the most important.

In addition to the positive impact on your organization’s security, multi-factor authentication is required by compliance frameworks. Examples include compliance frameworks such as PCI DSS 3.2 and NIST 800-53 revision 4. So, there are many reasons for organizations to implement multi-factor authentication across the board, including vCenter Server.

Securing vCenter Login with 2FA

Prior to vSphere 7.0, vCenter Server included a built-in identity provider that VI admins have known and are familiar with for years now (since vSphere 6.0). By default, vCenter uses the “vsphere.local” domain (can be changed) as an identity source. You could also configure the built-in identity provider to connect to:

• • Active Directory with LDAPS/S

• • OpenLDAP/S

• • Integrated Windows Authentication (IWA)

Organizations could configure logging into vCenter Server with Active Directory accounts using this configuration. In vSphere 7, VMware is making it much easier to implement multi-factor authentication by introducing identity federation. Identity federation introduces the capability to connect vCenter Server to an external identity provider, which allows federating the authentication process for vCenter Server to the identity solutions in use in the enterprise today.

Below is a screenshot from the Single Sign On > Configuration > Identity Provider screen found in vCenter Server 7.

vCenter Server 7 Identity Provider configuration

You can click the Change Identity Provider link to change or view the current provider. Note the default Microsoft ADFS configured in the vCenter Server 7 configuration.

Viewing and configuring the identity provider in vSphere 7 vCenter Server

This new feature helps centralize the vCenter Server authentication process with identity federation solutions in today’s enterprise, such as Active Directory Federation Services (ADFS). More importantly, with the discussion around multi-factor authentication, this feature opens up capabilities such as multi-factor authentication, including the two-factor authentication approach.

The infographic below from VMware shows the workflow of the identity federation process in vCenter Server.

Identity Federation workflow found in vSphere 7 (courtesy of VMware)

1. 1. The vSphere Client connects to the Identity Provider
   2. The vSphere Client redirects logins to the Identity Provider’s login page
   3. The end-user logs in with their normal user credentials
   4. They will be prompted with multi-factor authentication if this is configured
   5. Once authenticated, the identity provider redirects the session back to the vSphere Client
   6. The session will have the authentication token provided from the identity provider that authorizes access
   7. The user will proceed normally in the vSphere Client session, now authenticated

Currently, the only identity provider natively supported at the time of this writing is Active Directory Federation Services (ADFS). However, VMware will no doubt extend the list of available identity providers natively supported in future versions of vSphere, as noted in the official blog post:

“vSphere 7 initially supports ADFS because it represents what a large portion of our customers have and can easily use. More options to come as we teach vSphere more authentication “languages.”

VMware has built the new identity federation capability in line with standard protocols which is great as this will allow a much wider variety of identity providers. The vSphere 7 identity federation feature uses industry-standard protocols, including OAUTH2 and OIDC. However, it will still take time to integrate various identity providers in vSphere as, even with the open standards, they each use different identity “schemas.”

Available Options for vCenter – Are There Free Options?

As mentioned above, the option currently “included” with vCenter Server 7 identity federation is Active Directory Federation Services (ADFS). Additionally, VMware mentioned they include AFDS as the first identity federation option as this is the solution most of their enterprise customers are currently using.

However, Active Directory Federation Services (ADFS) may not be deployed in all customer environments. In addition, configuring Active Directory Federation Services (ADFS) to enable 2FA for your vCenter Server would involve a tremendous amount of complexity simply to enable 2FA on vCenter. ADFS configuration comes with additional infrastructure requirements and its own configuration, troubleshooting, and lifecycle maintenance.

While there are no specific licenses for ADFS itself, Windows licensing is needed for the ADFS servers and there are additional infrastructure resources required to provision the infrastructure. It is a great option to go this route for 2FA in vCenter if ADFS is already in place. Often this is used to federate user logins for Microsoft Office 365 and other cloud services.

Are there free options available for setting up 2FA with vCenter Server? You can set up two-factor authentication with vCenter Server without using the new identity federation functionality in vSphere 7. Duo Security offers a free version of their solution that allows creating a simple two-factor application that can introduce a two-factor prompt with the vSphere Client.

Does Two-Factor Authentication Impact Automation?

A question comes up with two-factor authentication and automated processes. How do the two coincide? It is a great question and one that needs to be considered when implementing two-factor authentication with automated processes running in the environment.

Two-factor authentication can potentially cause challenges for automated processes depending on how long the authentication token is maintained. The automated process would likely need to be reauthenticated each time the process runs. Some two-factor authentication solutions, such as Duo, OKTA, and others, allow admins to bypass two-factor prompts based on specific criteria, such as a user, an application, source networks, etc.

Using these specialized exemptions from two-factor prompts can be used judiciously throughout the environment for automated tasks and the user contexts these run. However, it is a double-edged sword. Opening or bypassing two-factor prompts are chinks in the armor that two-factor authentication provides in the environment.

However, usually, there is a “sweet spot” of exemptions, bypasses, and other rules that can be put in place that still provide a good balance. A few best practices to think about with two-factor and automation include:

• • Never run automated processes under a normal interactive user login

• • Use special-purpose service or automation accounts

• • Rotate the passwords for the automated service accounts frequently

• • Combine automated tasks with secrets management from the likes of Hashicorp Vault or another solution to have the credentials retrieved real-time as opposed to hardcoded in automated tasks or processes

• • Have automated solutions positioned on their own segregated network and only accessible using a Privileged Access Workstation (PAW)

vSphere Authentication with vCenter Single Sign-On and SAML

Another login mechanism in the enterprise for accessing the vSphere environment through vCenter Server is Sign Sign-On (SSO). Does vSphere support logging in with Single Sign-On (SSO)? Yes, it does. VMware vCenter Single Sign-On protects your environment by seamlessly allowing vSphere components to communicate using a secure token mechanism. It is much more secure than requiring users to authenticate separately to each component.

As mentioned earlier, the Single Sign-On domain is the “built-in” identity source found in vSphere 6.0 and higher that defaults to vsphere.local during installation. You can see the Single Sign-On domain configured when you login to the VAMI (vCenter Server Appliance Management Interface), under the Summary dashboard.

Viewing the vCenter Server Single Sign-On domain in the VAMI interface

The vCenter Single Sign-On solution uses a combination of:

• • STS (Security Token Service)

• • SSL (secure communication)

• • Active Directory or OpenLDAP for user authentication

You can also add a SAML service provider to vCenter Single Sign-On solution with an external SAML Service Provider, or use a VMware-native SAML solution, such as is found in the vRealize Automation solution.

How to Set up vCenter Server Two-Factor Authentication

Let’s look at the process to configure the ADFS connection for vCenter Server. In the ADFS management console, create a new Application Group. Use the “Server application accessing a Web API” template.

Creating a new application group in ADFS

In the screen below, you need to enter the Redirect URIs that point back to your vCenter Server. Also, copy the Client Identifier for use later.

Add the vSphere redirect URIs

Where do you get the redirect URIs? In the Identity Provider configuration, you can click the informational button beside the Change Identity Provider link and copy both for use in the ADFS configuration.

Gathering your redirect URIs from your vCenter Server

On the Configure Application Credentials screen, click the checkbox next to Generate a shared secret.

Generate a shared secret

Enter the client identifier that you copied from the Server application screen.

Configure the WebAPI

On the Apply Access Control Policy screen, clik the Permit everyone and require MFA option. This is one of the key pieces of the configuration that enables MFA for your vCenter Server login.

Configure Access Control Policy in ADFS

Make sure the allatclaims and openid options are selected.

Configure application permissions

Review the options configured on the Summary screen and click Next.

Summary for creating the new application group

The new application group is created successfully.

Application group is created successfully in ADFS

Now, we need to add a few claim rules to the application. Navigate to the Properties of your Application Group we just created.

Viewing the properties of the ADFS application group

Navigate to the Issuance Transform Rules and select Add Rule.

The three we add will be from the template Send LDAP Attributes as Claims. Choose Active Directory as the Attribute store. The first set of configurations for LDAP Attribute and Outgoing Claim Type are:

• • Token-Groups – Qualified by Long Name

• • Group

Create a new Claim Rule for groups

The next pair includes:

• • User-Principal-Name

• • Name ID

Create a new Claim Rule for Name ID

Finally, map the following:

• • User-Principal-Name

• • UPN

Create a new Claim Rule for UPN

Your Web API properties should look like the following.

New ADFS Web API properties for vCenter 2FA

We have all the information needed to populate the vCenter Server identity provider configuration except for the open-id configuration URL. To obtain that URL, use the cmdlet:

• • Get-AdfsEndpoint | Select FullUrl | Select-String openid-configuration

Make sure to only select the URL starting with the https:// and do not include the final “}” from the output.

Getting your openid-configuration from your ADFS server

Now, let’s go back to the identity provider configuration and choose ADFS server. We can now populate the information needed, including:

• • Client identifier

• • Shared secret

• • OpenID Address

How to Configure vCenter Two-Factor Authentication in VMware

Now, to configure vCenter two-factor authentication in VMware using the ADFS functionality built into vSphere 7, we just need to point to the ADFS configuration group application we have configured for MFA in the ADFS configuration above. Navigate in the vSphere Client to Administration > Single Sign On > Configuration > Identity Provider > Identity Sources > Change Identity Provider.

Change Identity Provider in the Identity Provider

Select the Microsoft ADFS option.

Choose the Microsoft ADFS option

Next, enter the relevant ADFS information from the new ADFS group application created earlier.

Populate your vCenter Server identity provider with the ADFS information

On the Users and Groups screen, populate the required information with the user with permissions to search Active Directory.

Configure your users and groups for searching Active Directory

Click Finish to finalize the configuration of the identity provider for Active Directory Federation Services.

Review and confirm the ADFS identity provider

To ensure you have your ADFS configuration in place for multi-factor, you can follow the Microsoft documentation here:

• • Configure AD FS 2016 and Azure MFA | Microsoft Docs

How to Manage Two-Factor Authentication for VMware

The management of the two-factor authentication itself will be handled at the ADFS layer and/or Azure MFA. Basically, vCenter hands over the authentication to ADFS, once the Identity Provider configuration is in place, pointed to ADFS. Once authentication is configured and verified in vSphere, you can manage the ADFS implementation using the official Active Directory Federation Services (ADFS) management console found under “Windows Administrative Tools”:

• • Microsoft.IdentityServer.msc

Azure MFA integration will be managed using your Azure Portal:

• • https://portal.azure.com

Troubleshooting 2FA in vCenter Server

Since the key to the new vCenter Server 7.0 Identity Provider 2FA solution is ADFS, troubleshooting 2FA in vCenter Server will revolve around ADFS troubleshooting. A good resource for troubleshooting ADFS login issues, including MFA is found on the official Microsoft documentation site:

• • ADFS SSO troubleshooting – Windows Server | Microsoft Docs

What are some common ADFS errors you might encounter:

• • ADFS error 180 and endpoints missing

• • ADFS 2.0 certificate error

• • ADFS 2.0 error 401

• • ADFS 2.0 error: This page cannot be displayed

• • ADFS 2.0 service fails to start

Specific documentation around Azure multi-factor authentication troubleshooting can be found here:

• • Troubleshoot Azure Multi-Factor Authentication issues – Active Directory | Microsoft Docs

To protect your VMware environment, Altaro offers the ultimate VMware backup service to secure backup quickly and replicate your virtual machines. We work hard perpetually to give our customers confidence in their backup strategy.

Plus, you can visit our VMware blog to keep up with the latest articles and news on VMware.

So, How Essential is 2FA?

A mountain of cybersecurity evidence, research, and best practice documentation points to the fact that enabling multi-factor authentication is a great way to decrease the likelihood of suffering from a cyberattack drastically. For example, ransomware attacks often start with stolen, leaked, or compromised credentials. As a result, the bad guys have an easy way into the network without elaborate schemes to hack into the network using other methods.

Multi-factor authentication (MFA) is a form of authentication that requires the user to prove their identity using multiple “factors” of information. These include something you know, something you are, and something you possess. Two-factor authentication is a popular combination of two factors of information, commonly something you know (password) and something you possess (a phone that receives or generates a one-time passcode).

Can ransomware affect VMware vSphere? Unfortunately, yes, it can. Ransomware groups are explicitly targeting vSphere environments using malicious Python scripts to encrypt virtual machines at the datastore level. As a result, many security companies see an alarming increase in attacks on ESXi in the enterprise.

Almost all the ransomware attacks on vSphere start with compromised credentials to some degree. Poor cybersecurity hygiene in many environments, lack of role-based permissions in vSphere, and domain admin credentials added to vSphere administrator permissions lead to easy vSphere targets.

A great way for vSphere administrators to bolster security for their vSphere environments is to implement security best practices in the environment. It includes securing the vSphere management network, turning off SSH access, using lockdown mode in ESXi, and also implementing two-factor authentication.

VMware vSphere 7 allows VI admins to add external identity sources to handle authentication requests. This new functionality makes it possible to connect vSphere environments into existing authentication providers that already can perform MFA. As shown in the walkthrough in this article, VI admins can now integrate with existing authentication providers, such as Active Directory Federation Services (ADFS). VMware has plans to add additional identity providers in the future to provide more options with the external identity providers.

However, without the new functionality, customers can add two-factor authentication to vSphere without the need for the external identity provider configuration, which opens up the opportunity to use free tools to provide 2FA in vCenter Server.