vSphere 7’s vCenter Server Identity Provider Federation feature allows for MFA

Reading Time: 8 minutes

Virtualizing Domain Controllers on vSphere

In this series on virtualizing Active Directory on VMware vSphere, we’ve discussed earlier how to set up a straight-forward vCenter delegation model for running virtual Domain Controllers safely. Today, I want to discuss a new feature in VMware vSphere 7 that improves the lives of Identity and Access Management (IAM) professionals working with both technologies: vCenter Server Identity Provider Federation.

 

Straight-forward vCenter Delegation

Deji Akomolafe, Matt Liebowitz and I have presented on virtualizing Domain Controllers at VMware VMworld events for the last years. We also conducted many Ask the Experts session. The most common question we get after the presentation is how to provide a robust role-based access control solution.

Many organizations have standardized on Active Directory as their single source of Identity and Access. Through group memberships, access is granted to functionality, based on roles. It is common to provide the same role-based access to vCenter. That way, vSphere admins can manage their VMware implementations by simply signing in with the same credentials as they use everywhere; their Active Directory credentials.

By leveraging VM Encryption and the No Cryptography admin role, a straight-forward vCenter delegation model can be built for running virtual Domain Controllers safely.

However, this model with role-based access control (RBAC) based on Active Directory or any LDAP v3-compatible identity store has a major flaws in today’s reality: Multi-factor Authentication (MFA) is limited.

When you build a role-based access control (RBAC) model, based on based on Active Directory or any LDAP v3-compatible identity store, multi-factor authentication is limited to smart cards.

Smart Cards require a robust Public Key Infrastructure (PKI) implementation and solid processes to provide the required authentication assurance levels. In today’s reality, organizations have embraced multi-factor authentication with far more cost-effective and user-friendly methods, compared to smart cards. These solutions are often not targeted at securing the interactive logon, but access to functionality like apps and services.

 

Solving Authentication Challenges with Active Directory Federation Services (AD FS)

Many organizations have solved the identity challenge with identity federation. With solutions like Active Directory Federation Services (AD FS), organizations can safely provide access to people in other organizations they have a relationship with. This relationship is based on open standards, secured with cryptography and sufficiently flexible to allow for business logic, access translation and the minimum amount of information exchanged.

 

VMware vSphere 7 and federation

vCenter in VMware vSphere 7 introduces support for role-based access control (RBAC), based on a relationship with Active Directory Federation Services (AD FS), running on Windows Server 2016, and above.

Pros

When organizations have deployed Active Directory Federation Services (AD FS) with a multi-factor authentication method, they can reuse this method as a requirement for signing into vCenter. Multi-factor authentication as a requirement increases the level of information security, as the identity of the admin is additionally verified beyond username and password; both pieces of information that can be leaked, breached and eavesdropped.

Additionally, sign-ins from your organization’s vCenter admins can have their authentication requests limited to specific IP addresses through AD FS access control policies.This aids in enforcing the use of privileged access workstations (PAWs).

Cons

There are more dependencies when using AD FS for single sign-on to vCenter. When the multi-factor authentication fails, people will no longer be able to sign in. When the connection between AD FS and Active Directory breaks, when the AD FS implementation isn’t reachable, and when AD FS is simply down, the fall-back root or administrator@vsphere.local account needs to be used to sign in.

Additionally AD FS servers need to be operated as Domain Controllers from the perspective of the vCenter admins. In the Active Directory tiered administration model, this means AD FS also needs to be deployed in Tier 0. From a vCenter point of view, this means the AD FS servers also need to be deployed with VM encryption.

Identity Provider Federation in VMware vSphere 7 currently only works with Active Directory Federation Services (AD FS) on Windows Server 2016 and Windows Server 2019. If your organization runs an AD FS implementation with a lower version, it needs to be upgraded.

vCenter does not currently allow the use of both Active Directory and AD FS as Identity Providers for one vCenter implementation. If you want to use AD FS and are currently using Active Directory for single sign-on, you’ll have to remove the Active Directory-based access controls and build new AD FS-based controls using the root or administrator@vsphere.local account.

 

