vCenter Server 7.0 で Identity Federation を構成【Part 3】

Table of contents

はじめに

本記事はIdentity Federation の構成記事の Part 3 となります。前回は AD FS 側の構成をおこないました。今回はいよいよ vCenter Server 側での構成を行っていきます。

注意: 本機能の VMware Docs での名称は vCenter Server ID プロバイダ フェデレーション (vCenter Server Identity Provider Federation)、公式 Blog の記事などでは Identity Federation と呼称されています。本記事では文字数の便宜上、当該機能を Identity Federation として呼称することとします。

2020/08/18 追記: 当方の ADV190023の対応に関する認識に誤りがあり、[おわりに] で「AD LDAP のデフォルトの動作が変更される」旨を記載していましたが、正しくは「設定変更が推奨であるものの既存の設定は変更されない」でした。このため、記事の内容を修正したとともに、誤った情報を記載したことをお詫び申し上げます。

なお、ADV190023 周りの詳細は「2020 LDAP channel binding and LDAP signing requirements for Windows」を参照しています。

vCenter Server での作業に入る前に確認

再掲になりますが、まずは前回の作業で使用した AD FS でのアプリケーショングループの以下の３点の情報を揃えておきます。

• クライアント識別子
• 共有シークレット
• AD FS の openid-configuration の URL

Active Directory の LDAPS の SSL/TLS 証明書の取得

認証には使われない(はず)ですが、vCenter Server 側でのロールによる認可にあたり Active Directory のユーザーの一覧が必要になります¹。この一覧の取得にあたり、vCenter Server から Active Directory の LDAPS への接続が必要になります。

vCenter Server からの LDAPS 接続にあたっては Active Directory 側(LDAPS サーバ)のサーバ証明書を用意しておく必要があります。

AD DS の場合はローカルコンピューターの [個人] ストア、もしくはサービスアカウント(Active Directory Domain Services)の [NTDS\個人] ストアに存在するんじゃないかと思います。こちらからエクスポートしておくと良いでしょう。私の環境では色々と実験していたので後者の証明書ストアに LDAPS の証明書が置いてありました。

もしくは、openssl コマンドの showcerts オプションを使うことで Base64 エンコードの証明書が表示できるので、こちらからコピー＆ペーストして証明書ファイルにする方法もあります。

1$ openssl s_client -showcerts -host <AD DS の FQDN> -port 636

vCenter Server での Identity Federation の構成

これで事前に揃えておくべき必要な情報が揃ったので、いよいよ vCenter Server で Identity Federation を構成していきます。

まずは [ホーム] > [管理] > [Single Sign-On] > [設定] から [ID プロバイダ] を開きましょう。

[ID プロバイダの変更] をクリックするとダイアログがポップアップします。[Microsoft ADFS] を選択し [次へ] をクリックして進みます。

[ADFS サーバ] ページでは AD FS 側でメモしておいた３点の情報を入力し、[次へ] をクリックして進みます。

[ユーザーおよびグループ] ページでは Active Directory のベース DN や LDAPS 接続の情報を入力し、[次へ] をクリックして進みます。接続するドメインユーザーには指定したそれぞれのベース DN に対する読み取り権限が必要です。

最後に設定を確認して [完了] をクリックすると、以下のように [ID プロバイダ] タブのタイプが Microsoft ADFS に変わります。

また、[Single Sign-On] > [ユーザーおよびグループ] で [ドメイン] に Microsoft ADFS が追加されているため、こちらで LDAPS 経由でのユーザーの一覧取得が出来ているか確認します。

ここまで来たら Identity Federation の構成は完了です。

権限の割り当てとログイン

この後にログインのテストをすることになりますが、Active Directory のドメインユーザーには権限が割り当てられていないのでログインできません。このため、インベントリのどこかでドメインユーザーに権限(ロール)を割り当ててください。

※例えば、以下のように vCenter Server オブジェクトの [権限] タブから割り当てるなど。

その後、一度 vSphere Client からログアウトすると初回記事でも記載したログイン画面が見られると思います。

ここで Active Directory ドメインユーザー (上記では administrator@jangari.local) を入力すると、外部 ID プロバイダのユーザーと判断されて以下のような AD FS のログイン画面に遷移します。

ドメインユーザーのユーザー名とパスワードでログインすると、最後に vSphere Client で右上のアカウント名がログインしたドメインユーザーとなっていることが確認できます。

新しい vCenter Server で拡張リンクモードを構成した場合

拡張リンクモードを構成した場合、こちらのドキュメントにも記載があるように vCenter Server 間で AD FS の構成が複製されます。

実際にどうなるのか確認するため、AD FS を構成した vCenter Server をポイントするように新しく vCenter Server をデプロイしてみたところ、ID プロバイダの画面上でリダイレクト URI 以外の設定 (クライアント識別子も含む) が複製されました。

このため、ドキュメントに記載がある通り、AD FS 側ではアプリケーショングループにリダイレクト URI を追加してあげれば OK です。

補足: 拡張リンクモードでのプライベート CA 証明書のインポート

重要：以下の補足はあくまでも私個人が機能を試している中で遭遇した事象、かつ私見による考察や推測が含まれています。従って、すべてが公式のドキュメントやナレッジベースで裏付けられるものではない単なる一個人の見解であること、同じエラーメッセージが必ずしも同じ事象を示しているとは限らないことを、予めご理解ご了承をお願いいたします。

初回の記事で JRE トラストストアにプライベート CA の CA 証明書をインポートしていましたが、keytool で確認すると、特にこちらは vCenter Server 間でレプリケーションされないようでした²。ホームラボなどの検証環境でプライベート CA を使用する場合、2台目以降の VCSA の JRE トラストストアにも CA 証明書のインポートが必要になるようです。

こちらのMicrosoft社ドキュメントにもVMware社ドキュメントでは「本番環境では AD FS で使用する SSL/TLS 証明書は公的な認証局により署名された証明書を使用してください」といった旨が記載されていますので、システムが各製品の要件などを遵守していれば本番環境では遭遇しにくいかと思いたいです。

参考までに、私が何も考えずに拡張リンクモードだけ構成してみたところ、2台目の vCenter Server 側で「[400] OAuth 2 の認証コードのアサーション要求の処理でエラーが発生しました」というエラーに遭遇しました。

エラーメッセージの内容や OpenID Connect を使っていることを考えると、vCenter Server が OpenID Connect の認可コードを利用して AD FS にトークンリクエストを発行する際に何かが失敗したと推測しています。この後に JRE トラストストアへの CA 証明書をインポートして解消された状況を鑑みれば、恐らく AD FS のサーバ証明書の検証時に問題が起きていたんだろうと思います。

おわりに

今回は３記事に渡って vSphere 7 における Identity Federation の構成を見ていきました。

VMware 側では統合 Windows 認証の今後の vSphere リリースでの廃止が予定されており、Microsoft 側では統合 Windows 認証に影響を及ぼす Active Directory LDAP のセキュリティを強化する設定が追加³されています。

これらにより、今後 Active Directory を認証に使用している環境ではシステムの構成変更が求められる可能性もありますので、現在の自システムの vSphere の認証がどういう構成になっているか、今後 Identity Federation を使用するか他の認証方式を選択するか今のうちから検討しておくことをお勧めしたいと思います。