Google

HOME
office
Google
Entra IDとGoogle Workspaceのメンバーを同期させる方法 - Provisioning編

2024年3月27日 / 最終更新日時 : 2024年9月11日 officeの杜 Google

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - Provisioning編

前回の記事にて、Google Workspace側のGoogle Directory Syncという機能を利用して、Azure Entra ID（Azure Active Directory）と同期させて、メンバーを自動的に追加する手法を記しました。一方で、Azure側にもEntra IDのメンバーをGoogle Workspace側に自動プロビジョニングする機能があり、これとSSO連携する機能を組み合わせることで、Entra ID側だけをメンテすればGWS側のメンバー管理が楽になります。

今回はAzure Entra IDのプロビジョニング機能を使って、ユーザを同期する手法を検証してみます。

1 今回利用する機能
2 事前準備
- 2.1 専用アカウントの作成
- 2.2 管理者権限を付与
3 自動プロビジョニングの設定
4 プロビジョニングの実行
5 関連リンク

今回利用する機能

今回の検証はあまりGoogle Workspace側での作業がありません。殆どがAzure Entra ID側の設定となります。（ちなみにグループを指定するにはMicrosoft Entra ID P1 以上のライセンスが必要です）。今回は無償のMicrosoft365に付属ライセンスにてユーザ単位でプロビジョニングします。

この機能をセットすることで、Entra ID側でユーザが追加された場合、自動でルールに従いGoogle Workspace側でもユーザが作成される仕組みになっています。但し、パスワード同期されるわけではないので、以下のSSO連携を追加で行い、SAML認証でGoogle Workspace側に入れるようにするのが定石のようです。

※不思議なのが、Entra管理センターからのライセンス管理画面からだとP1ライセンスの試用について何も出てきません。P2については出てきますが・・・P1を試用したい場合はこちらから入りましょう。

図：Entra管理センターからはP1の試用が出てこない

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - GDS編

Entra IDアカウントでGoogle WorkspaceにSSO連携してみた

事前準備

前述のGoogle WorkspaceにSSO連携してみた記事同様に、Google Workspace側はCloud Identity Freeにてアカウントを自動作成するようにします。Google Cloud Directoryのケースとは逆でEntra ID側からGoogle側に同期を図るので、Google側での準備はそこまで多くありません。

Google Workspace側では、Entra ID側からユーザ作成を行わせる専用のCloud Identity Freeアカウントを用意し、管理者権限を付与します。

※前回の記事の続きであるため、Entra ID側ではGWSと同じ独自ドメインを利用してユーザを作成しています。

専用アカウントの作成

Entra ID側からのユーザ作成を代行する管理者アカウントとその為の組織部門が必要です。

管理コンソールにログインする
左サイドパネルのディレクトリ⇒組織部門をクリックする
組織部門の作成をクリックして、親ドメインにぶら下がる形で「entra_id」という組織部門を作成します。
左サイドパネルからユーザをクリックして、作成したmicrosoft組織部門をクリック、新しいユーザーの追加をクリック
名、姓を入力し、provisioningという名称のアカウントにしました（名と姓は適当に入力）。パスワードもセットしておきましょう。

自分の場合余分なライセンス枠はないので、この時点ではCloud Identity Freeアカウントになっています。Google Workspaceライセンスは勿体ないので自動付与の場合は外してあげましょう。

図：通常のアカウント作成

管理者権限を付与

このままでは何も出来ないユーザですので、管理者権限を付与します。

作成したユーザをクリックして中に入ります。
管理者ロールと権限をクリックします。
今回はユーザ・グループの作成や削除といった権限で十分なのですが、丁度良いロールが無いので、カスタムロールを作成をクリックします。
新しいロールを作成をクリックする
ロール名称を入れて、続行をクリック（今回は、EntraManageという名前で作成）
管理コンソールの権限は組織部門読み取り、ユーザおよびグループは全権限、セキュリティはセキュリティの設定のみでセット
また管理APIの権限は、組織部門読み取り、ユーザ及びグループは全権限を指定する
保存をクリックする

