メインコンテンツにスキップ

ID 移行後に移行済みユーザーが新しいアカウントにアクセスする方法

ID 移行が完了すると、移行されたユーザーには移行先テナントにアカウントが作成されますが、パスワードは設定されていません。ShareGate では、オンボーディングの仕組みとして Microsoft Entra ID のセルフサービス パスワード リセット (SSPR) を使用します。これは、各ユーザーが新しいアカウントを受け取るための安全な手順です。

移行前に確認すること:SSPR の準備状況

Microsoft Entra ID では、SSPR は既定で有効になっていません。移行を実行する前に、移行先テナントで次の点を確認してください。

  • 移行対象のすべてのユーザーに対してSSPR が有効になっていること。これには Entra ID P1、P2、または Microsoft 365 Business Premium のライセンスが必要です。

  • 条件付きアクセス ポリシーが SSPR フローをブロックしないこと。移行されたユーザーは、まだ MFA を登録していません。条件付きアクセス ポリシーでパスワード リセットの完了に MFA を必須としている場合、ユーザーは新しいアカウントを受け取る前にロックアウトされてしまいます。

  • ユーザーが SSPR フローを実行する時点で、ソース テナントのメールボックスが引き続きアクティブであること。ユーザーが新しいアカウントを受け取る前に古いメールボックスが廃止されると、確認コードを受信できなくなります。

移行中に SSPR フローを有効にする方法

ID 移行を実行すると、ShareGate では、移行先テナントに新しく作成されたアカウントに対して、各ユーザーの古いメール アドレス(例:[email protected])を代替認証方法として設定するオプションが提供されます。このオプションを有効にしてください。これが SSPR フローを可能にする設定です。

Note: ShareGate は現在、SSPR の代替認証方法として古いメール アドレスのみをサポートしています。電話番号などその他の方法は現時点では対応していません。

Options で SSPR の設定を行う

SSPR の設定は一度行うだけで、以降のすべての移行実行に自動的に適用されます。マッピング画面で Options をクリックし、Copy behaviour タブを開きます。そこから、次の操作が行えます。

  • 既定の動作として Password reset (SSPR) をオンまたはオフにする。

  • 移行を実行するたびに確認ダイアログにトグルを表示したい場合は、Confirm before each copy を有効にする。

Confirm before each copy がオフの場合、保存された設定が自動的に適用され、確認ダイアログにトグルは表示されません。

Note: 同じ確認ダイアログには Suppress welcome emails トグルもあり、これを使用すると、移行中に新しいグループやチームに追加されたユーザーへの Microsoft からの通知を停止できます。このトグルは、少なくとも 1 つのグループが作成される場合で、かつそのオプションで Confirm before each copy が有効になっている場合にのみ表示されます。詳しくはCopy identities overviewを参照してください。

既定の設定を後で変更するには、Options > Copy behaviour に移動して設定を更新します。Confirm before each copy が有効になっている場合は、対象ユーザーを選択して移行を再実行し、確認ダイアログで直接トグルを調整することもできます。

ユーザーが新しいアカウントを受け取る方法

移行が完了したら、ShareGate が生成する移行後レポートを使用して、SSPR フローを完了する必要があるユーザーを特定します。

  1. 移行後レポートを開き、SSPR フローを完了する必要があるユーザーを特定します。

  2. 該当するユーザーに、新しいアカウントにアクセスするためにパスワードのリセットが必要であることを通知します。ユーザー自身が入力できるよう、Microsoft の SSPR URL を伝えます。通知文の安全な書き方については、以下のユーザーへの SSPR フローの伝え方を参照してください。

  3. 各ユーザーが Microsoft の SSPR ページに移動し、新しいユーザー プリンシパル名 (UPN)(例:[email protected])を入力します。

  4. Microsoft が、古いメール アドレス([email protected])に確認コードを送信します。

  5. ユーザーは、ソース テナントの資格情報を使用して古いメールボックスにログインし、コードを取得して SSPR ページに入力します。

  6. ユーザーは新しいアカウントの新しいパスワードを設定します。

  7. その後、MFA の方法を登録し、通常どおり新しいテナントで作業を開始できます。

このフローが安全である理由

SSPR フローには、組み込みの第 2 の関門があります。確認コードを取得するには、ユーザーが古い資格情報でソース テナントに認証する必要があります。つまり、攻撃者が新しいアカウントの存在や新しい UPN を知っていたとしても、古いメールボックスにアクセスできなければこのフローを完了することはできません。

ユーザーへの SSPR フローの伝え方

通知メールにはリンクを含めないようにしてください。ユーザー自身に Microsoft の SSPR ページへ移動してもらい、入力用の URL を伝えます。クリック可能なリンクは含めないでください。

「ここをクリックしてパスワードをリセットしてください」という直接的なリンクを含むメッセージは、フィッシング攻撃と形式的に同じです。特に企業環境では、セキュリティ意識の高いユーザーはまさにそのパターンを警戒するよう訓練されています。ユーザー自身が入力するプレーン テキストの URL であれば、こうした曖昧さがなくなり、メールが転送されたり傍受されたりしても、そこから実行できる操作は何もありません。

この記事は人工知能を使用して翻訳されました。疑問がある場合は、元の英語版をご確認ください。

こちらの回答で解決しましたか?