テナント間同期を構成する

この記事では、Microsoft Entra 管理センターを利用してテナント間同期を構成する手順について説明します。 構成すると、Microsoft Entra ID により、ターゲット テナント内の B2B ユーザーが自動的にプロビジョニングおよび解除されます。

このサービスの機能、しくみ、よく寄せられる質問の重要な詳細については、「 Microsoft Entra ID を使用して SaaS アプリケーションへのユーザー プロビジョニングとプロビジョニング解除を自動化する」を参照してください。

Von Bedeutung

クラウド間同期は現在プレビュー段階です。 この情報は、リリース前に大幅に変更される可能性があるプレリリース製品に関連しています。 Microsoft は、ここに記載されている情報に関して、明示または黙示を問わず、一切の保証を行いません。

この記事では、Microsoft クラウド間のテナント間同期を構成する手順について説明します。 構成すると、Microsoft Entra ID により、ターゲット テナント内の B2B ユーザーが自動的にプロビジョニングおよび解除されます。 このチュートリアルでは、商用クラウド (米国政府> ) からの ID の同期に重点を置いていますが、政府 --> 商用と中国 --> Commercial にも同じ手順が適用されます。

このサービスの機能、しくみ、よく寄せられる質問の重要な詳細については、「 Microsoft Entra ID を使用して SaaS アプリケーションへのユーザー プロビジョニングとプロビジョニング解除を自動化する」を参照してください。 テナント間同期とクラウド間同期の違いについては、 よく寄せられる質問のクラウド間同期に関するページを参照してください。

サポートされているクラウド ペア

テナント間同期では、次のクラウド ペアがサポートされます。

情報源	目標	Azure portal のリンク ドメイン
Azure 商用	Azure 商用	portal.azure.com -->portal.azure.com
Azure Government（アジュール・ガバメント）	Azure Government（アジュール・ガバメント）	portal.azure.us -->portal.azure.us

クラウド間同期では、次のクラウド ペアがサポートされます。

情報源	目標	Azure portal のリンク ドメイン
Azure 商用	Azure Government（アジュール・ガバメント）	portal.azure.com -->portal.azure.us
Azure Government（アジュール・ガバメント）	Azure 商用	portal.azure.us -->portal.azure.com
Azure 商用	21Vianet によって運営される Azure (中国の Azure)	portal.azure.com -->portal.azure.cn

学習の目的

この記事を最後まで読むと、次のことができるようになります。

• ターゲット テナントで B2B ユーザーを作成する
• ターゲット テナントで B2B ユーザーを削除する
• ソースとターゲットのテナント間でユーザー属性の同期を維持する

前提条件

ソース テナント

• Microsoft Entra ID P1 または P2 ライセンス。 詳細については、「 ライセンス要件」を参照してください。
• テナント間アクセス設定を構成するためのセキュリティ管理者ロール。
• テナント間同期を構成するためのハイブリッド ID 管理者ロール。
• 構成にユーザーを割り当て、構成を削除するクラウド アプリケーション管理者またはアプリケーション管理者ロール。

• Microsoft Entra ID ガバナンスまたは Microsoft Entra Suite ライセンス。 詳細については、「 ライセンス要件」を参照してください。
• テナント間アクセス設定を構成するためのセキュリティ管理者ロール。
• テナント間同期を構成するためのハイブリッド ID 管理者ロール。
• 構成にユーザーを割り当て、構成を削除するクラウド アプリケーション管理者またはアプリケーション管理者ロール。

ターゲット テナント

• Microsoft Entra ID P1 または P2 ライセンス。 詳細については、「 ライセンス要件」を参照してください。
• テナント間アクセス設定を構成するためのセキュリティ管理者ロール。

• Microsoft Entra ID ガバナンスまたは Microsoft Entra Suite ライセンス。 詳細については、「 ライセンス要件」を参照してください。
• テナント間アクセス設定を構成するためのセキュリティ管理者ロール。

手順 1: プロビジョニングの展開を計画する

1. 組織内のテナントを構成する方法を定義します。

2. プロビジョニング サービスのしくみについて説明します。