特権管理者じゃありませんが、ユーザの作成・更新・削除が担当出来るようになったので、このアカウントに関しては厳格な管理が必要になります。カスタムロールは組織部門を限定することが出来ないので要注意。

図：カスタムロールを作成する

図：最小限の管理者権限を付与

自動プロビジョニングの設定

Entra ID側でアプリの準備する

GWS側に作成担当のユーザが準備できたので次に、Entra ID側で自動プロビジョニングの設定を行います。

Azure Entra IDのトップ画面を開く
左サイドバーの下のほうにある「エンタープライズアプリケーション」をクリックする
上部にある「新しいアプリケーション」をクリックする
Microsoft Entra ギャラリーを参照すると出てくるので、「Google Cloud Platform」をクリックする
Google Cloud / G Suite Connector by Microsoftが出てくるのでクリックする
右サイドパネルの作成をクリックします。名前は適当につけます（今回はAuto Provisioningと命名）
しばらくすると、アプリが作成されて概要画面が出てきます。
左サイドバーから「プロパティ」をクリックします。

以下の内容の設定をします。

//ユーザーのサインインが有効になっていますか?
いいえ

//割り当てが必要ですか?
いいえ

//ユーザに表示しますか？
いいえ

1

2

3

4

5

6

7

8

//ユーザーのサインインが有効になっていますか?

いいえ

//割り当てが必要ですか?

いいえ

//ユーザに表示しますか？

いいえ

保存をクリックする

図：GCPを選択する

図：プロパティ設定

プロビジョニング設定を開始

続いて、以下の作業を続行します。

左サイドバーから「プロビジョニング」をクリックします。
作業の開始をクリックします。
プロビジョニングモードを「自動」に変更します。
管理者資格情報を開いて、承認するをクリックする
Googleログイン画面がポップアップする。
ここで、事前準備で作成しておいたCloud Identity Freeのアカウントでログインする
Azure Active Directoryに対する許可認証を求めてくるので、許可をクリックする。
テスト接続をクリックする
右上にプロビジョニングする権限がありますと出たらオッケーです。

図：承認をクリックするとGoogleログインが出てくる

図：アクセスを許可する

属性マッピング

ユーザ属性情報

続けて、Entra ID側のユーザの属性情報とGoogle Workspace側のユーザ属性情報を連結する為のマッピングを行います。必要なものだけをセットすると良いでしょう。

前述の同じ画面の下にあるマッピングをクリックし、Provision Microsoft Entra ID Usersをクリックする。
属性マッピングの画面が出てくるので、今回はprimaryEmail、name.familyName、name.givenNameの3つだけにして他は削除しました。
name.familyNameおよびname.givenNameの編集をクリックする
null の場合の規定値 (オプション)の値を「_」に変更しておく
最後に保存をクリックする

別途同期させたい属性情報があれば、新しいマッピングの追加から追加することも可能です。

※但し、Entra ID側に独自ドメインをセットしユーザを独自ドメインのユーザプリンシパル名となっていない場合、onmicrosoft.comのままでは追加はできないので、グループの場合同様に変換式を追加する必要性があります。

図：マッピングメイン画面

図：属性マッピング編集画面

グループ属性情報

グループの属性情報もマッピング編集可能です。ただ問題なのは、Azure Entra IDのグループはxxxx.onmicrosoft.comという形式になっているので、これをGWS側の独自ドメインに変換するマッピングを追加する必要があります。

マッピングにおいて、Provision Microsoft Entra ID Groupsをクリックする
属性情報のmailの編集をクリックする
マッピングの種類を直接⇒式に変更する
式の欄に以下のように変換式を追加する

Join("@", NormalizeDiacritics(StripSpaces([displayName])), "ドメイン名")

1

Join("@", NormalizeDiacritics(StripSpaces([displayName])), "ドメイン名")
OKをクリックして保存をクリックする

図：Entra IDのグループドメインはonmicrosoft

図：ドメイン変換式を設定

同期対象のユーザを追加する

作成したエンタープライズアプリケーションであるAuto Provisioningの概要画面まで戻ります。そこで、次に同期対象となるEntra ID側のユーザを追加します（グループを追加する事も可能）。

