ta_ichiのTech Logs: Workspace ONE AccessからAzure AD(Office365)へのIDプロビジョニング

前回に引き続き、Workspace ONE Accessについての記事です。

今回は、Workspace ONE AccessからAzure AD(Office365)へのIDプロビジョニングについて記載します。

■環境イメージ

構成イメージはこんな感じです。

Workspace ONE Accessに作成されているユーザー情報やグループ情報が、Azure AD(Office365)へ自動作成されます。

Workspace ONEの環境やMicrosoft 365のテナントは前回のブログと同じ環境を使用します。

ただし自動プロビジョニングがわかりやすく確認できるように前回のブログで手動作成した各環境のユーザーは削除し、管理者以外のユーザーはいない状態にしています。

また、前回のブログで作成したOffice365のシングルサインオン(SSO)設定はそのまま使用しますが、ユーザーの割り当ては一度すべて削除しています。

■設定の前に

なぜWorkspace ONE AccessからAzure ADへIDプロビジョニングをする？

前回のブログのAppendixで記載しましたが、Workspace ONE AccessとMicrosoft 365(Office365)のSSO連携時の多くの構成では、Active Directory ドメインコントローラーに登録されたIDやグループ情報をWorkspace ONE AccessとAzure ADへそれぞれのコネクターを使って同期します。

●一般的な構成

ですが、前回のブログ作成時の検証環境ではActive Directory ドメインコントローラーなどIDソースとなる製品が無いため、それぞれのサービスにアカウントを手動作成しています。

この構成の場合「ユーザー(ID)を追加したい」という場合に、Workspace ONE AccessとAzure ADへそれぞれユーザー情報を手動追加しないとならないためちょっと面倒です。

今回のブログでは、IDPとして動作するWorkspace ONE Accessにユーザーを追加したら、Azure AD(Office365)にもユーザーが自動作成されるように構成したいと思います。

このIDプロビジョニングの機能はWorkspace ONE Accessのプロビジョニングアダプタと呼ばれる機能です。

・Workspace ONE Access でのプロビジョニングアダプタの使用https://docs.vmware.com/jp/VMware-Workspace-ONE-Access/services/ws1-access-resources/GUID-27461E9A-475C-4E01-ACD0-18AF0B5230B9.html

ちなみにこの機能はオンプレADをすでにWorkspace ONE Accessに同期している環境で、追加でAzure AD Connectを構築せずにOffice365のSSOを構築する時にも使えると思います。

■設定準備

本題に戻ります。

今回の検証用に以下のローカルアカウントをWorkspace ONE Accessで作成します。このアカウントがMicrosoft365を使用するユーザーです。

検証目的なのでアカウント作成時のメールは一時的に適当なメールアドレスにして初回パスワードを設定し、後で変更しました。

ObujectGUIDの値はPowershell を開き下記コマンドを実行して生成した値を入力します。

New-Guid

次にグループを作成し、作成したユーザーを所属させます。検証時は”Office365-WS1-Users”というグループを使用しました。

これで環境準備は完了です。

■プロビジョニングアダプタの設定

まずPowerShellを使用して Microsoft365に接続し、アカウント作成用のサービスプリンシパルを作成します。

前回のブログでMsOnlineモジュールをインストールしてコマンドを実行した環境を使用します。

Microsoft 365(Office365)テナントに接続します。下記コマンドを実行するとポップアップで認証画面が出てくるので、Microsoft 365(Office365)テナントの管理者アカウントでログインします。

Connect-MsolService

次に下記コマンドを実行して、サービスプリンシパルを作成します。作成時の出力結果から” ObjectId”と” ServicePrincipalNames”の値を確認します。

New-MsolServicePrincipal -DisplayName “任意のアカウント名” -Type password -Value “任意のパスワード”

次に下記コマンドを実行して作成したサービスプリンシパルにユーザー管理のロールを付与します。

Add-MsolRoleMember -RoleMemberType ServicePrincipal -RoleName “User Administrator” -RoleMemberObjectId “確認したObjectIDの値”

サービスプリンシパルの作成は完了です。

Azure PortalのAzure AD管理画面で[すべてのアプリケーション]から作成したサービスプリンシパルは確認できます。”アプリケーションの種類”を[すべてのアプリケーション]に設定して検索すると確認できます。

次に、Workspace ONE Accessに作成したOffice365アプリケーションにプロビジョニングの設定をします。

Workspace ONE Accessの管理画面を開き、作成済みの[Office365]アプリの[編集]を開きます。

[高度なプロパティ]を開き、カスタム属性マッピングの” ImmutableID”が” ${user.ObjectGUID}”になっていることを確認します。(検証時なぜか英字小文字になっていて数時間溶かしました…)
次に” プロビジョニングオプションの表示”を[はい]にします。すると、プロビジョニングアダプタの設定が追加表示されるようになります。

[次へ]を2回クリックし、プロビジョニング設定を開きます。下記値をそれぞれ入力し、[接続のテスト]をクリックします。設定が問題なければ接続成功のメッセージが表示されます。

Office365ドメイン	フェデレーションしているカスタムドメイン
クライアントID	先程PowerShellで作成したサービスプリンシパルの”ServicePrincipalName”の値 (出力結果の両端にある”{}”はとる)
クライアントシークレット	先程PowerShellで作成したサービスプリンシパルのパスワード

テストが問題なければ”プロビジョニングを有効にする”を[はい]にします。[次へ]をクリックします。

ユーザープロビジョニング時の属性マッピングを設定します。検証時は以下で設定しました。

表示名	${user.userName}
ユーザープリンシパル名	${user.userPrincipalName}
GUID	${user.ObjectGUID}
E メールのニックネーム	${user.userName}
【追加】使用場所	JP

次に、プロビジョニングするグループを設定します。環境準備で作成したグループを追加します。

設定内容を確認し、[保存して割り当て]をクリックします。

アプリケーションの割り当てで、作成したグループを追加します。

以上で、設定は完了です。選択したグループとグループに所属しているユーザーがAzure AD(Office365)へ自動作成されます。

■プロビジョニングの確認

Workspace ONE AccessのOffice365アプリの情報画面で、”グループプロビジョニング”という表示項目が追加されます。プロビジョニングしたグループとステータスが表示されます。

Office365アプリの割り当てを確認し[プロビジョニングの状態]を開くとプロビジョニングしたユーザーとステータスが表示されます。

次にAzure Portalを開き、Azure ADの情報を確認します。

Workspace ONE Accessで指定したグループとユーザーがプロビジョニングされていることが確認できます。

グループのメンバーを確認すると、プロビジョニングされたユーザーが所属しています。

プロビジョニングしたユーザーはOffice365(Microsoft365)のライセンスがない状態のため、ユーザー毎にプロビジョニング後に手動ライセンス割り当てを行うのは面倒です。今回の環境ではプロビジョニングしたグループにOffice365　(Microsoft365)のライセンスを割り当てます。