3. プロビジョニングの対象となるユーザーを決定します。

4. テナント間でマップするデータを決定します。

手順 1: 両方のテナントでクラウド間設定を有効にする

ソース テナント

1. ソース テナントの Microsoft Entra 管理センター にサインインします。

2. [ID]、>、[テナント間アクセス設定] の順に移動します。

3. [ Microsoft クラウドの設定 ] タブで、共同作業を行うクラウド ( Microsoft Azure Government など) のチェック ボックスをオンにします。

   クラウドの一覧は、使用しているクラウドによって異なります。 詳細については、「 Microsoft クラウド設定」を参照してください。

   

4. [保存] を選択します。

ターゲット

1. ターゲット テナントの Microsoft Entra 管理センター にサインインします。

2. [ID]、>、[テナント間アクセス設定] の順に移動します。

3. [ Microsoft クラウド設定 ] タブで、ソース テナントのクラウド間同期チェック ボックス ( Microsoft Azure Commercial など) を選択します。

   

   このチェック ボックスをオンにすると、次のアクセス許可を持つサービス プリンシパルが作成されます。

   • User.ReadWrite.CrossCloud
   • User.Invite.All
   • Organization.Read.All
   • Policy.Read.All

4. [保存] を選択します。

手順 2: ターゲット テナントでユーザーの同期を有効にする

ターゲット テナント

1. ターゲット テナントの Microsoft Entra 管理センター にサインインします。

2. [Entra ID]>[External Identities]>[クロステナント アクセス設定] に移動します。

3. [ 組織の設定 ] タブで、[ 組織の追加] を選択します。

4. テナント ID またはドメイン名を入力し、[追加] を選択して、ソース テナントを 追加します。

   

5. 追加した組織の 受信アクセス で、[ 既定から継承] を選択します。

6. [ クロステナント同期 ] タブを選択します。

7. [ ユーザーがこのテナントへの同期を許可する ] チェック ボックスをオンにします。

   

8. [保存] を選択します。

9. テナント間の同期と自動引き換えの有効化 ダイアログ ボックスが表示された場合、自動引き換えを有効にするか尋ねられます。 [ はい] を選択してください。

   [ はい ] を選択すると、ターゲット テナントで招待が自動的に引き換えられます。

   

手順 3: ターゲット テナントで招待を自動的に引き換える

ターゲット テナント

このステップでは、ソース テナントのユーザーが同意プロンプトに同意する必要がないように、招待を自動的に引き換えます。 この設定は、ソース テナント (アウトバウンド) とターゲット テナント (インバウンド) の両方でオンにする必要があります。 詳細については、「 自動引き換え設定」を参照してください。

1. ターゲット テナントの同じ [受信アクセス設定 ] ページで、[ 信頼設定 ] タブを選択します。

2. [テナントで招待を自動的に引き換える]<[テナント]> チェック ボックスをオンにします。

   [テナント間の同期と自動引き換えの有効化] ダイアログ ボックスで以前に [はい] を選択した場合、このボックスは既にオンになっている可能性があります。

   

3. [保存] を選択します。

手順 4: ソース テナントで招待を自動的に引き換える

ソース テナント

このステップでは、ソース テナントで招待を自動的に受け入れます。

1. ソース テナントの Microsoft Entra 管理センター にサインインします。

2. [Entra ID]>[External Identities]>[クロステナント アクセス設定] に移動します。

3. [ 組織の設定 ] タブで、[ 組織の追加] を選択します。

4. テナント ID またはドメイン名を入力し、[追加] を選択して、ターゲット テナントを 追加します。

   

5. ターゲット組織の送信アクセスで、既定から継承を選択します。

6. [ 信頼 設定] タブを選択します。

7. [テナントで招待を自動的に引き換える]<[テナント]> チェック ボックスをオンにします。

   

8. [保存] を選択します。

手順 5: ソース テナントで構成を作成する

ソース テナント

1. ソース テナントで、Entra ID>外部 ID>クロステナント同期に移動します。

   

   Azure portal を使用している場合は、Microsoft Entra ID>の管理>クロステナント同期に移動します。

   

