本文へ移動します / GO TO TEXT

未来に繋ぐセキュリティ情報発信

【定期便】認証方法ポリシーへの移行が自動で行えるようになったので手動の移行手順と比較してみた:Microsoft 7月公開情報

米山

こんにちは!米山です。

Microsoft Entra ID のレガシー多要素認証(以下、MFA)ポリシーとレガシーセルフサービスパスワードリセット(以下、SSPR)ポリシーが2025年9月30日に廃止予定となっており、認証方法ポリシーという新しいポリシーに移行する必要があります。

移行期限が迫っているため、認証方法ポリシーへの移行手順について自動で行う方法と手動で行う方法の2通りご紹介します。
現在レガシーポリシーをご利用中の方でまだ認証方法ポリシーへの移行ができていない方、または移行手順が分からない方は、ぜひご覧ください。

また、2025年7月の Microsoft 公開情報からセキュリティ関連の情報もピックアップしましたので、併せてご紹介します。

  • 当ブログにて記載しております Microsoft 社の Web サイトの URL については、Microsoft 社側のリダイレクトの仕組みにより、お客様の閲覧環境に沿ったページに自動的にリダイレクトされることがございます。
    原文を参照される場合は、リダイレクトされた URL の ja-jp などの文字列を en-us に変更することで閲覧いただけます。

レガシー MFA/SSPR ポリシーと認証方法ポリシーについて

Microsoft Entra ID のレガシー MFA/SSPR ポリシーは、従来の認証管理方式のことであり、これらは現在別々の画面で設定・管理されています。

従来のレガシー MFA ポリシー 設定画面
従来のレガシー SSPR ポリシー 設定画面

認証方法ポリシーは、Microsoft 社が新たに提供を始めた認証管理方式のことであり、現在別々の画面で管理されている MFA と SSPR の認証方法の一元管理が可能で、ユーザーやグループごとに柔軟なポリシー設定が可能です。

レガシー MFA/SSPR ポリシーが廃止予定である2025年9月30日までに認証方法ポリシーに移行しない場合、Microsoft Authenticator や SMS などの従来の認証方法が無効になる、サインインやパスワードリセットが使用できなくなるなどの影響が発生する可能性があります。そのためまだ認証方法ポリシーへの移行ができていない方は移行することをおすすめします。

移行に関する注意事項

はじめに、移行に関する注意事項をご紹介します。
以下の5点があげられます。

①一度認証方法ポリシーへ移行してしまうと設定は元に戻せず、移行前の状態に戻すには手動で再設定する必要があるため、事前に設定内容をキャプチャなどで保存しておくことを推奨します。

例:レガシー MFA ポリシー
例:レガシー SSPR ポリシー

②レガシー SSPR ポリシーの [秘密の質問] は認証方法ポリシーへ移行可能になると Microsoft 社から発表されていますが、現在は認証方法ポリシーで管理ができないためご注意ください。(2025年7月現在)

※参考:Microsoft 社:MFA と SSPR のポリシー設定を Microsoft Entra ID の認証方法ポリシーに移行する方法 - セキュリティの質問

③認証方法ポリシーの [証明書ベースの認証] [QR コード (プレビュー)] はレガシーポリシーに存在せず、自動/手動移行の対象とはならないためご注意ください。

④認証方法ポリシーへ移行することによるユーザー影響は基本的にないですが、認証方法の設定ミスによる認証方法の変化やサインインがブロックされるなどのユーザー影響が発生する恐れがあるためご注意ください。

⑤本手順はあくまでサンプル手順となっており使用されているテナントごとに対応が異なります。そのため手順を実施しても上手くいかない場合は Microsoft 社に問い合わせていただくようお願いいたします。

認証方法ポリシーへの移行手順

次に認証方法ポリシーへの移行手順について、自動と手動の2通りご紹介します。

それぞれの移行手順の流れは以下の通りです。

