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

[アーティクル]
10/09/2024

この記事では、Microsoft Entra 管理センターを利用してテナント間同期を構成する手順について説明します。構成すると、Microsoft Entra ID では、ターゲットテナント内の B2B ユーザーが自動的にプロビジョニングおよびプロビジョニング解除されます。このサービスが実行する内容、しくみ、よく寄せられる質問の重要な詳細については、「Microsoft Entra ID による SaaS アプリへのユーザープロビジョニングとプロビジョニング解除の自動化」を参照してください。

学習の目的

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

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

前提条件

ソーステナントのアイコン。
ソーステナント

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

ターゲットテナントのアイコン。
ターゲットテナント

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

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

組織内のテナントを構成する方法を定義します。
プロビジョニングサービスのしくみを確認します。
誰がプロビジョニングの対象となるかを決定します。
テナント間でマップするデータを決定します。

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

ヒント

この記事の手順は、開始するポータルに応じて若干異なる場合があります。

ターゲットテナントのアイコン。
ターゲットテナント

ターゲットテナントの Microsoft Entra 管理センターにサインインします。
[ID]、[External Identities]、[テナント間アクセス設定] の順に移動します。
[組織の設定] タブで、[組織の追加] を選びます。
テナント ID またはドメイン名を入力して [追加] を選び、ソーステナントを追加します。
追加された組織の [Inbound access] (インバウンドアクセス) で、[既定値から継承] を選びます。
[テナント間同期] タブを選びます。
[ユーザーがこのテナントに同期することを許可する] チェックボックスを選択します。
[保存] を選択します。
[テナント間同期と自動引き換えを有効にする] ダイアログボックスで自動引き換えを有効にするか問われた場合、[はい] を選択します。

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

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

ターゲットテナントのアイコン。
ターゲットテナント

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

ターゲットテナントの同じ [受信アクセスの設定] ページで、[信頼の設定] タブを選択します。
[テナントで招待を自動的に引き換える]<テナント> チェックボックスにチェックを入れます。

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

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

ソーステナントのアイコン。
ソーステナント

このステップでは、ソーステナントで招待を自動的に引き換えます。

ソーステナントの Microsoft Entra 管理センターにサインインします。
[ID]、[External Identities]、[テナント間アクセス設定] の順に移動します。
[組織の設定] タブで、[組織の追加] を選びます。
テナント ID またはドメイン名を入力して [追加] を選び、ターゲットテナントを追加します。
ターゲット組織の [Outbound access] (アウトバウンドアクセス) で、[既定値から継承] を選びます。
[信頼の設定] タブを選択します。
[テナントで招待を自動的に引き換える]<テナント> チェックボックスにチェックを入れます。
[保存] を選択します。

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

ソーステナントのアイコン。
ソーステナント

ソーステナントで、[ID]、[External Identities]、[テナント間同期] の順に参照します。

Azure portal を使用している場合は、[Microsoft Entra ID]>[管理]>[テナント間同期] に移動します。
[構成] を選択します。
ページの先頭にある [新しい構成] を選びます。
構成の名前を指定して、[作成] を選びます。

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

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

ソーステナントのアイコン。
ソーステナント

ソーステナントに新しい構成が表示されるはずです。表示されない場合、構成リストで構成を選択します。
[Get started](作業を開始する) を選択します。
[プロビジョニングモード] を [自動] に設定します。
[管理者資格情報] セクションで、[認証方法] を [Cross Tenant Synchronization Policy] (テナント間同期ポリシー) に変更します。
[テナント ID] ボックスに、ターゲットテナントのテナント ID を入力します。
[テスト接続] を選んで接続をテストします。

指定した資格情報でプロビジョニングを有効にすることが承認されたことを示すメッセージが表示されます。テスト接続が失敗した場合は、この記事で後述する「トラブルシューティングのヒント」をご覧ください。
[保存] を選択します。

[マッピング] と [設定] セクションが表示されます。
[プロビジョニング] ページを閉じます。

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

ソーステナントのアイコン。
ソーステナント

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

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

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

ソーステナントで、[プロビジョニング] を選択し、[設定] セクションを展開します。
[スコープ] の一覧で、ソーステナントのすべてのユーザーを同期するか、構成に割り当てられているユーザーのみを同期するかを選びます。

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