2. [構成] を選択します。

3. ページの上部にある [ 新しい構成] を選択します。

4. 構成の名前を指定します。

   

5. を選択してを作成します。

   作成した構成が一覧に表示されるまで、最大で 15 秒かかる場合があります。

4. 構成の名前を指定します。

5. [ Microsoft クラウド間のテナント間同期のセットアップ ] チェック ボックスをオンにします。

   

6. を選択してを作成します。

   作成した構成が一覧に表示されるまで、最大で 15 秒かかる場合があります。

   クラウド間同期の [構成] ページで、[ テナント名] 列と [ テナント ID ] 列が空になります。

手順 6: ターゲット テナントへの接続をテストする

ソース テナント

1. ソース テナントに新しい構成が表示されるはずです。 表示されない場合、構成リストで構成を選択します。

   

2. [ 作業の開始] を選択します。

3. [プロビジョニング モード] を[自動] に設定します。

4. [ 管理者資格情報 ] セクションで、[ 認証方法 ] を [テナント間同期ポリシー] に変更します。

   

5. [ テナント ID ] ボックスに、ターゲット テナントのテナント ID を入力します。

6. [ 接続のテスト ] を選択して接続をテストします。

   指定した資格情報でプロビジョニングを有効にすることが承認されたことを示すメッセージが表示されます。 テスト接続が失敗した場合は、この記事で後述 する一般的なシナリオと解決策 を参照してください。

   

7. [保存] を選択します。

   [マッピング] と [設定] セクションが表示されます。

8. [プロビジョニング] ページを閉じます。

手順 7: プロビジョニングの対象となるユーザーを定義する

ソース テナント

Microsoft Entra プロビジョニング サービスを使うと、次のいずれかまたは両方の方法でプロビジョニングを行うユーザーを定義できます。

• 構成への割り当てに基づく
• ユーザーの属性に基づく

小さいところから始めましょう。 全員にロールアウトする前に、少数のユーザーでテストします。 プロビジョニングのスコープを割り当て済みのユーザーとグループに設定すると、構成に 1 人または 2 人のユーザーを割り当てることで、それを制御できます。 次の手順で説明する属性ベースのスコープ フィルターを作成することで、プロビジョニングの対象となるユーザーをさらに絞り込むことができます。

1. ソース テナントで 、[ プロビジョニング ] を選択し、[ 設定] セクションを展開します。

   

2. [スコープ] ボックスの一覧で、ソース テナント内のすべてのユーザーを同期するか、構成に割り当てられているユーザーのみを同期するかを選択します。

   [すべてのユーザーとグループを同期する] ではなく、[割り当てられたユーザーとグループのみを同期する] を選択することをお勧めします。 スコープ内のユーザーの数を減らすと、パフォーマンスが向上します。

3. 変更を加えた場合は、[ 保存] を選択します。

4. [構成] ページで、[ ユーザーとグループ] を選択します。

   テナント間同期が機能するには、少なくとも 1 人の内部ユーザーを構成に割り当てる必要があります。

5. [ ユーザー/グループの追加] を選択します。

6. [ 割り当ての追加 ] ページの [ ユーザーとグループ] で、[ 選択なし] を選択します。

7. [ ユーザーとグループ ] ウィンドウで、構成に割り当てる 1 つ以上の内部ユーザーまたはグループを検索して選択します。

   グループを選んで構成に割り当てた場合、グループ内の直接メンバーであるユーザーのみがプロビジョニングの対象になります。 静的グループまたは動的グループを選択できます。 割り当ては、入れ子になったグループにはカスケードされません。

8. [選択] を選択します。

9. 割り当てを選択します。

   

   詳細については、「 アプリケーションにユーザーとグループを割り当てる」を参照してください。

ステップ 8: (省略可能) スコープ フィルターを使用してプロビジョニングの対象となるユーザーを指定します。

ソース テナント

前の手順で [スコープ ] に選択した値に関係なく、属性ベースのスコープ フィルターを作成することで、同期するユーザーをさらに制限できます。