今回は予め、独自ドメインにてユーザを作成しており、このユーザをGWS側に自動プロビジョニングさせます。

左サイドパネルからユーザとグループをクリックする
上部のユーザまたはグループの追加をクリックする
ユーザの選択されていませんをクリックし、作成しておいたユーザにチェックを入れて、選択をクリックします。
下部にある割り当てをクリックする

これで同期対象が選定できました。

図：同期対象ユーザの追加

プロビジョニングの実行

同期の開始

ここまででGoogle WorkspaceおよびAzure Entra IDのプロビジョニングに関する準備が整いました。早速実行して、Google Workspace側にユーザが同期されるかテストしてみたいと思います。

作成したエンタープライズアプリケーションのプロビジョニングの概要に入る
左サイドバーからプロビジョニングをクリックする
さらにプロビジョニングに入り編集画面を開く
下部にあるプロビジョニング状態を「オン」にして、保存をクリックする
上部に「プロビジョニングの開始」という項目があるのでクリックする

同期の間隔は40〜80分で行われるようです。オンデマンドでプロビジョニングにて手動で即座に特定ユーザのみを反映してテストが出来ます。

図：ステータスの変更を行う

図：プロビジョニング開始

同期の検証

少しいろいろな面で検証をしてみました。

アカウントを削除

GWS側でアカウントを削除後に、Entra ID側で再度手動でプロビジョニングすると新たに同じアカウントが生成されました。常にEntra ID側からスケジューリングで同期が掛かり指定ユーザについては常に存在するようになります。

逆にEntra ID側で同期対象ユーザから除外場合どうなるのか？そのまま1時間程度放置してみました（手動で出来ない為）。

この場合こちらにも記載があるように（Google側のドキュメントだとこちらになる）、Google Workspace側のユーザは「停止」となり、アカウントが削除されることはありません。よって、手動で削除する必要があります（なんですが、自分で検証してみた結果、サスペンドされてなかった・・・）。

マッピングにて、ソースのsuspendedの値をGWS側のsuspendedに対して同期を掛けることで手動でも停止をさせることが可能です。初回同期はさせるけれど停止状態にしたい場合などでも利用します（Cloud Identity Freeライセンスで追加されても、一部のGoogleサービスは使えてしまう為）

組織部門について

個別メンバーに設定する方法

デフォルトのままだとGoogle Workspace側の特定の組織部門に所属するようにマッピングが出来ません。ルートの組織に登録されてしまいます。また、Entra IDとGWSでは組織部門的な管理手法が異なるので、例えばEntra ID側の管理単位は複数所属可能なのでそのまま適用も出来ません。

ローカルADからEntra IDへConnectで属性値のマッピングをしてる場合、15個のextensionAttributeという属性値にマップして、それをプロビジョニングのマップで選択して使えるのですが、問題はこの値、Azure Entra ID上ではGUIで設定する手段がありません（Graph APIを使って設定は可能）。

トリッキーなテクですが、以下のようにして組織部門として設定して同期を掛けられます。

ユーザのプロパティの利用頻度が低いフィールドを代用する（例えばFAX番号）
1.のフィールドに対して、GWSのルートから見てサブディレクトリをパスとして入力（今回はルート直下にentra_idという組織部門を作ったので、ここに同期するならば、/entra_idと入力する）
プロビジョニングのマッピングに於いて、ソース属性は「facsimile TelephoneNumber」を指定
対象の属性は、「OrgUnitPath」を指定
OKをクリックして、保存をクリックする

実際に既にルート直下で同期をしてしまったユーザに対して手動で同期を掛けてみた所、きちんと所属する組織部門が変更されました。

OrgUnitPathはルートから見てのパスとなるのでさらにサブディレクトリがあるならば、/entra_id/subdirnameといったようにパスを入力すれば、深い組織部門に細かく配置することが可能です。

※Null値だったらというケースを検証してみましたが、Null判定されずエラーになりました。故に必ず対象のプロパティに組織部門のパスを入れておく必要性があります。

※ユーザ数が膨大で個別ユーザのプロパティ変更なんてやってられないというケースの場合は、GASなどを利用して、スプレッドシートの値をもって一括で反映するようなことが可能です（Graph APIを利用しています）

