VMware vCenterをGoogle Workspace OIDCで集中認証する設定：LDAPとActive Directoryの代替 – ITFROMZERO

Table of Contents

実際の課題：ITチームの拡大に伴うvCenterアカウント管理

社内で8台のESXiホストで構成されたVMwareクラスターを管理しているが、これは実際に直面した問題だ。当初はvCenterにアクセスするのが2〜3人だったため、ローカルアカウントで十分だった。しかしチームが8人に拡大し、外部委託メンバーも加わったことで、管理が混乱し始めた。退職者のアカウントを無効化し忘れ、新メンバーはITが手動でアカウントを作るまで待ちぼうけ、パスワードリセットのSlack通知が毎週飛び交う状況になった。

最初に思い浮かんだ解決策はLDAPまたはActive Directory——エンタープライズの伝統的な標準だ。しかし弊社は100％ Google Workspaceを使用しており、Windows Serverは一台もない。vCenterの認証だけのためにADサーバーを立てるのは、コストと手間に見合わない。

LDAPとActive Directoryが常に最適な選択肢とは限らない理由

LDAPとADはオンプレミスのWindows環境では優れた機能を発揮する。しかしクラウドファーストやGoogle Workspace環境に移行すると、さまざまな実際の問題が浮上する：

Windows Server Domain Controllerの追加構築が必要——ライセンスコストとVMリソースを消費する
LDAPSを適切に設定しないとLDAPが平文通信になる——明らかなセキュリティリスクだ
Google WorkspaceからADへのグループ同期は別途対応が必要で、複雑かつずれが生じやすい
Google側でユーザーをオフボードしても、ADが即座に同期されない——危険な遅延が発生する

実際にこれで痛い目を見たことがある。LDAPのバインドアカウントのパスワードが深夜2時に期限切れになり、vCenterの認証が全面停止した——誰もログインできない状態に陥った。OIDCを使えば、こうした依存関係はなくなる。

解決策の比較：実際の観点から

vCenterの認証を集中管理する主な方法は3つある：

LDAP/LDAPS：専用のディレクトリサーバーが必要、管理が複雑、オフボード時の同期遅延あり
Active Directory：既存のAD環境があれば有効だが、Google Workspaceファーストの環境には不向き
OIDC (OpenID Connect)：モダンな標準規格、vCenter 7.0 U2からサポート、仲介サーバー不要でGoogle Workspaceと直接統合可能

vCenter Server 7.0 U2以降、VMwareはOIDC標準に基づくExternal Identity Providerをサポートしている。Google Workspaceが唯一の認証ソースとなり、追加のサーバー構築は不要だ。

最善の方法：Google WorkspaceでOIDCをステップごとに設定する

ステップ1 — Google Cloud ConsoleでOAuth 2.0クライアントを作成する

https://console.cloud.google.com にアクセスし、既存のプロジェクトを選択するか、内部ツール専用の新しいプロジェクトを作成する。

APIs & Services → OAuth consent screen に移動する：

User Type: Internal——Google Workspaceドメイン内のユーザーのみログイン可能
App name（例：vCenter SSO）、User support email、Developer contactを入力する

次に Credentials → Create Credentials → OAuth 2.0 Client ID に移動する：

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

作成後、Client IDとClient Secretを控えておく——次のステップで必要になる：

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

ステップ2 — vCenterでIdentity Providerを設定する

[email protected] アカウントでvCenterにログインし、次の操作を行う：

Administration → Single Sign On → Configuration → Identity Provider に移動する
Change Identity Provider をクリックする
Microsoft ADFS を選択する——誤解しないでほしい！vCenterはADFSと表記しているが、実際には任意のOIDCプロバイダーを受け付ける

接続情報を入力する：

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

vCenterは https://accounts.google.com/.well-known/openid-configuration 経由でGoogleのエンドポイントを自動的に検出する。自社のGoogle Workspaceドメイン（例：company.com）を入力して保存する。

ステップ3 — vCenterでユーザー権限を割り当てる

OIDC設定を保存後、vCenterからログアウトすると、ログイン画面に Sign in with company.com ボタンが表示される。このボタンが表示されれば接続は正しく設定されている。次は権限の割り当てだ。

各ユーザーに権限を追加する：

Administration → Access Control → Global Permissions に移動する
Add をクリックし、GoogleメールアドレスでユーザーをSearch（[email protected]）する
適切なロールを割り当てる：Read-Only、Virtual Machine Power User、Administratorなど

複数ユーザーを一括で割り当てる場合はPowerCLIを使うと効率的だ：

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"
}

ステップ4 — グループクレームに関する注意事項

Google OIDCはJWTトークンにグループメンバーシップを自動的に含めない。これは初期設定時に混乱しやすい点だ。対処方法は2つある：

Option A：Google Cloud Directory Sync（GCDS）を使ってGoogle GroupsをLDAPに同期する——しかしLDAPが再び登場することになる…
Option B（筆者が採用中）：グループではなくユーザーのメールアドレスで直接権限を管理する。20人未満であれば十分対応でき、必要に応じてPowerCLIで一括割り当てできる。

展開後のベストプラクティス

ローカルSSOアカウントをブレークグラスとして保持する

これは絶対に外せない必須事項だ：

[email protected] — このアカウントは絶対に無効化しないこと

Google OIDCで問題が発生した場合——短時間のGoogle障害や設定ミスであっても——vCenterへの緊急ログイン手段が必要だ。ローカルSSOアカウントは、あらゆるものが壊れた際の最後の手段となる。

セットアップ後すぐにオフボーディングをテストする

Google Workspaceにテストユーザーを作成 → vCenterで権限を割り当て → Google Admin Consoleでユーザーを停止 → vCenterにログインできないことを確認する。このステップは見落とされがちだが非常に重要だ。

確認済みだ：Google Admin Consoleでユーザーを停止すると、vCenterへのログイン権限が即座に失われる。vCenter側での追加操作は不要だ。これがLDAPと比較した際の最大の強みだ——LDAPでは、無効化し忘れたり同期が遅れたりすると、オフボード後もしばらくログインできてしまう。

認証失敗のモニタリング

SSOログを監視することで、ブルートフォース攻撃や失効したアカウントによるログイン試行を早期に検出できる：

# vCenter ApplianceにSSHして、SSOログを確認する:
tail -f /var/log/vmware/sso/vmware-sts-idmd.log

# 認証失敗をgrepする:
grep "FAILED" /var/log/vmware/sso/vmware-sts-idmd.log | tail -50

設定前にvCenterのバージョンを確認する

OIDCはvCenter 7.0 U2以降でのみサポートされている。vCenter 6.xにはこの機能がない——事前にアップグレードが必要だ。

# vCenter ApplianceにSSHする:
cat /etc/applmgmt/applianceVersion

OIDC + Google Workspaceへ移行して以来、約200台のVMを抱える8台のESXiクラスターにおけるアカウント管理の煩わしさが完全になくなった。vCenter側でのエンジニアのオンボード・オフボード作業が15分からゼロ分に短縮された——Google Admin Consoleで処理するだけで完結する。ゾンビアカウントも、真夜中に期限切れになるバインドアカウントも、もう存在しない。そしてGoogleのMFAがvCenterにも自動的に適用されるため、追加設定は一切不要だ。