Frequently Asked Questions (FAQ) - Identity and Access Management

This solution uses Microsoft Active Directory over LDAPS (LDAP over SSL) as the identity provider for both vCenter Single Sign-On and Workspace ONE Access.

Active Directory with Integrated Windows Authentication is deprecated in vSphere 7.0 and will be phased out in a future release of vSphere. See the vSphere 7.0 Release Notes and KB 78506.

At the time of the writing this solution, the use of federated identity with ADFS is not included. However, the use of ADFS is fully supported with the vSphere and Workspace ONE Access versions used in this validated solution, but may introduce issues for other integrated solutions.

• Conversion from Active Directory with Integrated Windows Authentication or Active Directory over LDAP to Active Directory Federations Services does have some impactful change to users/groups along with their roles and permission for some products (e.g. vRealize Automation).
• SDDC Manager does not directly integrate with ADFS. A new login will use the SDDC Manager UI; however, if already logged into vCenter Server only the user name must be provided.
• There are no known issues with vCenter Server authentication or application-to-vSphere service account connectivity and integrations using ADFS.
• vRealize Suite-to-NSX integrations (e.g. vRealize Automation and vRealize Operations to NSX cloud accounts/integrations) must use the built-in admin accounts instead of service accounts. API based logins can not be passed back to ADFS. This is a known issue with third-party Identity Providers via Workspace ONE Access. There are no known issues with vRealize Suite solutions and NSX-T Data Center integrations using ADFS.
• There are no known issues with vRealize to vRealize Suite solution integrations using ADFS.
   

For more information, please see this blog from the solution author.

This validated solution is based on the use of Workspace ONE Access for the connections between NSX Managers to Microsoft Active Directory using LDAPS. This allows the solution to use a configuration patten that is also used for vRealize Suite and which can also be adapted for the use of ADFS, if required.

You may use only the native LDAPS integration for  NSX Local Managers; however, the solution does not cover the design, implications, and implementation. Additionally, Workspace ONE Access is required by NSX Global Managers. Please refer to the NSX-T Data Center documentation.

This is not the only way to deploy, integrate, and operate NSX-T Data Center with Workspace ONE Access as the identity access provider, but is an opinionated and prescriptive solution based on a set of design objectives and scenarios. It is not the only pattern.

However, there are some specific reasons that this solution uses the standalone deployment of Workspace ONE Access.

Licensing

The solution design considers licensing and entitlement.

The solutions are developed as layers. What this means is that you can take the context of only this solution design and apply it independently.

For example, imagine you have VMware Cloud Foundation Standard - what are you entitled to deploy? If you said to yourself: "vSphere, vSAN, and NSX-T Data Center," you are correct.

The VMware Cloud Foundation Standard edition does not include vRealize Suite. Therefore, you are not entitled to deploy vRealize Suite Lifecycle Manager and subsequently the clustered Workspace ONE Access. You are however, entitled to Workspace ONE Access with NSX-T Data Center. 

In this example, you are only entitled to use Workspace ONE Access in conjunction with NSX-T Data Center and you do not need a Workspace ONE Access license to leverage a subset of its functionality with NSX-T Data Center. But, you are  not entitled to deploy vRealize Suite Lifecycle Manager use it to deploy and manage Workspace ONE Access.

As a result, the solution provides a layered method for you to apply the solution design for the management and VI workload domains while using Workspace ONE Access with NSX-T Data Center as the identity access provider based on VMware Cloud Foundation Standard or higher. 

Multi-instance / Multi-region

The solution is developed with the use more that one VMware Cloud Foundation instance (multi-instance) and more than one data center region (multi-region) as implementation paths.

Why is this important?

When you think about multi-instance and multi-region, failover, disaster recovery, etc. the goal is to operate the Software-Defined Data Center as a system - but one that can minimize impact and blast radius with availability and disaster recovery.