1. ソース テナントで [ プロビジョニング ] を選択し、[マッピング] セクション を 展開します。

   

2. [Microsoft Entra ID ユーザーのプロビジョニング] を選択して、[属性マッピング] ページを開きます。

3. [ ソース オブジェクト スコープ] で、[ すべてのレコード] を選択します。

   

4. [ ソース オブジェクト スコープ] ページで 、[ スコープ フィルターの追加] を選択します。

5. プロビジョニング用のスコープに含まれるユーザーを定義するフィルターを追加します。

   スコープ フィルターを構成するには、スコープ フィルターを使用して プロビジョニングするスコープ ユーザーまたはグループに関するページに記載されている手順を参照してください。

   

6. [ OK] を 選択し 、[保存] を選択して変更を保存します。

   フィルターを追加した場合、変更を保存すると、割り当てられたすべてのユーザーとグループが再同期されることを示すメッセージが表示されます。 ディレクトリのサイズによっては、これに長い時間かかる場合があります。

7. [ はい ] を選択し、[ 属性マッピング ] ページを閉じます。

手順 9: 属性マッピングを確認する

ソース テナント

属性マッピングを使うと、ソース テナントとターゲット テナントの間でデータが流れる方法を定義できます。 既定の属性マッピングをカスタマイズする方法については、「 チュートリアル - Microsoft Entra ID で SaaS アプリケーションのユーザー プロビジョニング属性マッピングをカスタマイズする」を参照してください。

1. ソース テナントで [ プロビジョニング ] を選択し、[マッピング] セクション を 展開します。

2. [Microsoft Entra ID ユーザーのプロビジョニング] を選択します。

3. [ 属性マッピング ] ページで、下にスクロールして、[属性マッピング] セクションでテナント間で同期されるユーザー 属性を 確認します。

   最初の属性 alternativeSecurityIdentifier は、テナント間でユーザーを一意に識別し、ソース テナント内のユーザーとターゲット テナント内の既存のユーザーを照合し、各ユーザーが 1 つのアカウントしか持たないようにするために使用される内部属性です。 一致する属性は変更できません。 一致属性の変更または一致属性の追加を試みると、schemaInvalid エラーが発生します。

   

4. Member (userType) 属性を選択して、[属性の編集] ページを開きます。

5. userType 属性の定数値の設定を確認します。

   この設定では、ターゲット テナントに作成されるユーザーの種類を定義し、次の表のいずれかの値を指定できます。 既定では、ユーザーは外部メンバー (B2B コラボレーション ユーザー) として作成されます。 詳細については、「 Microsoft Entra B2B コラボレーション ユーザーのプロパティ」を参照してください。

   定数値	説明
   メンバー	既定値。 ユーザーは、外部メンバー (B2B コラボレーション ユーザー) としてターゲット テナントに作成されます。 ユーザーは、ターゲット テナントの任意の内部メンバーとして機能できます。
   ゲスト	ユーザーは、外部ゲスト (B2B コラボレーション ユーザー) としてターゲット テナントに作成されます。

   注

   B2B ユーザーが既にターゲット テナントに存在する場合、[このマッピングの適用] 設定が [常に] に設定されていない限り、Member (userType) はメンバーに変更されません。

   選択したユーザーの種類には、アプリまたはサービスに対して次の制限があります (ただし、これらに限定されません)。

   アプリまたはサービス	制限事項
   Power BI	- Power BI での UserType Member のサポートは現在プレビュー段階です。 詳細については、「 Microsoft Entra B2B を使用して外部ゲスト ユーザーに Power BI コンテンツを配布する」を参照してください。
   Azure Virtual Desktop	- 制限事項については、「 Azure Virtual Desktop の前提条件」を参照してください。
   Microsoft Teams	- 制限事項については、「 他の Microsoft 365 クラウド環境のゲストとの共同作業」を参照してください。

   

6. 変換を定義する場合は、[ 属性マッピング ] ページで、変換する属性 ( displayName など) を選択します。

7. [マッピング] の種類を [式] に設定します。