テナント間同期が機能するには、少なくとも 1 人の内部ユーザーを構成に割り当てる必要があります。
[Add user/group](ユーザーまたはグループの追加) を選択します。
[割り当ての追加] ページで、[ユーザーとグループ] の下にある [選択されていません] を選びます。
[ユーザーとグループ] ペインで、構成に割り当てる内部ユーザーまたはグループを 1 つ以上検索して選びます。

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

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

手順 8: (省略可能) スコープフィルターを使用してプロビジョニングのスコープ内のユーザーを定義する

ソーステナントのアイコン。
ソーステナント

前のステップで [スコープ] に選んだ値に関係なく、属性ベースのスコープフィルターを作ることで、同期されるユーザーをさらに制限できます。

ソーステナントで、[プロビジョニング] を選択し、[マッピング] セクションを展開します。
[Microsoft Entra ID ユーザーのプロビジョニング] を選択し、属性マッピング ページを開きます。
[ソースオブジェクトスコープ] で、[ すべてのレコード] を選びます。
[ソースオブジェクトスコープ] ページで、[スコープフィルターの追加] を選びます。
プロビジョニングのスコープ内のユーザーを定義するスコープフィルターを追加します。

スコープフィルターの構成については、「スコープフィルターを使用した属性ベースのアプリケーションプロビジョニング」の手順をご覧ください。
[OK] と [保存] を選んですべての変更を保存します。

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

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

ソーステナントのアイコン。
ソーステナント

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

ソーステナントで、[プロビジョニング] を選択し、[マッピング] セクションを展開します。
[Microsoft Entra ID ユーザーのプロビジョニング] を選択します。
[属性マッピング] ページを下にスクロールし、テナント間で同期されるユーザー属性を [属性マッピング] セクションで確認します。

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

userType 属性の [定数値] の設定を確認します。

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

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

Note

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

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

アプリまたはサービス	制限事項
Power BI	- Power BI での UserType Member のサポートは現在プレビュー段階です。詳細については、「Microsoft Entra B2B で外部ゲストユーザーに Power BI コンテンツを配布する」を参照してください。
Azure Virtual Desktop	- 外部メンバーと外部ゲストは、Azure Virtual Desktop ではサポートされていません。

変換を定義する場合は、[属性マッピング] ページで、変換する属性 (displayName など) を選びます。
[マッピングの種類] を [式] に設定します。
[式] ボックスに、変換式を入力します。たとえば、表示名の場合は、次のようにできます。
- 名と姓を入れ替えて、その間にコンマを追加します。
- 表示名の最後に、かっこで囲んだドメイン名を追加します。
例については、「Microsoft Entra ID で属性マッピングの式を記述するためのリファレンス」を参照してください。

ヒント

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

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

ソーステナントのアイコン。
ソーステナント

ソーステナントで、[プロビジョニング] を選択し、[設定] セクションを展開します。
[エラー発生時にメール通知を送信する] チェックボックスを選択します。
プロビジョニングエラー通知を受け取る必要があるユーザーまたはグループのメールアドレスを、[通知用メール] フィールドに入力します。

ジョブが検疫状態になってから 24 時間以内に、メール通知が送信されます。カスタムアラートについては、「プロビジョニングを Azure Monitor ログと統合する方法の概要」をご覧ください。
誤って削除されないようにするには、[誤削除を防止する] を選んで、しきい値を指定します。既定では、しきい値は 500 に設定されます。

詳細については、「Microsoft Entra プロビジョニングサービスで誤った削除の防止機能を有効にする」を参照してください。
[保存] を選択してすべての変更を保存します。

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

ソーステナントのアイコン。
ソーステナント

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

ソーステナントで、[ID]、[External Identities]、[テナント間同期] の順に参照します。
[構成] を選んでから、構成を選びます。
[Provision on demand] (オンデマンドでプロビジョニングする) を選択します。
[ユーザーまたはグループを選択します] ボックスで、テストユーザーの 1 人を検索して選びます。
[プロビジョニング] を選びます。

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

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

[オンデマンドでプロビジョニング] ページでは、プロビジョニングに関する詳細を表示し、再試行するオプションを選択できます。
ターゲットテナントで、テストユーザーがプロビジョニングされたことを確認します。
すべてが期待どおりに動作している場合は、構成に追加のユーザーを割り当てます。

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

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

ソーステナントのアイコン。
ソーステナント

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

