Migrating identity source from IWA to AD over LDAP/OpenLDAP - vCenter Server

Products

• VMware vCenter Server

Issue/Introduction

Integrated Windows Authentication (IWA) is a deprecated identity source in vCenter Server. IWA uses Likewise and Kerberos for authentication, which causes undesirable results in complex infrastructures.

Active Directory (AD) over LDAP allows vCenter Single Sign-On (SSO) to query and authenticate users against a single domain controller using the LDAP protocol. Because the AD over LDAP identity provider assumes the LDAP source conforms to the proprietary Active Directory schema, use AD over LDAP exclusively for Microsoft Active Directory. Use the OpenLDAP identity provider for all other x500 directories.

Migrating from IWA to AD over LDAP requires specific considerations to prevent loss of access for vCenter Server users. Following a migration, the environment could exhibit specific behaviors.

• VCSA SSO authentication latency lasts 15 to 45 minutes immediately after the migration.

• Usernames in the vSphere Client appear in different formats across sites in Enhanced Linked Mode (ELM).

• Permissions render as DOMAIN\username (NetBIOS) on some objects and [e-mail] (FQDN) on others.

Environment

• VMware vCenter Server 7.x

• VMware vCenter Server 8.x

Cause

The architectural design of vCenter identity services dictates these behaviors:

• Authentication Latency: Adding a new identity provider triggers an initial directory cache initialization. vCenter Server progressively builds internal user-to-group maps via directory traversal and indexing, creating a transient delay.

• Naming Discrepancies: Different vCenter services default to different naming formats. The vCenter Single Sign-On (SSO) service uses FQDN for Global Permissions. The vCenter Inventory Service (vpxd) uses the NetBIOS/Domain Alias format for object-level permissions.

Resolution

To replicate Integrated Windows Authentication (IWA) capabilities, configure Active Directory (AD) over LDAP with specific parameters. Review the limitations and unsupported functionality before proceeding with the configuration.

Configuration Limitations and Unsupported Functionality

• Group Limitations with Global Catalogs:

  • An Active Directory Global Catalog contains complete information about its own domain and partial information about other domains in its purview. Only universal groups from other domains are part of a Global Catalog.

  • When adding group permissions to vCenter, use only groups with domain local members or universal groups. This applies to nested groups. Users added to vCenter permissions via non-universal groups lose authentication access after migrating from IWA to AD over LDAP.

  • For more information, review the following Microsoft TechNet articles:

    • Global catalog replication

    • Selecting Local Groups or Domain Local Groups as Resource Groups

    • Group Scope

• Unsupported Windows Session Authentication (SSPI):

  • SSPI allows users to provide a Windows Kerberos token from a Windows Session to log into vCenter. While IWA uses Likewise to read and validate the Kerberos token, the AD over LDAP identity provider lacks this capability.

Configuration Steps

1. Configure the AD over LDAP identity source using the Global Catalog (port 3268 or 3269).

2. Set the Base DN for users and Base DN for groups at the top level of the domain forest (e.g., DC=example,DC=com). This ensures the identity provider queries the Active Directory Global Catalog in full and is not scoped to a particular domain.

3. Add a Domain Alias in the configuration to allow users to authenticate using NetBIOS formats (e.g., domain\user).

4. Allocate an operational window of 15 to 45 minutes for directory indexing to complete before investigating authentication performance.

5. Accept parallel naming layouts (FQDN vs. NetBIOS) as expected cosmetic behavior that does not impact security descriptors or functional access.

Domain Forest Topology Configuration

Consider a domain forest topology of example.com with three domains (domain-a, domain-b, domain-c). Configure three AD over LDAP identity providers, one for each domain, using the top-level Base DN:

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

Note: If Base DN for users and Base DN for groups are configured as DC=domain-b,DC=example,DC=com, the identity provider only queries information about domain-b and excludes domain-a and domain-c.

Additional Information

• Removal of Integrated Windows Authentication (IWA)

• Configuring vCenter SSO Identity Source using LDAPS