Configuring VMware vCenter Centralized Authentication with Google Workspace via OIDC: Replacing LDAP and Active Directory – ITFROMZERO

Table of Contents

The Real Problem: Managing vCenter Accounts as Your IT Team Grows

I manage a VMware cluster with 8 ESXi hosts at my company, and this is a real problem I ran into: in the beginning, only 2–3 people accessed vCenter, so local accounts were perfectly fine. Then the team grew to 8 people, outsourced contractors were added to the mix, and things started to get messy. People would leave without their accounts being disabled, new hires had to wait for IT to manually create accounts, and password resets became a weekly Slack ping ritual.

The first solution that came to mind was LDAP or Active Directory — the traditional enterprise standard. But our company runs 100% on Google Workspace with no Windows Servers whatsoever. Standing up an AD server just to authenticate vCenter would be completely out of proportion in terms of cost and effort.

Why LDAP and Active Directory Aren’t Always the Right Choice

LDAP and AD work well in purely on-premise Windows environments. Move to cloud-first or Google Workspace, and a whole set of practical problems emerge:

Requires spinning up a Windows Server Domain Controller — extra licenses, extra VM resources
LDAP transmits in plain text unless you carefully configure LDAPS — an obvious security risk that any ESXi administrator should take seriously
Syncing groups from Google Workspace into AD is a problem on its own — complex and prone to drift
When you off-board a user in Google, AD doesn’t sync immediately — leaving a dangerous window

I got burned by this once: the LDAP bind account password expired at 2 AM, taking the entire vCenter authentication system down — nobody could log in. With OIDC, this kind of dependency simply doesn’t exist.

Available Approaches and a Practical Comparison

There are three main approaches to centralizing vCenter authentication:

LDAP/LDAPS: Requires a separate directory server, complex to manage, sync lag when off-boarding
Active Directory: Great if you already have AD infrastructure, but not ideal for Google Workspace-first environments
OIDC (OpenID Connect): The modern standard, supported since vCenter 7.0 U2, integrates directly with Google Workspace — no intermediary required

Since vCenter Server 7.0 U2, VMware supports External Identity Providers via the OIDC standard. Google Workspace becomes the single source of authentication — no additional servers needed.

The Best Approach: Setting Up OIDC with Google Workspace Step by Step

Step 1 — Create an OAuth 2.0 Client in Google Cloud Console

Go to https://console.cloud.google.com and select an existing project or create a new one dedicated to internal tools.

Navigate to APIs & Services → OAuth consent screen:

User Type: Internal — only users within your Google Workspace domain can sign in
Fill in the App name (e.g., vCenter SSO), User support email, and Developer contact

Next, go to Credentials → Create Credentials → OAuth 2.0 Client ID:

Application type: Web application
Authorized redirect URIs: https://<vcenter-fqdn>/ui/login/oauth2/authcode

Once created, save the Client ID and Client Secret — you’ll need these in the next step:

Client ID:     1234567890-abcdefgh.apps.googleusercontent.com
Client Secret: GOCSPX-xxxxxxxxxxxxxxxxxxxxxxxx

Step 2 — Configure the Identity Provider in vCenter

Go to Administration → Single Sign On → Configuration → Identity Provider
Click Change Identity Provider
Select Microsoft ADFS — don’t be confused! vCenter labels it ADFS but actually accepts any OIDC-compliant provider

Fill in the connection details:

Client Identifier:  <Client ID from Google>
Shared Secret:      <Client Secret from Google>
OpenID Address:     https://accounts.google.com
Redirect URI:       https://<vcenter-fqdn>/ui/login/oauth2/authcode

vCenter automatically discovers Google’s endpoints via https://accounts.google.com/.well-known/openid-configuration. Enter your Google Workspace domain (e.g., company.com) and save.

Step 3 — Assign User Permissions in vCenter

After saving the OIDC configuration, log out of vCenter — the login screen will now show a Sign in with company.com button. Seeing that button confirms the connection is working; the next step is to assign permissions.

Add permissions for each user:

Go to Administration → Access Control → Global Permissions
Click Add → Search for users by their Google email ([email protected])
Assign the appropriate role: Read-Only, Virtual Machine Power User, Administrator…

When you need to assign permissions for multiple users at once, use PowerCLI for speed:

Connect-VIServer -Server vcenter.company.com

$users = @(
    "[email protected]",
    "[email protected]",
    "[email protected]"
)

foreach ($user in $users) {
    New-VIPermission -Entity (Get-Folder -NoRecursion) `
        -Principal $user `
        -Role "ReadOnly" `
        -Propagate $true
    Write-Host "Added: $user"
}

Step 4 — Notes on Group Claims

Google OIDC does not automatically include group membership in the JWT token. This is a common point of confusion when first setting things up. There are two ways to handle it:

Option A: Use Google Cloud Directory Sync (GCDS) to sync Google Groups into a secondary LDAP — but that brings LDAP back into the picture…
Option B (what I use): Manage permissions directly by user email rather than by group. Works fine for teams under 20 people; use PowerCLI for bulk assignments when needed.

Best Practices After Deployment

Keep the Local SSO Account as a Break-Glass

This is non-negotiable in my book:

[email protected] — NEVER disable this account

If Google OIDC ever has an issue — even a brief Google outage or a misconfiguration — you need an emergency way into vCenter. The local SSO account is your last resort when everything else breaks.

Test Off-Boarding Immediately After Setup

Create a test user in Google Workspace → assign permission in vCenter → suspend the user in Google Admin Console → verify they can no longer log in to vCenter. This step is often skipped but is critically important.

I’ve confirmed it myself: suspending a user in Google Admin Console immediately revokes their vCenter access. No action needed on the vCenter side. This is the biggest advantage over LDAP — with LDAP, if you forget to disable or sync is slow, a user can still log in for a while after they’ve been off-boarded.

Monitor Failed Authentication

Monitoring SSO logs helps you detect brute force attempts or revoked accounts still trying to log in:

# SSH into the vCenter Appliance and check the SSO log:
tail -f /var/log/vmware/sso/vmware-sts-idmd.log

# Grep failed authentication:
grep "FAILED" /var/log/vmware/sso/vmware-sts-idmd.log | tail -50

Verify Your vCenter Version Before Configuring

OIDC is only supported on vCenter 7.0 U2 and later. vCenter 6.x does not have this feature — upgrade first.

# SSH into the vCenter Appliance:
cat /etc/applmgmt/applianceVersion

Since switching to OIDC + Google Workspace, managing accounts across an 8-node ESXi cluster running nearly 200 VMs is no longer a burden. Onboarding and offboarding engineers has gone from 15 minutes to zero minutes on the vCenter side — just handle it in Google Admin Console and you’re done. No more zombie accounts. No more bind account expiration at midnight. And Google’s MFA automatically applies to vCenter access too, with no additional configuration required.