ソーステナントで、[ID]、[External Identities]、[テナント間同期] の順に参照します。
[構成] を選んでから、構成を選びます。
[概要] ページで、プロビジョニングの詳細を確認します。
[プロビジョニングの開始] を選んで、プロビジョニングジョブを始めます。

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

ソーステナントのアイコン。ターゲットテナントのアイコン。
ソースとターゲットテナント

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

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

プロビジョニングが異常な状態になったように見える場合、構成は検疫されます。詳細については、「検疫状態のアプリケーションのプロビジョニング」を参照してください。
プロビジョニングが成功したユーザーと失敗したユーザーを確認するには、[プロビジョニングログ] を選びます。既定では、ログは構成のサービスプリンシパル ID でフィルター処理されます。詳細については、「Microsoft Entra ID のプロビジョニングログ」を参照してください。
Microsoft Entra ID でログに記録されたすべてのイベントを表示するには、[監査ログ] を選びます。詳細については、Microsoft Entra ID の監査ログに関する記事を参照してください。

ターゲットテナントでの監査ログを見ることもできます。
ターゲットテナントで、[ユーザー]>[監査ログ] を選んで、ユーザー管理に関するログされたイベントを表示します。

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

ターゲットテナントのアイコン。
ターゲットテナント

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

ターゲットテナントで、[ID]、[External Identities]、[外部コラボレーション設定] の順に選択します。
[外部ユーザーの脱退設定] で、外部ユーザーが組織を脱退することを許可するかどうかを選びます。

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

トラブルシューティングのヒント

構成を削除する

[構成] ページで構成を削除するには、こちらの手順に従います。

ソーステナントで、[ID]、[External Identities]、[テナント間同期] の順に参照します。
[構成] ページで、削除する構成の横にチェックマークを付けます。
[削除]、[OK] の順に選択して、構成を削除します。

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

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

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

You appear to have entered invalid credentials. Please confirm you are using the correct information for an administrative account.
Error code: AzureDirectoryB2BManagementPolicyCheckFailure
Details: Policy permitting auto-redemption of invitations not configured.

原因

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

ソリューション

「手順 3: ターゲットテナントで招待を自動的に引き換える」と「手順 4: ソーステナントで招待を自動的に引き換える」で示されている手順のようにします。

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

テナント間同期の構成時に、[自動引き換え] チェックボックスが無効になっています。

原因

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

解決方法

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

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

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

原因

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

ソリューション

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

ユーザーは同期からスキップされます。スコープステップには、状態が 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.

原因

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

解決方法

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

現象 - 承認待ち状態の既存の B2B ユーザーのユーザープリンシパル名が更新されない

ユーザーが手動の B2B 招待を通じて初めて招待されると、招待はソースユーザーのメールアドレスに送信されます。その結果、ターゲットテナント内のゲストユーザーは、ソースメール値プロパティを使用するユーザープリンシパル名 (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 値を更新しません。次のシナリオでは、ユーザープリンシパル名は更新されません。

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

ソリューション

この問題を解決するには、影響を受けるユーザーに対してオンデマンドプロビジョニングを実行して 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 要求です。詳細については、「オンデマンドプロビジョニングの既知の制限事項」を参照してください。

次の方法で共有

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

学習の目的

前提条件

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

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

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

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

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

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

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

手順 8: (省略可能) スコープフィルターを使用してプロビジョニングのスコープ内のユーザーを定義する

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

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

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

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

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

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

トラブルシューティングのヒント

構成を削除する

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

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

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

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

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

現象 - 承認待ち状態の既存の B2B ユーザーのユーザープリンシパル名が更新されない

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

学習の目的

前提条件

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

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

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

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

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

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

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

手順 8: (省略可能) スコープ フィルターを使用してプロビジョニングのスコープ内のユーザーを定義する

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

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

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

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

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

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

トラブルシューティングのヒント

構成を削除する

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

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

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

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

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

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

現象 - 承認待ち状態の既存の B2B ユーザーのユーザー プリンシパル名が更新されない

次のステップ

フィードバック

その他のリソース

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

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

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

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

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

手順 8: (省略可能) スコープフィルターを使用してプロビジョニングのスコープ内のユーザーを定義する

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

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

現象 - 承認待ち状態の既存の B2B ユーザーのユーザープリンシパル名が更新されない