はじめに

自社EntraIDにゲストユーザーとして登録した別ドメインのユーザーを、EntraIDに連携させたBoxへ自動プロビジョニングさせたので、備忘録として内容をまとめました。

定義

登場人物がいろいろ出てくるので事前に定義します。

本社A：組織構造としては事業会社Bの親会社
- EntraID-AAA
  - ドメイン＝aaa.hoge.com
- BoxテナントA
  - EntraID-AAAとSAML連携＋自動プロビジョニング設定済
事業会社B：親会社とは別でAzure/Boxの契約をしている
- EntraID-BBB
  - ドメイン＝bbb.hoge.com
- BoxテナントB
  - EntraID-BBBとSAML連携＋自動プロビジョニング設定済

現状の環境は以下のような図になります。

背景

本社Aと事業会社BでそれぞれBoxテナントを契約しており、それぞれが管理するEntraIDに対してSAML連携と自動プロビジョニング設定をしていた
事業統合に伴い事業会社Bで契約していたBoxテナントを本社AのBoxテナントに契約を統一することが想定されており、そのための要件として以下の内容が上がった
- 要件1：BoxテナントAの中に事業会社Bのユーザーを取り込む
- 要件2：EntraIDは統合せず維持させる
- 要件3：事業会社Bのアカウントはそのまま使う（user1@bbb.hoge.com）

課題

この構成にするためのハードルはいくつかあるのですが、とりあえず認証とプロビジョニングの課題を解決します。

課題一覧：

１つのBoxテナントは1つのIdPしか参照できない
EntraID-AAAを参照したまま、EntraID-BBB のアカウントを使ったSAMLSSOを実現しなければならない
自動プロビジョニングもさせないといけない

解決にむけての試行錯誤

Boxテナントは基本的にIdPを1つしか参照できません。
そのためBoxテナントAを継続的に利用することを考えると必然的に "EntraID-AAA" が連携先になるわけですが

要件2「それぞれのEntraIDは維持する」
要件3「アカウントをそのまま使う」

というものがあるため、bbb.hoge.com のドメインは引き続き "EntraID-BBB" で管理されたままになると困ります。

ひとまずこの打開策として "EntraID-AAA" にゲストユーザーとして user1@bbb.hoge.com を登録することにし、登録されたゲストユーザーを自動プロビジョニングすることにしました。

が、この方法は残念ながら失敗します。
"EntraID-AAA" にゲストユーザーとして登録されたアカウントをプロビジョニングすると、下記のような状態となりました。

このような状態となってしまうのは、以下2つの設定内容に起因します。

"EntraID-AAA"に登録されたゲストユーザーのUPN が onmicrosoft.com ドメインに置換される
"EntraID-AAA" ～ "BoxテナントA" 間に設定された自動プロビジョニング設定

① "EntraID-AAA"に登録されたゲストユーザーのUPN が onmicrosoft.com ドメインに置換される

EntraIDに登録される通常ユーザー、ゲストユーザーには以下のような属性の違いがあります。

通常ユーザー

ユーザー種別	        : メンバー
DisplayName		    : user2
Mail			    : user2@aaa.hoge.com
UserPrincipalName	: user2@aaa.hoge.com

ゲストユーザー

ユーザー種別		    : ゲスト
DisplayName		    : user1
Mail			    : user1@bbb.hoge.com
UserPrincipalName	: user1_bbb.hoge.com#EXT#@hoge.onmicrosoft.com  <= ココ

EntraIDの仕様上、ゲストアカウントには #EXT@ に変換されたアドレスが自動登録されます。

② "EntraID-AAA" ～ "BoxテナントA" 間に設定された自動プロビジョニング設定

デフォルトのプロビジョニング設定の場合はこんな感じだと思います。

このような設定だと、UserPrincipalName には ~~~#EXT@***.onmicrosoft.com が格納されているため、上図のようなBoxユーザーが生成されることになりました。

これを解消するためには、 自動プロビジョニングの属性マッピング と シングルサインオンの属性とクレームの値 を変更する必要があります。

自動プロビジョニングの属性マッピングの設定変更

Azure Active Directory属性＝UserPrincipalName
Box属性＝Login

↓↓↓↓

Azure Active Directory属性＝mail
Box属性＝Login

シングルサインオンの属性とクレームの値の設定変更

givenname           user.givenname
surname             user.surname
emailaddress	    user.mail
name		        user.UserPrincipalName
一意のユーザー ID	user.UserPrincipalName

↓↓↓↓

givenname           user.givenname
surname             user.surname
emailaddress        user.mail
name                user.mail
一意のユーザー ID	user.mail

連携プロセスを図解するとこんな感じ

こんな感じの連携を組むことで、"BoxテナントA" に user1@bbb.hoge.com のBoxアカウントを自動プロビジョニングで生成することができました。

この構成にすると、認証プロセスとしては

[BoxテナントA] -> [EntraID-AAA] -> [EntraID-BBB]

として処理されることになり、事業会社Bのユーザーは今まで通りのユーザーID・パスワードを利用してBoxを利用することができます。

補足

今回はBoxを対象としましたが、どのSaaSであっても同じ仕組みでゲストユーザーのプロビジョニングは解決できると思います。

残課題

"EntraID-AAA" に登録されているゲストユーザーを #EXT@ の形にならないように自動プロビジョニングすることはできましたが、毎回 "EntraID-AAA" に登録することは手間です。

なので、それぞれのテナント内の通常ユーザーを自動でゲストとして登録することが可能となる "cross-tenant-synchronization" の機能を使って、組織間のアカウントライフサイクルも自動化しようと思います。
https://learn.microsoft.com/ja-jp/entra/identity/multi-tenant-organizations/cross-tenant-synchronization-overview

EntraIDのゲストユーザーを自動プロビジョニングした話