ID 移行が完了すると、移行されたユーザーには移行先テナントにアカウントが作成されますが、パスワードは設定されていません。ShareGate は、オンボーディングの仕組みとして Microsoft Entra ID のセルフサービス パスワード リセット(SSPR)を使用します。これは、各ユーザーが自分の新しいアカウントを受け取るための安全な手順です。
移行前に: SSPR の準備ができていることを確認する
SSPR は、Microsoft Entra ID でデフォルトでは有効になっていません。移行を実行する前に、移行先テナントで以下を確認してください。
SSPR が有効になっていること。移行対象のすべてのユーザーに対して有効である必要があります。これには Entra ID P1、P2、または Microsoft 365 Business Premium のライセンスが必要です。
Conditional Access ポリシーが SSPR フローをブロックしないこと。移行されたユーザーはまだ MFA を登録していません。Conditional Access ポリシーでパスワードリセットの完了に MFA を必須としている場合、これらのユーザーは新しいアカウントを受け取る前にロックアウトされてしまいます。
移行元テナントのメールボックスが引き続きアクティブであること。ユーザーが SSPR フローを実行する時点で必要です。ユーザーが新しいアカウントを受け取る前に旧メールボックスが廃止されると、確認コードを受信できなくなります。
移行中に SSPR フローを有効にする方法
ID 移行を実行する際、ShareGate では、各ユーザーの旧メールアドレス(例: [email protected])を、移行先テナントで新しく作成されたアカウントの代替認証方法として設定するオプションが用意されています。このオプションを有効にしてください。これにより、SSPR フローが可能になります。
注: ShareGate は現在、SSPR の代替認証方法として旧メールアドレスのみをサポートしています。電話番号などの他の方法は、現時点ではサポートされていません。
注: 同じ確認ダイアログには、Suppress welcome emailsというトグルもあります。これを有効にすると、移行中に新しいグループやチームに追加されたユーザーへの Microsoft からの通知が停止されます。このトグルは、少なくとも 1 つのグループが作成される場合にのみ表示されます。詳細については、Copy identities の概要をご覧ください。
このオプションをオフにしていて後から有効にしたい場合は、該当するユーザーを選択して移行を再実行し、トグルをオンにしてください。
ユーザーが新しいアカウントを受け取る方法
移行が完了したら、ShareGate が生成する移行後レポートを使用して、SSPR フローを完了する必要があるユーザーを特定します。
移行後レポートを開き、SSPR フローを完了する必要があるユーザーを特定します。
該当するユーザーに、新しいアカウントにアクセスするためにパスワードをリセットする必要があることを通知します。Microsoft SSPR の URL を伝え、ユーザー自身に入力してもらいます。通知文言を安全に作成する方法については、以下のユーザーへの SSPR フローの伝え方を参照してください。
各ユーザーは Microsoft SSPR ページにアクセスし、新しいユーザープリンシパル名(UPN)(例: [email protected])を入力します。
Microsoft は、確認コードを旧メールアドレス([email protected])宛てに送信します。
ユーザーは移行元テナントの認証情報を使用して旧メールボックスにログインし、コードを取得して SSPR ページに入力します。
ユーザーは新しいアカウントの新しいパスワードを設定します。
その後、MFA 方法を登録し、通常どおり新しいテナントでの作業を開始できます。
このフローが安全である理由
SSPR フローには、第 2 のゲートが組み込まれています。確認コードを取得するには、ユーザーが旧の認証情報で移行元テナントに認証する必要があります。つまり、攻撃者が新しいアカウントの存在や新しい UPN を知っていたとしても、旧メールボックスにアクセスできない限り、このフローを完了することはできません。
ユーザーへの SSPR フローの伝え方
通知メールにはリンクを含めないようにしてください。ユーザー自身に Microsoft SSPR ページにアクセスしてもらうよう伝え、入力用の URL を提供します。クリック可能なリンクは含めないでください。
「ここをクリックしてパスワードをリセットしてください」という直接的なリンクを含むメッセージは、フィッシング攻撃と同じ形式です。特にエンタープライズ環境では、セキュリティ意識の高いユーザーはまさにこのパターンを疑うよう教育されています。ユーザー自身が入力するプレーンテキストの URL であれば、あいまいさがなくなり、メールが転送されたり傍受されたりした場合でも、悪用できる要素が含まれません。
この記事はAIによって翻訳されています。ご不明な点がある場合は、英語の原文をご確認ください。