8. [ 式 ] ボックスに、変換式を入力します。 たとえば、表示名の場合は、次のようにできます。

   • 名と姓を入れ替えて、その間にコンマを追加します。
   • 表示名の最後に、かっこで囲んだドメイン名を追加します。

   例については、 Microsoft Entra ID での属性マッピングの式の記述に関するリファレンスを参照してください。

   

ヒント

テナント間同期のスキーマを更新することで、ディレクトリ拡張機能をマップできます。 詳細については、「 テナント間同期でのディレクトリ拡張機能のマップ」を参照してください。

手順 10: 追加のプロビジョニング設定を指定する

ソース テナント

1. ソース テナントで 、[ プロビジョニング ] を選択し、[ 設定] セクションを展開します。

   

2. [ エラー発生時に電子メール通知を送信する ] チェック ボックスをオンにします。

3. [ 通知メール ] ボックスに、プロビジョニング エラー通知を受信するユーザーまたはグループのメール アドレスを入力します。

   ジョブが検疫状態になってから 24 時間以内に、メール通知が送信されます。 カスタム アラートについては、「プロビジョニングと Azure Monitor ログの統合方法について」を参照してください。

4. 誤って削除されないようにするには、[ 誤って削除されないように する] を選択し、しきい値を指定します。 既定では、しきい値は 500 に設定されます。

   詳細については、「 Microsoft Entra プロビジョニング サービスで誤削除防止を有効にする」を参照してください。

5. [ 保存] を 選択して変更を保存します。

手順 11: オンデマンドのプロビジョニングをテストする

ソース テナント

構成が完了したので、いずれかのユーザーでオンデマンド プロビジョニングをテストできます。

1. ソース テナントで、Entra ID>外部 ID>クロステナント同期に移動します。

2. [ 構成] を選択し、構成を選択します。

3. オンデマンドプロビジョン を選択します。

4. [ ユーザーまたはグループの選択 ] ボックスで、いずれかのテスト ユーザーを検索して選択します。

   

5. プロビジョン を選択します。

   しばらくすると、[ アクションの実行 ] ページが表示され、ターゲット テナントでのテスト ユーザーのプロビジョニングに関する情報が表示されます。

   

   ユーザーがスコープ内ではない場合は、テスト ユーザーがスキップされた理由に関する情報を含むページが表示されます。

   

   [ オンデマンドプロビジョニング ] ページでは、プロビジョニングに関する詳細を表示し、再試行するオプションを選択できます。

   

6. ターゲット テナントで、テスト ユーザーがプロビジョニングされたことを確認します。

   

7. すべてが期待どおりに動作している場合は、構成に追加のユーザーを割り当てます。

   詳細については、「 Microsoft Entra ID でのオンデマンド プロビジョニング」を参照してください。

手順 12: プロビジョニング ジョブを開始する

ソース テナント

プロビジョニング ジョブは、[設定] セクションのスコープで定義されているすべてのユーザーの初期同期サイクルを開始します。 初期サイクルは後続の同期よりも実行に時間がかかります。後続のサイクルは、Microsoft Entra のプロビジョニング サービスが実行されている限り約 40 分ごとに実行されます。

1. ソース テナントで、Entra ID>外部 ID>クロステナント同期に移動します。

2. [ 構成] を選択し、構成を選択します。

3. [ 概要 ] ページで、プロビジョニングの詳細を確認します。

   

4. [ プロビジョニングの開始] を選択して、プロビジョニング ジョブを開始します。

手順 13: プロビジョニングを監視する

ソースとターゲット テナント

プロビジョニング ジョブを開始したら、状態を監視できます。

1. ソース テナントの [概要 ] ページで、進行状況バーを確認して、プロビジョニング サイクルの状態と完了までの時間を確認します。 詳細については、「 ユーザー プロビジョニングの状態を確認する」を参照してください。

   プロビジョニングが正常でない状態に見える場合、構成は隔離されます。 詳細については、「 検疫状態のアプリケーション プロビジョニング」を参照してください。

   