Google Apps ScriptからAzure Entra IDのユーザ情報読み書き【GAS】

図：空いてるフィールドを代用する

アプリロールで設定する方法

前述の方法の場合、個別のユーザのプロパティにそれぞれ値をセットしなければなりません。少人数ならともかく相応の人数がいる場合にはなかなか組織部門の変更をするとなると面倒です。

そこでこちらのサイトで紹介されてるようなグループとアプリロールを使った手法でまとめてマッピングを設定することが可能です。アプリロール作成とグループで同期させる手法はEntra ID P1もしくはP2のライセンスが必要です。以下の手順でグループとアプリロールを作成します。ちょっと手順が長いです。

Azure Entra IDにログインします
左サイドバーのグループを開きます
上部メニューの新しいグループをクリックしてグループを作成し、所有者は自分、このグループがCIFという組織部門に配置予定ならば、メンバーには対象者を選んで追加します。必要な組織部門の数だけグループを用意し対象者を追加しておきます（今回はGWSとCIFの２つのグループを作成）
続いて、左サイドバーからエンタープライズアプリケーションをクリック
今回利用してる「Google Cloud / G Suite Connector by Microsoft」のプロジェクトを開く
左サイドバーのユーザーとグループを開く
左パネルに出てる文中の「アプリケーション登録」をクリックする
アプリロールの作成になっていたら、上部にある「アプリロールの作成」をクリックする
右サイドバーが出てくるので、表示名と値には組織部門へのパスをいれます（例：/CIF/test）
許可されたメンバーの種類は両方でオッケー
アプリロールを有効にしますか？のチェックはチェックを入れて、適用をクリックする
もう１つの部門用にも同じように作成する
5.のプロジェクトのトップ画面に戻り、左サイドバーからユーザとグループをクリックする
一度ここでページをリロードしましょう（アプリロールの設定値が読み込まれてないので）← Azureあるあるです
上部にあるユーザまたはグループの追加をクリックする
割り当ての追加画面になり、ユーザとグループでは作成したグループを選択します。
ロールを選択では、7.で作成したアプリロールを選択します。（Default Organizationを選ぶと同期出来ません）
割り当てをクリックします。

あとはユーザのマッピングする際に、式でもってSingleAppRoleAssignment([appRoleAssignments])を作成し、対象の属性をOrgUnitPathにすればアプリロールの値を持って、目的の組織部門へユーザを流し込むことが可能です。

※嵌り所はグループとアプリロールを使った手法で紹介されてるような「アプリの登録」からアプリロールを作っても、上記の関数からは値が取れないばかりか、14.の画面でロールの選択がグレーアウトで出来ません。そのため、関数で取得した値が「Default Organization」になってしまい、OrgUnitPathに割り当てが出来ずエラーとなります。

※故にSingleAppRoleAssignment関数にてnullだったらの処理で違う組織部門へ配属させるという手は使えません。明示的にロール選択が必須となるがゆえに、それであればもう一つのアプリロールを作るのと大差ないからです。

※１人に対して複数のロールがつくようなグループの構成にすると上手く動作しませんので１人には1ロールで運用が必要です。

※グループとアプリロールを使った手法では、アプリロールのマニフェストに「"availableToOtherTenants": false」を１行入れる設定になっていますが、今回は入れずに適用しています。

図：アプリロールを作る前の時点

図：アプリロール作成画面

図：ロールの割当画面

図：式でマッピング

プロビジョニングの注意点

グループのプロビジョニングオフでユーザ情報は反映するのか？

プロビジョニングにて前述のようにアプリロールをつけたグループを対象として追加しつつも、Microsoft365側の他のグループアドレスそのものをプロビジョニングするつもりはないので、マッピングでは「オフ」にしています。

この時、プロビジョニング対象としてユーザではなくセキュリティグループを追加していますが、これでグループ内部メンバーの情報が反映されて、Google Workspace側にユーザ作成や更新がされるのか？といったら問題なくされます。マッピングのオフはあくまでも「グループアドレスそのものを反映するかどうか？」についての設定であり、プロビジョニングのアプリとしてユーザ・グループを登録してるものについてはこの対象になりません。