Implementing Identity Provider Federation for your organization’s vSphere admins

There’s a step-by-step available for implementing the vCenter Server Identity Provider Federation feature to require multi-factor authentication from your vSphere admins.

Getting ready

It starts with the following requirements:

Creating a service account and group

To implement the vCenter Server Identity Provider Federation feature, we need a group in Active Directory that will serve as the target audience. We’ll also need a service account with read access (with default settings, this is true for every user object). Perform the following two lines of Windows PowerShell on a Windows Server installation that is a Domain Controller, or on a domain-joined Windows (Server) installation with the Windows PowerShell module for Active Directory installed:

Import-Module ActiveDirectory

New-ADUser -Name "Svc_vSphereADFS" -Path "CN=Users,DC=domain,DC=tld" -GivenName "vSphere AD FS" –Surname "Serivce Account" -sAMAccountName "DOMAIN\Svc_vSphereADFS"

Set-ADAccountPassword -Identity "CN=Svc_vSphereADFS,CN=Users,DC=domain,DC=tld" -NewPassword (ConvertTo-SecureString -AsPlainText "Passw0rd!" -Force)

Enable-ADAccount -Identity "CN=Svc_vSphereADFS,CN=Users,DC=domain,DC=tld"

New-ADGroup -GroupCategory "Security" -GroupScope "Global" –Name "vSphere admins" -Path "OU=Organizational Unit,DC=domain,DC=tld" -SamAccountName "vSphereAdmins"

 

Collecting information from vCenter

Next, we need to collect some information from vCenter:

  • Sign in to the vSphere Client to the vCenter Server. Use an account with the VcIdentityProviders.Manage privilege to do so. The built-in root and administrator@vsphere.local accounts have this privilege.
  • From the Home menu, select Administration.
  • Under Single Sign On, click Configuration.
  • Select the Identity Provider tab and obtain the Redirect URIs by clicking the informational i icon next to the Change identity provider link.
    The two Redirect URIs are displayed in the pop-up banner.
  • Copy both URIs to your documentation.
  • Close the pop-up banner.

Creating the Application Group in AD FS

Next, perform the following steps on an AD FS server running Windows Server 2016, or up, using the two Redirect URIs we just collected from vCenter:

Note:
If the AD FS farm utilizes a Windows Internal Database (WID) to host the ADFSConfiguration database, perform these steps on the Primary Server. If the AD FS farm utilizes SQL Server, perform these steps on any of the AD FS servers in the farm.

  • Open AD FS Management (Microsoft.IdentityServer.msc).
  • In the left navigation pane, select Application Groups.
  • In the list of available actions in the right Actions pane, select Add Application Group.
  • Enter a Name and optionally a Description for the new application group.
  • In the Template list, under Client-Server applications, select the Server application accessing a web API type.
  • Click Next.
  • Copy the value in the Client Identifier field to your documentation.
  • Enter the vCenter Redirect URIs that were given in the vCenter Identity Provider configuration. These Redirect URIs must be exact; otherwise, the vCenter login may not work with ADFS.
  • Click Next.
  • Check the option to Generate a shared secret,
  • Copy the value to your documentation.
  • Click Next.
  • Add an Identifier value that is equal to the Client Identifier from step 7.
  • Click Next.
  • Under Choose an access control policy, select Permit everyone and require MFA.Note:
    If you do not want to require multi-factor authentication from vSphere Admins through a pre-configured AD FS multi-factor authentication adapter, select the built-in Permit everyone access control policy or an access policy created earlier with the specific access controls your organization requires.
  • Click Next.
  • On the Configure Application Permissions page, under Permitted scopes, make sure openid and allatclaims are checked.
  • Click Next.
  • Review the summary and click Next to create the Application Group.
  • Click Close to complete the wizard

The Application Group is now created and is listed in the Application Groups pane.

Configuring the claim token contents

