vCenter in VMware vSphere 7 introduces support for role-based access control (RBAC), based on standards-based federation. While this sounds fantastic, there are a couple of things you should know about this vCenter Identity Provider Federation feature, before you blindly implement it.

vCenter 7.0 or later

The vCenter Identity Provider Federation feature is only available in vCenter implementations running version 7.0, or later. It does not work with previous versions of vCenter.

vCenter Server 7.0 requires ESXi host version 6.5 or later. Upgrade if necessary. For more information, consult the VMware Product Interoperability Matrix.

AD FS on Windows Server 2016 Or later

The vCenter Identity Provider Federation feature currently is only supported with Active Directory Federation Services (AD FS) implementations running Windows Server 2016, or up.

The vCenter Identity Provider Federation feature uses OAuth. Although AD FS implementations running Windows Server 2012 R2 are capable of connecting OAuth applications, this version of AD FS is not supported.

AD FS Must be configured with an Active Directory CPT

The Active Directory Federation Services implementation must be equipped with an Active Directory Claims Provider Trust (CPT). Although AD FS on Windows Server 2016, and up, support connections toLDAPv3-compatible identity stores, this setup is not supported for the vCenter Identity Provider Federation feature.

Network traffic between the vCenter Admin, -Server and AD FS

The premise of federation allows the device of the user to be in charge of authentication and reauthentication. This means that the device of the vCenter admin, the vCenter Server and the AD FS implementation need to be able to communicate to each other over the network.

Authentication occurs over TCP443, but some connections are required over TCP80 to support the https traffic with certificate revocation checks.

Multi-factor Authentication in AD FS

The advertised multi-factor authentication capabilities are not in vCenter, but in AD FS. To gain the ability to require multi-factor authentication from vCenter admins, you’ll need to have an AD FS implementation that meets the above requirements and has a multi-factor authentication adapter configured, such as the Azure MFA Adapter.

Multi-factor Authentication for every session

When multiple VMware products are connected to the Active Directory Federation Services (AD FS) implementation, single sign-on is achieved per session. As the first sign-in per session is validated with multi-factor authentication, all subsequent sign-ins will be validated in the same way.

While many security people will claim you need to perform multi-factor authentication for every sign-in, you typically don’t need to as AD FS claim tokens have a typical lifetime of 8 hours.

More dependencies in the authentication chain

When thinking of degradation and resilience of the management infrastructure, authentication through AD FS adds dependencies in the authentication chain, when compared to authentication to Active Directory or LDAP.

Now, when designing an RBAC structure, when configuring SRM, managing time synchronization, deciding on what VMs to run on what ESXi hosts, backup and auditing, you’ll need to think about the AD FS servers as well.

Permissions to configure

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.

AD FS or Active Directory

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.

More IdPs to Come

During VMware VMworld 2020, VMware announced that their roadmap for the vCenter Identity Provider Federation feature includes support for VMware’s own WorkSpace One, Okta, Ping Federate and DUO. Additionally, more VMware products and technologies are being redesigned to leverage stands-based federation for authentication and authorization to simplify the identity landscape for organizations using VMware products.

Concluding

When your organization starts embracing standards-based federated access to VMware products and technologies, the benefits of single sign-on and multi-factor authentication accumulate over time.

Now is a good time to start.

Further reading

vSphere 7’s vCenter Server Identity Provider Federation feature allows for MFA
vSphere 7 – Identity Federation
Configure vCenter Server Identity Provider Federation
How vCenter Server Identity Provider Federation Works

The post Ten Things You should know about vCenter Identity Provider Federation appeared first on The things that are better left unspoken.