ユーザーがベスト プラクティスに従って Azure のデプロイを最適化するための、パーソナル設定が行われた Azure のレコメンデーション エンジン。
チャブーンです。
この件ですが、「統合型の認証方法ポリシーに移行する」の意味合いですが、レガシーポリシーである
- (MFA)クラウドベースの多要素認証の追加設定-サービス設定
- (SPRR)パスワードリセット-認証方法
の2つが、既存の認証方法ポリシー(Microsoft Authenticator等)に統合されるということです。
MFA と SSPR のポリシー設定を Microsoft Entra ID の認証方法ポリシーに移行する方法
原則として「今までのポリシーで禁止しない限り」認証方法は現存されると資料にありますので、旧ポリシー→新ポリシーが「同じメソッド」であれば、影響を受けない可能性があります。新旧のマップは以下のようになっているようです。
| 多要素認証ポリシー | 認証方法ポリシー |
|---|---|
| 電話の呼び出し | 音声通話 |
| 電話の呼び出し | 音声通話 |
| 電話へのテキスト メッセージ | SMS |
| モバイル アプリでの通知 | Microsoft Authenticator |
| モバイル アプリからの確認コードまたはハードウェア トークン | サード パーティ製のソフトウェア OATH トークン ハードウェア OATH トークン Microsoft Authenticator |
とはいえ同資料内に「移行ガイドでは、テナント ポリシー設定のみを移行します。 個々のユーザー設定は移行されません。」とあるので、再設定の可能性は前提としておくべきかと思います。
ところで質問者さんは「認証強度でMFAを(条件付きアクセスで)強制している」ということですが、実態として以下の状況なのでしょうか?
- 「クラウドベースの多要素認証の追加設定」はデフォルトから一切いじっていない
- 認証方法ポリシーでMFAに関する設定は一切有効にしていない(デフォルト設定は無効)
認証強度のデザインですが、条件付きアクセスで細かく認証条件(オプション)を指定するための、突き出し的なポリシーです。認証方法ポリシーと関連はありますが、本質的には別物ポリシーとして、設定そのものには影響はありません。条件付きアクセスでは、認証強度ポリシーで合致していれば評価を行い、条件に合致していない(かみあわない場合等)、認証方法ポリシーにリダイレクして再評価、という動作ということのようなので、リダイレクト動作が発生した際に、何らかの挙動の変化があるかもしれません。ここはポリシー次第なので、実際のポリシーを見て、確認してください。