2. [ プロビジョニング ログ] を 選択して、どのユーザーが正常にプロビジョニングされたか、失敗したかを判断します。 既定では、ログは構成のサービス プリンシパル ID でフィルター処理されます。 詳細については、Microsoft Entra ID でのプロビジョニングログを参照してください。

   

3. Microsoft Entra ID でログに記録されたすべてのイベントを表示するには、[ 監査ログ ] を選択します。 詳細については、「 Microsoft Entra ID の監査ログ」を参照してください。

   

   ターゲット テナントでの監査ログを見ることもできます。

4. ターゲット テナントで、[ ユーザー>監査ログ ] を選択して、ユーザー管理のログに記録されたイベントを表示します。 ターゲット テナントでのテナント間同期は、アクターとして "Microsoft.Azure.SyncFabric" アプリケーションとしてログに記録されます。

   

手順 14: 脱退の設定を構成する

ターゲット テナント

ユーザーがターゲット テナントでプロビジョニングされている場合でも、ユーザーは自分自身を削除できる可能性があります。 自分自身を削除したユーザーがスコープ内にいる場合、そのユーザーは次のプロビジョニング サイクル中に再びプロビジョニングされます。 ユーザーが組織から自分自身を削除できないようにするには、 外部ユーザーの休暇設定を構成する必要があります。

1. ターゲット テナントで、Entra ID>外部ID>外部コラボレーション設定を参照します。

2. [ 外部ユーザーの脱退設定] で、外部ユーザーが自分で組織から離れることを許可するかどうかを選択します。

この設定は B2B コラボレーションと B2B 直接接続にも適用されるため、 外部ユーザーの休暇設定 を [いいえ] に設定した場合、B2B コラボレーション ユーザーと B2B 直接接続ユーザーは組織を離れることはできません。 詳細については、「 組織を外部ユーザーとして脱退する」を参照してください。

一般的なシナリオとソリューション

現象 - AzureActiveDirectoryCrossTenantSyncPolicyCheckFailure でテスト接続が失敗する

ソース テナントでテナント間同期を構成し、接続をテストすると、次のいずれかのエラー メッセージで失敗します。

ソース テナントで自動引き換えがセットアップされていない

You appear to have entered invalid credentials. Please confirm you are using the correct information for an administrative account.
Error code: AzureActiveDirectoryCrossTenantSyncPolicyCheckFailure
Details: The source tenant has not enabled automatic user consent with the target tenant. Please enable the outbound cross-tenant access policy for automatic user consent in the source tenant. aka.ms/TroubleshootingCrossTenantSyncPolicyCheck

ターゲット テナントで自動引き換えが設定されていない

You appear to have entered invalid credentials. Please confirm you are using the correct information for an administrative account.
Error code: AzureActiveDirectoryCrossTenantSyncPolicyCheckFailure
Details: The target tenant has not enabled inbound synchronization with this tenant. Please request the target tenant admin to enable the inbound synchronization on their cross-tenant access policy. Learn more: aka.ms/TroubleshootingCrossTenantSyncPolicyCheck

原因

このエラーは、ソース テナントまたはターゲット テナントの招待を自動的に引き換えるポリシーが設定されなかったことを示します。

解決

「手順 3: ターゲット テナントで招待を自動的に利用する」と「手順 4: ソース テナントの招待を自動的に引き換える」の手順に従います。

現象 - ExternalTenantNotFound でテスト接続が失敗する

ソース テナントでクラウド間同期を構成し、接続をテストすると、次のエラー メッセージで失敗します。

You appear to have entered invalid credentials. Please confirm you are using the correct information for an administrative account.
Error code: ExternalTenantNotFound
Details: This tenant was not found by the authentication authority of the current cloud: <targetTenantId>. The authentication authority is https://login.microsoftonline.com/<targetTenantId>.

原因

このエラーは、[ Microsoft クラウド間のテナント間同期のセットアップ ] チェック ボックスがオフになっていることを示します。 

解決

1. ソース テナントで、接続に失敗した作成した構成を削除します。