よって、ユーザ単位で追加するのではなくセキュリティグループ単位でプロビジョニング対象として追加して問題ありません。

オンデマンドプロビジョニング

一方でオンデマンドプロビジョニング（手動でプロビジョニングを行う）については、対象としてグループは選べるものの、中にいるユーザを結局は選択することになります（最大5名しかオンデマンドでは実行できない）。

またこの時、エラーログに「skipped」として「EntityTypeNotSupported」が記録されます。これはエラーというわけではなく、グループアドレスそのものを出力しようとして出てるものなので、Skippedで問題ありません。

ただし5名までしかプロビジョニングされないので、大量のユーザを反映したいという本番の場合には同期が走るのを待つ必要があります。

図：オンデマンドだと出る項目

プロビジョニングに掛かる時間

プロビジョニングに掛かる時間は初回と2回目以降とでは大きく変わります。後者の場合は差分アップデートになるため、初回とは違い更新される数も少ないため、多くても30分以内に完了するようです。

しかし前者の初回実行の場合はユーザ作成なども含まれるため、ユーザのプロビジョニングのみであれば「割り当てられたユーザーとグループのみを同期する」の数値によると、 142 - 708分（1000名〜10000名）となっています（必ずしも10000名だからといって1000名の10倍掛かるわけじゃない）。

よって3000名であれば最大で掛かる時間から割り戻すと1人あたり4秒くらいの感覚でプロビジョニング出来るのではないかと思われます。

GCDSを停止して切り替えるケース

すでにGCDSをつかってローカルADからGWSへプロビジョニングをしてるケースに於いて、Entra IDに切り替えて今回のプロビジョニング＆SSOとする場合は、もともとGCDSはタスクスケジューラによって随時自動で同期をかけてる状態であるので

GCDSを停止する
Entra IDのプロビジョニングを開始する

でオッケーです。Password Syncを併用してると思われるのでそちらも停止が必要です。

また、GCDSはWindows Serverのタスクスケジューラから呼ばれて動いてるだけなので、「C:\Program Files\Google Cloud Directory Sync\sync-cmd.exe」を呼び出してるタスクスケジューラを探し出して、停止や削除をすればオッケーです。

該当タスクが見つけにくい場合は

管理者権限でコマンドプロンプトを起動する
以下のコマンドを実行する

schtasks /query /V /FO CSV > C:\tasklist.csv

1

schtasks /query /V /FO CSV > C:\tasklist.csv
C:¥直下の対象のCSVを見て、上記のsync-cmd.exeを探し出す

で見つけることが可能です。

野良アカウントが存在する場合

以下は、管理対象外ユーザの管理でも詳細に説明しています。

Google Workspaceの管理対象に含まれないユーザ用の移行ツールを検証してみた

プロビジョニングをしてしまうと・・・

通常、Google Workspaceのテナントに於いてユーザを手動で追加した場合に、同名のドメインのgoogleアカウントが外部に存在する場合、競合するアカウントとして検出され、競合するアカウントの設定に基づいて対象者に移行招待のメールが飛ぶ、もしくはgtempaccount.comに変換されてテナントにアカウントが作成されます。

これらは競合アカウントの解消を手動で行う場合のフローになります。また、Directory APIで作業を行った場合も同様です（ブログの記事）。

一方で、Entra IDからのプロビジョニングを実行した場合には、この設定によらず強制的にアカウントが作成され、対象の野良アカウントはgtempaccount.comに変換されてしまいます。よって、移行招待のメールが飛ばず、野良アカウントを即座に解消してしまいます。つまり、Directory APIに基づかないでプロビジョニングが実行されている（この件についてどこにも公式ドキュメントには記載がありません）。

強制移行された後

また、この時旧来の野良アカウント側は

username%domainname@gtempaccount.comというアカウント名に変換される（例：yamada%hoge.com@gtempaccount.com)
データはこのgtempaccount.comに保存されている
Google Takeoutからデータをバックアップし、本来のドメインのアカウントに対してアップロードは可能。
外部GoogleサービスであるGoogle Analyticsなどはgtempaccount.comで入ることが可能
この際に、本来のドメインのアカウントに対してアカウントの管理から管理者等として追加することで、再度引き継ぐことが可能