Now, we need to populate the user claim tokens with the appropriate claim types during authentication requests. By default, only mechanical claim types are present in claim tokens. We need to add the claim types vCenter expects:

  • Select the newly created Application Group
  • Select Properties from the list of available actions from the Actions pane.
  • Select the Web API entry under Applications and click Edit.
  • Go to the Issuance Transform Rules tab and add each of the following three rules:
    • Group Rule
      • Click Add Rule.
      • Under Claim rule template, select the option Send LDAP Attributes as Claims and click Next.
      • Enter a name for the claim rule.
      • Under Attribute store, select Active Directory.
      • In the mapping table on the first row, under the LDAP Attribute column, select the Token-Groups – Qualified by Long Domain Name option.
      • In the mapping table on the same row, under the Outgoing Claim Type column, select the Group option.
      • Click Finish.
    • Subject Rule
      • Click Add Rule.
      • Under Claim rule template, select the option Send LDAP Attributes as Claims and click Next.
      • Enter a name for the claim rule.
      • Under Attribute store, select Active Directory.
      • In the mapping table on the first row, under the LDAP Attribute column, select the User-Prinicipal-Name option.
      • In the mapping table on the same row, under the Outgoing Claim Type column, select the Name ID option.
      • Click Finish.
    • UPN Rule
      • Click Add Rule.
      • Under Claim rule template, select the option Send LDAP Attributes as Claims and click Next.
      • Enter a name for the claim rule.
      • Under Attribute store, select Active Directory.
      • In the mapping table on the first row, under the LDAP Attribute column, select the User-Prinicipal-Name option.
      • In the mapping table on the same row, under the Outgoing Claim Type column, select the UPN option.
      • Click Finish.
  • Click OK to save and close the updated Web API properties window.
  • Click OK again to close the Application Group properties window.

In order to configure AD FS federation with vCenter, you will need to know your AD FS server's OpenID Configuration URL. To obtain the OpenID Address for your AD FS server run the following line of Windows PowerShell:

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

Copy the URL that is returned (select only the URL itself, not the closing bracket or the initial "@{FullUrl=" part. Add this URL to your documentation as the OpenID address.

Configure Identity Provider Federation in vCenter

Next, perform the following steps to configure the vCenter side of things:

  • Return to the Identity Provider tab in the vSphere Client.
  • Click the Change identity provider link.
    The Configure Main Identity Provider wizard appears.
  • In the Configure Main Identity Provider wizard  window, select Microsoft ADFS.
  • Click Next.
  • Enter the information that you have gathered previously for the following text boxes:
    • Client Identifier
    • Shared Secret
    • OpenID Address of the AD FS server
  • Click Next.
  • Enter user and group information for the Active Directory over LDAP connection to search for users and groups.
    • Enter "CN=Organizational Unit,DC=domain,DC=tld" as the Base distinguished name for groups.
    • Enter svc_vSphereADFS as the Username.
    • Enter Passw0rd! as the Password.
    • Enter the Domain Controller name as the Primary server URL in the notation ldap://DC01.domain.tld:3268.
    • Enter another Domain Controller name as the Secondary server URL in the notation ldap://DC02.domain.tld:3268.
    • Click Next.
  • Review the information.
  • Click Finish
  • From the Home menu, select Administration.
  • Under Single Sign On, click Users and Groups.
  • Click the Groups tab.
  • Click the Administrators group and click Add Members.
  • Select Microsoft ADFS from the drop-down menu.
  • In the text box below the drop-down menu, enter the first few characters of AD FS group that you want to add then wait for the drop-down selection to appear.
  • Select the AD FS group and add it to the Administrators group.
  • Click Save.

 

Concluding

Enable multi-factor authentication for accessing vCenter by using AD FS and the new vCenter Identity Provider Federation feature introduced in vSphere 7.

the additional identity verification through your multi-factor authentication infrastructure tied to AD FS allows you to stop worrying about unauthorized access.

Further reading

Access Control Policies in Windows Server 2016 AD FS
How to enable OpenID Connect in ADFS 2016 for vCenter Server (78029)
Configure vCenter Server Identity Provider Federation (vmware.com)

Posted on October 23, 2020 by Sander Berkouwer in Active Directory Federation Services, Delegation of Control, VMware, VMware vExpert

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.