2. ターゲット テナントで、新しい構成を作成し、「手順 5: ソース テナントで構成を作成する」の説明に従って、[Microsoft クラウド間のテナント間同期のセットアップ] チェック ボックスをオンにします。

現象 - AzureActiveDirectoryTokenExpired でテスト接続が失敗する

ソース テナントでクラウド間同期を構成し、接続をテストすると、次のエラー メッセージで失敗します。

You appear to have entered invalid credentials. Please confirm you are using the correct information for an administrative account.
Error code: AzureActiveDirectoryTokenExpired
Details: The identity of the calling application could not be established.

原因

このエラーは、同期のクラウド間設定が有効になっていない場合を示します。 

解決

ターゲット テナントの [Microsoft クラウド設定 ] タブで、ソース テナントのクラウド間同期チェック ボックスをオンにします。 手順 1: 両方のテナントでクラウド間設定を有効にする手順に従います。

現象 - [自動引き換え] チェックボックスが無効になっている

テナント間同期を構成する場合、[ 自動引き換え ] チェックボックスは無効になります。

原因

お使いのテナントに Microsoft Entra ID P1 または P2 ライセンスがありません。

解決

信頼設定を構成するには、Microsoft Entra ID P1 または P2 が必要です。

現象 - ターゲット テナントで最近削除されたユーザーが復元されない

ターゲット テナントで同期されているユーザーを論理的に削除した後、次の同期サイクルの間は、そのユーザーは復元されません。 オンデマンド プロビジョニングを使用してユーザーを論理的に削除した後、そのユーザーを復元しようとすると、ユーザーが重複する可能性があります。

原因

以前にターゲット テナントで論理的に削除されたユーザーの復元は、サポートされていません。

解決

ターゲット テナントでソフト削除されたユーザーは、手動で復元してください。 詳細については、「 Microsoft Entra ID を使用して最近削除されたユーザーを復元または削除する」を参照してください。

現象 - ユーザーに対して SMS サインインが有効になっているため、ユーザーはスキップされます

ユーザーは同期からスキップされます。 スコープステップには、状態が false の以下のフィルターが含まれています:「Filter external users.alternativeSecurityIds EQUALS 'None'」

原因

ユーザーに対して SMS サインインが有効になっている場合、プロビジョニング サービスによってスキップされます。

解決

ユーザーの SMS サインインを無効にします。 次のスクリプトは、PowerShell を使用して SMS サインインを無効にする方法を示しています。

##### Disable SMS Sign-in options for the users

#### Import module
Install-Module Microsoft.Graph.Users.Actions
Install-Module Microsoft.Graph.Identity.SignIns
Import-Module Microsoft.Graph.Users.Actions

Connect-MgGraph -Scopes "User.Read.All", "Group.ReadWrite.All", "UserAuthenticationMethod.Read.All","UserAuthenticationMethod.ReadWrite","UserAuthenticationMethod.ReadWrite.All"

##### The value for phoneAuthenticationMethodId is 3179e48a-750b-4051-897c-87b9720928f7

$phoneAuthenticationMethodId = "3179e48a-750b-4051-897c-87b9720928f7"

#### Get the User Details

$userId = "objectid_of_the_user_in_Entra_ID"

#### validate the value for SmsSignInState

$smssignin = Get-MgUserAuthenticationPhoneMethod -UserId $userId


    if($smssignin.SmsSignInState -eq "ready"){   
      #### Disable Sms Sign-In for the user is set to ready

      Disable-MgUserAuthenticationPhoneMethodSmsSignIn -UserId $userId -PhoneAuthenticationMethodId $phoneAuthenticationMethodId
      Write-Host "SMS sign-in disabled for the user" -ForegroundColor Green
    }
    else{
    Write-Host "SMS sign-in status not set or found for the user " -ForegroundColor Yellow
    }



##### End the script

現象 - "AzureActiveDirectoryForbidden" エラーでユーザーがプロビジョニングに失敗する

スコープ内のユーザーがプロビジョニングに失敗します。 プロビジョニング ログの詳細には、次のエラー メッセージが含まれます。

Guest invitations not allowed for your company. Contact your company administrator for more details.

