Considerations when migrating a vCenter Identity Source from Integrated Windows Authentication to AD over LDAP / OpenLDAP

Products

• VMware vCenter Server

Issue/Introduction

IWA (Integrated Windows Authentication) is considered a deprecated option for identity sources in vCenter Server. IWA uses Likewise to communicate with the AD domain, and so also uses Kerberos for authentication. This allowed some offload of the work needed to authenticate users, but also lead to some undesirable results in large or complicated infrastructures.

The AD over LDAP identity provider is similar to OpenLDAP identity provider in that it allows vCenter SSO to query and authenticate a user against a single x500 directory (i.e. domain controller) using LDAP protocol. The only difference is that the AD over LDAP identity provider has built-in assumptions which expect the LDAP source to conform to the proprietary Active Directory schema. Therefore, AD over LDAP identity provider should be used when connecting to Microsoft Active Directory, and the OpenLDAP identity provider should be used for all other x500 directories.

If the decision to migrate from an IWA to an AD over LDAP identity provider is chosen, specific considerations need to be taken to ensure no loss of access to vCenter users.

Environment

VMware vCenter Server 7.0.x
VMware vCenter Server 8.0.x
VMware vCenter Server 6.7.x

Resolution

Replicating IWA capabilities when using AD over LDAP

To replicate the IWA capabilities, AD over LDAP needs to be configured in a particular way.

Let's consider a domain forest topology of example.com, where there are three domains, (1) domain-a, (2) domain-b, (3) domain-c.
Since there are three domains, three AD over LDAP identity providers are configured for each domain.

Identity Source Type : Active Directory over LDAP
Name                 : domain-a.example.com
Base DN for users    : DC=example,DC=com
Base DN for groups   : DC=example,DC=com
Domain Name          : domain-a.local
Domain Alias         : domain-a
Primary server URL   : ldap://domain-a.example.com:3268

Identity Source Type : Active Directory over LDAP
Name                 : domain-b.example.com
Base DN for users    : DC=example,DC=com
Base DN for groups   : DC=example,DC=com
Domain Name          : domain-b.example.com
Domain Alias         : domain-b
Primary server URL   : ldap://domain-b.example.com:3268

Identity Source Type : Active Directory over LDAP
Name                 : domain-c.example.com
Base DN for users    : DC=example,DC=com
Base DN for groups   : DC=example,DC=com
Domain Name          : domain-c.example.com
Domain Alias         : domain-c
Primary server URL   : ldap://domain-c.example.com:3268

Each identity provider,

• Uses an Active Directory Global Catalog corresponding to that domain in the Primary Server URL.
• The Base DN for users and Base DN for groups must be of the top-level domain (e.g. DC=example,DC=com). This allows for vCenter to query Active Directory Global Catalog in full, and not be scoped to a particular domain.
  • If Base DN for users and Base DN for groups were to be configured as DC=domain-b,DC=example,DC=com, then the identity provider would only be able to query information about domain-b, and will exclude everything about domain-a and domain-c.
• Has an alias to allow for NETBIOS name use when users authenticate. (e.g. "domain-b\user01" vs "[email protected]"

 

Group limitations when using Active Directory Global Catalogs

An Active Directory Global Catalog contains complete information about its own domain and partial information about the other domains in its purview. Only universal groups from other domains are part of a Global Catalog. Therefore, when adding group permissions to VC, it's recommended to use only groups with domain local members or universal groups. This also applies to nested groups.

Users who were added to VC permissions via non-universal groups may no longer be able to authenticate after migrating from IWA to AD over LDAP.

For more information on this, please refer to the following Microsoft TechNet articles:

• http://technet.microsoft.com/en-us/library/cc759007%28WS.10%29.aspx
• http://technet.microsoft.com/en-us/library/cc756994%28WS.10%29.aspx
• http://technet.microsoft.com/en-us/library/cc755692%28WS.10%29.aspx

 

IWA functionality that cannot be preserved when using AD over LDAP

• Windows Session Authentication (SSPI) - This allows users to provide their Windows Kerberos token from their Windows Session to login to vCenter. When using IWA, Likewise is able to read and validate kerberos token. AD over LDAP identity provider does not have this capability.