vSphere 8.0 Update 2: Federated Authentication with Azure Active Directory

Introduction

 At the 2023 VMware Explore event in Las Vegas, we announced the launch of vSphere 8.0 Update 2. Among all the exciting new features, one, in particular, relates to the way users authenticate to vCenter. We are thrilled to introduce this  feature: vCenter Server 8.0 Update 2 now supports federated authentication with Azure Active Directory.

Let's explore a bit about this integration, and how to get it enabled. 

What are the benefits of adopting external identity providers?

By using external identity providers organizations will benefit from:

• Taking advantage of current identity provider infrastructure.
•  Facilitating Single Sign-on within their organization.
• Aligning with functional separation of duties: infrastructure and identity provider administrators. 
• Enabling multi-factor authentication mechanisms already available in the identity provider of choice.

 

 

Identity providers supported with vSphere 8.0 U2

Even though this writing focuses on Azure Active Directory integration, it is worth to recap all the options currently available for authentication as of  vCenter Server 8.0 U2.

 

 

 

 

How does it work?

The architecture behind either of the external identity provider federation options, Azure AD and Okta is exactly the same from a vCenter server perspective, we are utilizing VMware Identity Services. Here we will continue talking about Azure AD, but the same concepts apply for Okta ID.

There are 2 phases in this integration:

• User authentication.
• User & group synchronization.

 

 

User Authentication: OIDC

When vCenter receives a user authentication login attempt using a domain registered with the external identity provider, it will redirect the authentication request via a OIDC protocol token request generated by VMware identity Services. Once Azure AD has successfully authenticated and validated the user, it will return a token to VMware identity Services. The rest will go as normal.

 

User/Group Lookup: SCIM

User/groups are pushed from the identity provider to vCenter using SCIM protocol. This applies for user and group searches within vCenter console.

 

How can I enable this feature?

Funny you asked, well we imagined you asking it.

 We have recorded a video showing the integration process:

 

 

Note: We are including steps taken within Azure AD console in an attempt to facilitate the implementation process by an integrated illustration. All features, menus, images, names, within the Azure AD console can be changed by Microsoft at anytime. 

 

Prerequisites

These are the prerequisites that you will encounter in the Configuration Wizard. While you can create the OIDC and SCIM applications beforehand, you will still need to modify them to include certain information, such as the secret, which you will only receive during the vCenter Server Identity Provider configuration.

• You are customer of Microsoft and have a Azure AD account.
• You have created enterprise (non-gallery) application with OpenID Connect as a sign-on method.
• Add authorization code, refresh token and resource owner password as grant types in the created application.
• For user and group sync, you need to configure VMware Identity Services Gallery
• Application for SCIM 2.0 provisioning in Azure AD with OAuth 2.0 Bearer Token.
• vCenter server is connected to Azure AD discovery endpoint and authorization, token, logout, JWKS and any other endpoints advertised in the discovery endpoint metadata
• You need the VcIdentityProviders.Manage privilege to create, update, or delete a vCenter Server Identity Provider that is required for federated authentication. To limit a user to view the Identity Provider configuration information only, assign the VcIdentityProviders.Read privilege
• If you have previously added vCenter group memberships for any remote AD/LDAP users or groups, vCenter attempts to prepare these memberships so that they are compatible with the new identity provider configuration. This preparation process happens automatically at service startup, but it must complete in order to continue with this configuration wizard. Click the button below to check the status of this process before proceeding.

We can summarize the prerequisites as follows:

• Enable the domain(s) as custom domains in Azure AD.
• Administrative permissions in vCenter Server (you can use the VcIdentityProviders.Manage privilege).
• vCenter Server must be updated to version 8.0 U2.
• Ensure https communication can be established between Azure AD and vCenter Server for user synchronization.  

    Note: We are not recommending to publish vCenter Server.  For more details, please refer to the Q&A section.   

 

Steps

You will need to work both on the vCenter site and the Azure AD site almost concurrently, as some configuration will need to be exchanged for the integration to take place.

The process can be summarized as the following figure:

 

Something important to notice is that, particularly in steps 1 and 2, there is data required from both parties, such as vCenter Redirect URL, client ID, OpenID configuration and the secrets. Therefore, a good idea is to run the process in parallel. 

 

 

 

Questions and Answers

Why are you using the name Azure AD when Microsoft has already announced the rebranding to Entra ID?

At the time of writing this article, both vSphere and Azure UI are still referring to the product as Azure AD. We acknowledge the situation will change in any moment, and future updates will show the new naming.

Can I integrate with both Azure AD and Okta at the same time?

No, you can only use one type of identity provider at a time, in addition of the default local domain (vsphere.local or the one defined at installation time).

Check if any of the external identity provider options supports integration with the other external identity provider, so vCenter receives one integration.

Can I have an internal identity provider connecting to an AD Over LDAP domain and an external identity provider connected to another Azure AD domain?

No, you can only use one type of identity provider at a time, in addition of the default local domain (vsphere.local or the one defined at installation time).

You mentioned there must be communication from the Azure SCIM Application to the vCenter Server. We don’t want to publish our vCenter Server.

Neither do we. If your organization has been working with Azure AD for a long time, you probably  have this requirement already figured out, via some form of secure interconnection between your corporate network and Azure AD.

Regardless of the option chosen, there are a couple of points that should be considered:

• Azure AD must be able to resolve and reach the FQDN set in the enterprise application tenant URL field.  This will be used to push the users and groups from Azure AD to vCenter Server.
• vCenter Server will validate the FQDN against its own configuration, it must match. This means, the header received by vCenter Server must be directed to its own FQDN. 

 

This certainly can be a challenge for some organizations, as it goes beyond the vCenter Server configuration.  We do recommend using a secure tunnel approach. A potential workaround is having a Load Balancer, reverse proxy or App gateway responding to the URL set in the Tenant and overwriting it with the internal  FQDN of vCenter Server before forwarding the traffic to it. 

In our example, we used an Azure Application proxy configuration. We installed the Application proxy connector in a Windows Server on the internal network, with access to vCenter.  We pointed Azure AD SCIM application to the external interface of this Application proxy, and let the same tool handle the FQDN overwrite. 

As always, analyze all the pros and cons of each configuration option at the light of your organizational needs and regulations. As we are integrating with a third party tool, please check their best practices and support guidances as well.