よって、野良アカウントが業務で活用されていると思われる場合には、手動でユーザを追加し競合アカウントに通知を送ってからから、Entra IDからのプロビジョニングを実行するのが望ましい（ユーザが対処をしたのちにプロビジョニングのグループに追加してあげる）

図：Analyticsはgtempaccountで入れる

図：GWSのアカウントを共有に追加して譲渡可能

野良アカウントに戻す手法

一度、Google Workspaceのテナントに対象アカウントを強制的に移行させてしまった場合、元の同名アカウントにあるデータは引き継げません。また、Analyticsなどのアカウントも移行されてるわけではないので、このままだとユーザに一手間かけてもらって前述のように本来のGWSアカウントに共有を掛けたり、ドライブに手動でアップロードが必要です。

では元に戻せないのか？といったら、以下の手法で戻すことが可能です。ユーザの方に作業を１つして貰う必要があります。

Google Workspace側のテナントから対象ユーザを削除する（まだgtempaccount.comが存在してることを要確認）
Entra ID側のグループアドレスから対象のユーザを外しておく（同期が走ると再度作成されてしまう為）
ユーザ側はgtempaccount.comのアカウント設定画面に入り、Googleアカウントのメールアドレスのメアドをクリック
本来のドメインのメアドを入れて変更を掛ける（例：test@domain.comなど）
確認のメールがtest@domain.comに届くので、メール本文内の「こちらをクリック」をクリックする
変更が完了し、元の野良アカウントとしてドメインのあるアカウントに戻る
この状態で、Google Workspace側で再度同じアカウントに対して手動でユーザを追加すると招待メール送信画面が出るので、招待を掛ける

7.の状態にまでなったら、移管が完了したものから順次、Entra IDのグループアドレスに追加を行い、プロビジョニングを実施します。

図：ユーザ側で再度元のメアドに戻す手順

図：変更確認のメールが来る

図：再度招待メールが送れるようになる

競合するアカウントの管理の自動送信について

今回の取組の中で競合するアカウントの管理の機能について不可解な点があった為以下にまとめておきます。

競合するアカウントの管理に於いて、ユーザの自動招待を期待してCSVでの一括追加を行ったものの作動せず強制的に移行が行われました。
また、自動送信を利用せず「競合する管理対象外のアカウントを管理対象のアカウントの置き換えない」にセットしてる場合は、CSVでの追加やEntra IDでのプロビジョニングでは「CONSUMER_ACCOUNT_CONFLICT」や「GoogleAppsObjectNotFound」としてエラーとなり追加そのものが出来ませんでした。
手動で追加の場合についてはどちらの設定であっても「必ず招待の可否のダイアログ」が出る
Directory APIの場合はドキュメントにもあるように「resolveConflictAccount=true」のパラメータを追加する必要がある。

また、対象のテナントにMXレコードが設定されていない場合、招待メールが遅れるかどうかは確認が必要です（ライセンスによってはメール機能が無い為）。

結果的に競合アカウントの管理をするうえでは、対象のユーザを選定し手動で追加する必要性があり、自動送信の機能が動くシーンが非常に限られてるため、プロビジョニング前にこれらは別にわけて処理をしておく必要があります。

GASでresolveConflictAccountを付けて作成

前述の通り、Directory APIでユーザを作成する場合のドキュメントにはresolveConflictAccountのクエリパラメータをtrueにして送信しろと書いてあります。UrlfetchAppであるならばURLのパラメータにつなげて掛けば良いとは思うのですが、Google Apps Scriptでの送信方法がウェブ上のどこにも書いてありません。

そこで色々なパターンを試してみましたが、GASでこれを実現するにはちょっと工夫が必要です。以下のエントリーを参照して実装し、先に競合を検出して競合アカウントを解消してから、プロビジョニングを実行する必要があります。

Google Apps Scriptでユーザの一括作成・削除をする【GAS】

Google Workspaceの管理対象に含まれないユーザ用の移行ツールを検証してみた

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - Provisioning編

今回利用する機能