When applied to the solution design the following issues can arise: In a multi-region deployment, there is the possibility that connectivity between regions could be impacted (e.g., a WAN or VPN outage). For examples, if the identity and access management layer for local region components (e.g., NSX-T Data Center) resides only in one and the connectivity between two regions are impacted, then access to these services in the second region may impacted due to the availability of Workspace ONE Access outside of a "break glass" use of local accounts and potentially reconfiguration of services. 

Let's take this same example and apply it to Cloud Foundation deployed in two regions but using vRealize Automation Cloud (SaaS). In this scenario, there is a single Workspace ONE Access instance in San Francisco (us-west-1) and NSX-T Data Center is configured to use this instance. In Los Angeles (us-west-2), NSX-T is configured to use the Workspace ONE Access instance in San Francisco (us-west-1). vRealize Automation Cloud has a cloud proxy deployed in each region - cloud accounts are configured to authenticate to vCenter Server using Active Directory over LDAP(S) and to NSX-T via Active Directory over LDAP(S) using Workspace ONE Access instance in San Francisco. In the event of a network outage between the two regions, NSX-T in Los Angeles would not be able to authenticate the service account it uses in Active Directory. This would result in workloads deployed from vRealize Automation Cloud failing. However, if Los Angeles has its own instance, there would be no impact to operations.

And that's the point, availability of the identity and access management services for those local solutions. 

If your environment is not multi-instance or multi-region and is entitled to vRealize Suite, using the clustered Workspace ONE Access used by vRealize Suite for NSX-T Data Center would be supported as a reasonable design deviation.

Please note that the localized, standalone Workspace ONE Access instance is planned to eventually be “absorbed” into the platform and the solution design has taken this into consideration.

No. This validated solution is based on the use of LDAPS for the connections between vCenter Server and Workspace ONE Access to Microsoft Active Directory. LDAP can be used during the configuration if required; however, Microsoft recommends a hardened configuration for LDAP channel binding and LDAP signing on Active Directory domain controllers. For more information, see Microsoft Security Advisory ADV190023.

No. Password and account policies for the VMware Cloud Foundation platform components cannot be set or managed from SDDC Manager and must be configured manually.

Yes. This validated solution includes the optional use of Microsoft PowerShell cmdlets to perform many of the deployment and configuration procedures. You must first install the PowerValidatedSolutions PowerShell module from the PowerShell Gallery. The subsequent procedure options will set the minimally required variables and automate the procedure.

No. It's not required or recommended to join ESXi hosts in a VMware Cloud Foundation system to Active Directory. SDDC Manager manages the commissioning, configuration, and lifecycle of the ESXi hosts. In the event that direct access to a ESXi host is required, the Cloud Administrator can obtain the root or SERVICE account credentials to troubleshoot any issues with the ESXi host. However, there are circumstances when you must enable Active Directory as the authentication system by joining each ESXi host to an Active Directory domain. VMware Cloud Foundation supports the use of NFS version 4.1 (and version 3) as supplemental storage. With NFS version 4.1, ESXi supports the RPCSEC_GSS Kerberos mechanism authentication service. It allows the built-in NFS 4.1 client for ESXi to prove its identity to an NFS server before mounting an NFS share. The Kerberos security uses cryptography to work across an insecure network connection. To use Kerberos authentication, each ESXi host that mounts that mounts an NFS 4.1 datastore must be joined to the required Active Directory domain and the NFS Kerberos credentials must be set on each host.

Yes. If you join another VMware Cloud Foundation instance to the same vCenter Single Sign-On domain (vsphere.local) that was created by the first instance then each SDDC Manager would manage the administrator@vsphere.local account. After performing the password rotation of this account from one SDDC Manager, you must remediate the account in each additional SDDC Manager connected to the same vCenter Single Sign-On domain.

No. You must use the default vCenter Single Sign-On domain name (vsphere.local).

While this solution does not provide specific guidance for the the creation and desired state of vSphere roles, this can be accomplish through the use of Terraform.

Yes.