原因

このエラーは、ターゲット テナントのゲスト招待設定が最も制限の厳しい設定 "管理者を含む組織内のすべてのユーザーがゲスト ユーザーを招待できない (最も制限的)" で構成されていることを示します。

解決

ターゲット テナントのゲスト招待設定を、制限の緩い設定に変更します。 詳細については、「 外部コラボレーション設定の構成」を参照してください。

現象 - UserPrincipalName が、保留中の受け入れ状態の既存の B2B ユーザーに対して更新されない

ユーザーが手動の B2B 招待を通じて初めて招待されると、招待はソース ユーザーのメール アドレスに送信されます。 その結果、ターゲット テナント内のゲスト ユーザーは、ソース メール値プロパティを使用して UserPrincipalName (UPN) プレフィックスを使用して作成されます。 環境によっては、ソース ユーザー オブジェクトのプロパティである UPN とメールの値が異なる場合があります (たとえば Mail == user.mail@domain.com と UPN == user.upn@otherdomain.com)。 この場合、ターゲット テナント内のゲスト ユーザーは、UPN を user.mail_domain.com#EXT#@contoso.onmicrosoft.com として作成されます。

この問題は、ソース オブジェクトがテナント間同期のスコープに配置され、他のプロパティ以外にも、ターゲット ゲスト ユーザーの UPN プレフィックスが ソース ユーザーの UPN と一致するように更新されることを 想定している場合に発生します (上記の例を使用すると 、user.upn_otherdomain.com#EXT#@contoso.onmicrosoft.com)。 ただし、増分同期サイクル中にはこのようなことは起こらず、変更は無視されます。

原因

この問題は、 ターゲット テナントに手動で招待された B2B ユーザーが招待を承諾または引き換えなかったため、その状態が保留中の状態である場合に発生します。 ユーザーがメールを通じて招待されると、メールから設定された一連の属性を使ってオブジェクトが作成されます。そのうちの 1 つは、ソース ユーザーのメール値を指す UPN です。 後でクロステナント同期のスコープにユーザーを追加する場合、システムは alternativeSecurityIdentifier 属性に基づいてターゲット テナント内の B2B ユーザーとソース ユーザーを結合しようとしますが、以前に作成したユーザーには、招待が引き換えられなかったため、alternativeSecurityIdentifier プロパティが設定されていません。 そのため、システムはこれを新しいユーザー オブジェクトとは見なせず、UPN 値を更新しません。 UserPrincipalName は、次のシナリオでは更新されません。

1. 手動で招待されたときのユーザーの UPN とメールが異なる。
2. ユーザーが、テナント間同期を有効にする前に招待された。
3. ユーザーが招待を受け入れなかったため、"承認待ち状態" になっている。
4. ユーザーがテナント間同期のスコープに組み込まれる。

解決

この問題を解決するには、影響を受けるユーザーに対してオンデマンド プロビジョニングを実行して UPN を更新します。 プロビジョニングを再起動して、すべての影響を受けるユーザーの UPN を更新することもできます。 これにより初期サイクルがトリガーされ、大規模なテナントでは長い時間がかかる場合があることに注意してください。 保留中の受け入れ状態の手動招待されたユーザーの一覧を取得するには、スクリプトを使用できます。次のサンプルを参照してください。

Connect-MgGraph -Scopes "User.Read.All"
$users = Get-MgUser -Filter "userType eq 'Guest' and externalUserState eq 'PendingAcceptance'" 
$users | Select-Object DisplayName, UserPrincipalName | Export-Csv "C:\Temp\GuestUsersPending.csv"

その後、 PowerShell で provisionOnDemand をユーザーごとに使用できます。 この API のレート制限は 10 秒あたり 5 要求です。 詳細については、「 オンデマンド プロビジョニングの既知の制限事項」を参照してください。

次のステップ

• チュートリアル: 自動ユーザー アカウント プロビジョニングに関するレポート
• Azure portal でのエンタープライズ アプリのユーザー アカウント プロビジョニングの管理
• Microsoft Entra ID でのシングル サインオンとは