自動での移行手順(すべてのポリシー移行にかかる時間:約8分)
  1. 認証方法移行ウィザードの起動
  2. 認証方法移行ウィザードを使用した認証方法の移行
  3. 認証方法の移行が完了したことを確認

※ 自動での移行はポリシーを1つの画面からまとめて確認できるため、手動移行よりもポリシーの確認時間が短くなります。

手動での移行手順(すべてのポリシー移行にかかる時間:約20分)
  1. レガシー MFA ポリシーの確認
  2. レガシー SSPR ポリシーの確認
  3. 認証方法ポリシーの確認
  4. 認証方法移行の開始
  5. レガシー ポリシーの削除

自動での移行手順

1. 認証方法移行ウィザードの起動

① 認証ポリシー管理者以上のロールが付与されたアカウントで Microsoft Entra 管理センター(https://entra.microsoft.com)にアクセスします。

② [ID] - [保護] - [認証方法] をクリックします。

③ [移行の管理] の [移行の状態] が [処理中] であることを確認します。
※ [処理中] ではなく [移行前] と表示されている場合は、[変更] をクリックし、[移行が進行中:] を選択し [保存] をクリックします。

2. 認証方法移行ウィザードを使用した認証方法の移行

① [ID] - [保護] - [認証方法] - [ポリシー] をクリックし、[自動ガイドの開始] をクリックします。

② [認証方法設定の移行] 画面に移り、現在のレガシーポリシーの設定を確認する場合は、[従来の MFA 方式の設定] [従来の SSPR 方式の設定] をクリックし、設定内容を確認します。現在の設定内容を確認できたら、[次へ] をクリックします。

③ 各認証方法を確認し、編集したい認証方法は鉛筆マークをクリックします。
※ 本手順では Microsoft Authenticator を確認する手順を追記します。
※ [状態] 列の値は既定で [オン] になります。
※ 認証方法ポリシーに事前に設定した内容はそのままこの画面に表示されます。

④ [状態] と [ターゲット] を確認し、問題なければ [保存] をクリックします。

⑤ 各認証方法に問題がなければ、[移行] をクリックします。
※ 「注意事項①」にも記載したように、一度認証方法ポリシーへ移行してしまうと設定は元に戻せません。移行前の状態に戻すには手動で再設定する必要があるため、事前に設定内容をキャプチャなどで保存しておくことを推奨します。

⑥ 移行を続行する場合は [続行] をクリックします。

⑦ 移行完了の通知を確認します。

以上で Microsoft Authenticator の移行が完了しました。
認証方法ポリシーへ移行後、サインイン画面で Microsoft Authenticator が有効化されていることを確認できました。

3. 認証方法の移行が完了したことを確認

① [ID] - [保護] - [認証方法] - [ポリシー] をクリックし、[移行の状態] が [完了] に更新されたことを確認します。

※ [変更] をクリックし、[移行が進行中] を選択し [保存] を行うことで [移行の状態] を [処理中] に戻すことが可能です。ただし認証方法の設定はそのままです。
※ [処理中] に戻すと、本手順②③で設定が行えなくなった箇所で再度レガシーポリシーの設定が行えるようになりますが、レガシーポリシーと認証方法ポリシーが両方有効な状態のため、認証方法の構成が一致していない場合、意図していない認証方法が使用できてしまう可能性があるためご注意ください。

※ 上記で [移行] をクリックし以下のような通知が表示されますと [処理中] に変更完了です。

② [ID] - [ユーザー] - [すべてのユーザー] - […] - [ユーザーごとの MFA] - [サービス] をクリックしレガシー MFA ポリシーを確認すると、この画面からは認証方法の設定は行えないことが確認できます。

③ [ID] - [ユーザー] - [すべてのユーザー] - [パスワード リセット] - [認証方法] をクリックしレガシー SSPR ポリシーを確認すると、この画面からは認証方法の設定は行えないことを確認できます。
※ 「注意事項②」にも記載したように、2025年7月現在では [秘密の質問] のみは認証方法ポリシーで対応できていないため、引き続きこの画面から設定を行うことができます。しかし、将来的に[秘密の質問] は認証方法ポリシーへ移行可能になると Microsoft 社から発表されているため、移行可能後は [秘密の質問] も認証方法ポリシーで管理を行うことを推奨します。

自動での移行手順は以上となります。

手動での移行手順

1. レガシー MFA ポリシーの確認

① 認証ポリシー管理者以上のロールが付与されたアカウントで Microsoft Entra 管理センター(https://entra.microsoft.com)にアクセスします。

② サインインしましたら、[ID] - [ユーザー] - [すべてのユーザー] - […] - [ユーザーごとのMFA] - [サービス] をクリックします。

③ [検証オプション] でユーザーが利用可能な認証方法を確認します。

※ 以下の表は、レガシー MFA ポリシーで使用できる認証方法と、それに対応する認証方法ポリシーとなりますのでご参考にしてください。

左右にスクロールしてご覧ください。

多要素認証ポリシー 認証方法ポリシー
電話への呼び出し 音声通話
電話へのテキスト メッセージ sms
モバイル アプリでの通知 Microsoft Authenticator
モバイル アプリからの確認コードまたはハードウェアトークン サード パーティ製のソフトウェア
OATH トークン
ハードウェア OATH トークン
Microsoft Authenticator

※参考:Microsoft 社:MFA と SSPR のポリシー設定を Microsoft Entra ID の認証方法ポリシーに移行する方法

2. レガシー SSPR ポリシーの確認

① [ID] - [ユーザー] - [すべてのユーザー] - [パスワード リセット] - [認証方法] をクリックします。

② ユーザーがパスワードリセットの際に使用できる方法を確認します。

※ 以下の表は、レガシー SSPR ポリシーで使用できる認証方法と、それに対応する認証方法ポリシーとなりますのでご参考にしてください。

左右にスクロールしてご覧ください。

SSPR 認証方法 認証方法ポリシー
モバイル アプリへの通知 Microsoft Authenticator
モバイル アプリ コード Microsoft Authenticator
ソフトウェア OATH トークン
電子メール 電子メールの OTP
携帯電話 音声通話
sms
会社電話 音声通話
セキュリティの質問 (現時点では未対応)

※参考:Microsoft 社:MFA と SSPR のポリシー設定を Microsoft Entra ID の認証方法ポリシーに移行する方法

3. 認証方法ポリシーの確認

① [ID] - [保護] - [認証方法] をクリックします。

② [ポリシー] をクリックし、認証方法ポリシーの構成を確認します。

4. 認証方法移行の開始

① [ID] - [保護] - [認証方法] をクリックします。

② [ポリシー] をクリックし、前述手順1、2の表を参考にそれぞれのレガシーポリシーの認証方法を、対応する認証方法ポリシーに設定を移行します。
※ 本手順では例として、[Microsoft Authenticator] の移行手順を記載します。

③ Microsoft Authenticator の[有効にする] のトグルを有効(青色)にし、[含める] タブの[ターゲット] で [すべてのユーザー] を選択します。

④ 変更完了しましたら、[保存] をクリックします。
※ [構成] をクリックすると詳細な設定が行えますが、本手順では変更箇所がないため手順はスキップします。

⑤ ポリシーの保存が完了したことを確認します。

こちらで Microsoft Authenticator の移行が完了しました。
認証方法ポリシーへ移行後、サインイン画面で Microsoft Authenticator が有効化されていることを確認できました。

5. レガシーポリシーの削除

① 認証ポリシー管理者以上のロールが付与されたアカウントで Microsoft Entra 管理センター(https://entra.microsoft.com)にアクセスします。

② [ID] - [ユーザー] - [すべてのユーザー] - […] - [ユーザーごとの MFA] - [サービス] をクリックします。

③ 認証方法ポリシーの [Microsoft Authenticator] と紐づいている [モバイルアプリによる通知] [モバイル アプリまたはハードウェアトークンからの確認コード] のチェックを外して、[保存] をクリックします。

④ [ID] - [ユーザー] - [すべてのユーザー] - [パスワード リセット] - [認証方法] をクリックします。

⑤ 認証方法ポリシーの [Microsoft Authenticator] と紐づいている [モバイルアプリの通知] [モバイルアプリ コード] のチェックを外して、[保存] をクリックします。

手動での移行手順は以上となります。

まとめ

自動での移行は簡単で早く利便性が高いと思った一方、移行前の設定には戻せない、ポリシーごとの細かい制御が行えないなどのデメリットもあるため注意が必要です。
手動での移行は自動移行よりも細かく設定した状態で移行が可能であり、ユーザー影響を最小限に抑えながら移行ができる一方、移行作業に時間がかかり認証方法の設定ミスなどが発生する可能性があるため注意が必要です。

どちらもメリット・デメリットがありますが、段階的な移行が必要などの事情がない場合は、移行作業が容易で時間がかからない自動での移行方法を推奨します。

引き続き、7月度の Microsoft 公開情報をご確認ください。

Microsoft 公開情報

Microsoft Blog の更新からセキュリティに関する気になる項目をピックアップしてご紹介します。

Microsoft 365 Copilot Notebooks を OneNote に統合することで作業が効率化

Introducing Copilot Notebooks: A whole new way to work with AI in OneNote

  • Microsoft 365 Copilot Notebooks を OneNote に統合することで関連するファイルやリンク、ノートを集約しプロジェクトの情報を一元管理できます。
    Notebook に集めた情報をもとに、Copilot に質問すると、文脈に沿った回答や要約、洞察を得られます。音声要約機能もあり、Notebook の内容を音声で要約し、移動中などに聞いて内容を把握できます。

ソフトウェアのリグレッションの検知と自動的なロールバック

Graph-Based AI System for Real-Time Detection and Rollback of Performance Regressions in Software

  • アプリケーションを複数の小さな独立したサービスに分割して構築する設計スタイル(マイクロサービスアーキテクチャ)は柔軟性が高い一方で、更新時にパフォーマンス劣化が起こりやすく、従来の静的な監視では検出が遅れます。特に、サービス間の複雑な依存関係があると、問題の根本原因の特定が困難です。
    GNN(Graph Neural Network)を活用することで、AI がサービス間の関係をグラフ構造として捉え、時間的変化も含めて学習を行います。AI が構造的・時間的な依存関係を理解することで、従来の手法では見逃されがちな異常が検出可能となります。

Microsoft 365 Copilot と Clipchamp を活用した AI による業務改善

Unlocking the Power of AI: Transforming Business with Microsoft 365 Copilot and Clipchamp

  • Microsoft は、AI の力を活用してコンテンツ制作や業務効率化を支援する新機能を Microsoft 365 に統合しました。
    特に注目されているのは「Copilot の Create モジュール」と「Clipchamp の動画編集機能」の機能となります。
    このアップデートにより、AI を活用したクリエイティブ・業務支援プラットフォームへとアップグレードしました。
    中小企業やリソースの限られたチームにとって、時間・コスト・スキルの壁を乗り越えて、質の高い成果物を生み出す手段となります。

さいごに

以上です。
最後までお読みいただきありがとうございました!

お問い合わせ

製品・サービスに関するお問い合わせはお気軽にご相談ください。

セキュリティソリューションに関する資料請求・お問い合わせ

開催中のセミナー

最新トレンドや業務に役立つ知識が得られる SBテクノロジーのセミナー 参加無料 オンデマンド配信あり

ピックアップ

セミナー情報
クラウドエンジニアブログ
NOZ
メールマガジン登録