Microsoft Entra ID（旧Azure AD）を導入している場合、Microsoft AuthenticatorアプリやSMSなどを使用した多要素認証（以下、MFA）やユーザー自身でパスワードリセットを行えるようにするセルフサービスパスワードリセット（以下、SSPR）を設定して利用されている方は多いのではないでしょうか。
これまでのMFAおよびSSPR設定はレガシーポリシーと呼ばれており、現時点において2024年9月30日に廃止されることがMicrosoftより発表されております。
レガシーポリシーの移行先として認証方法ポリシーと呼ばれる新しい機能が既に正式リリースされております。そこで今回は認証方法ポリシーについて仕様を確認し、いくつかの認証メソッドを実際に有効化して動作確認を実施していきたいと思います。
認証方法ポリシーとは
認証方法ポリシーとは、ユーザーのMFAとパスワードリセット時の本人確認の両シナリオで使用する認証方法を管理するための機能になります。従来のレガシーポリシーでは、それぞれのシナリオ別で認証方法を管理する必要がありましたが、一元的に管理することが可能になっています。
また、特定のグループを指定して局所的に有効にしたり、パスワードレス認証の様な最新の方法もサポートしております。
認証方法ポリシーは様々な認証メソッドに対応しており、それぞれ個別で有効にすることが可能です。2023年7月時点においてサポートしている認証メソッドは以下の通りです。
- FIDO2 セキュリティキー（※ユーザー認証のみ使用可能）
- Microsoft Authenticator
- SMS
- 一時アクセスパス
- サードパーティ製のソフトウェア OAUTH トークン
- 音声通話
- メール OTP
- 証明書ベースの認証
SSPR設定で指定できる「秘密の質問」は現時点で使用することができませんが、Microsoft ドキュメントには近日公開予定となっておりました。
冒頭にも記載した通り、レガシーポリシーが廃止される前に認証方法ポリシーへ移行を行う必要があります。認証方法ポリシーには、利用者への影響を少なくして段階的に移行を実施していくための「移行の管理」と呼ばれる機能が用意されております。「移行の管理」を使用することで、レガシーポリシーと認証方法ポリシーの並行利用期間を設けながら時間をかけて移行できるようになっています。移行の手順については、以下のMicrosoft ドキュメントに詳しく書かれていますのでそちらをご参照ください。
MFA と SSPR のポリシー設定を Azure AD の認証方法ポリシーに移行する方法
認証方法ポリシーの有効化
本投稿では「Microsoft Authenticator」「SMS」「証明書ベースの認証」の3メソッドについて有効化を行い、動作確認を実施していきます。
「移行の管理」の設定
認証方法ポリシーを設定していくにあたり、まずは移行の管理の設定変更を実施します。
パラメータは、「移行前（デフォルト値）」「移行が進行中」「移行が完了済み」の3つがあり、それぞれの挙動は以下画像の通り設定画面に記載されています。
私の環境ではSSPRを有効にしていますので、「移行が進行中」に変更してMFAおよびSSPRの両シナリオで認証方法ポリシーを使用できるように設定しました。
「Microsoft Authenticator」の設定
Microsoft Authenticatorの設定を実施します。
まずは、有効化およびターゲットのタブについてです。今回は4つのグループに対して有効化を実施しました。認証モードは、「すべて」「パスワードレス」「プッシュ」から選択します。「すべて」および「パスワードレス」を選択した場合は、パスワードの入力が不要になりMicrosoft Authenticatorアプリのみで認証することが可能になります。「プッシュ」を選択した場合は、パスワード＋アプリへのプッシュ通知にて認証を行います。
続いて構成のタブについてです。今回は、「OTP（確認コード）の使用を許可する」を「はい」に、「アプリ通知の際にアプリケーション名を表示する」「アプリ通知の際に地理的な場所を表示する」を「有効」に変更しました。コンパニオンアプリケーション（現時点ではAndroidやiOSのOutlookモバイルアプリのみ対象）でのMicrosoft Authenticatorは利用想定がないためMicrosoft マネージドのままとしました。
「SMS」の設定
SMSの設定を実施します。
SMSは、有効化およびターゲットのタブのみになります。今回は3つのグループに対して有効化を実施しました。「サインインに使用」にチェックを入れた場合は、パスワードの入力が不要になりSMSのみで認証することが可能になります。SMSはセキュリティレベルが高くないので、すべてのグループに対して「サインインに使用」はチェックなしで設定しました。
「証明書ベースの認証」の設定
証明書ベースの認証の設定を実施します。
まず、前提事項として以下を満たしておく必要があります。
- 少なくとも 1 つの証明機関 (CA) と任意の中間 CA がMicrosoft Entra ID（Azure AD）に登録されている
- インターネットに接続する URL から参照できる証明書失効リスト (CRL) が登録されている
今回はIaaS環境へ構築したAD CSサーバを使用して証明機関を用意しました。（AD CSサーバの構築手順については、今回の趣旨から外れるため割愛させて頂きます。証明書ベースの認証はそれだけで記事が書けるぐらいボリューム満点なので、別途記事にできたらと思います。）
ということで、証明書ベースの認証を有効化する前に発行したCA証明書およびCRLをアップロードします。合わせて、動作確認で使用するPCに対してクライアント証明書をインストールしておきます。
前提条件の準備が整いましたので、証明書ベースの認証を有効化していきます。まずは、有効化およびターゲットのタブについてです。今回は1つのグループに対して有効化を実施しました。
続いて構成のタブについてです。今回は保護レベルを「多要素認証」としました。そして、証明書フィールドのPrincipalNameとRFC822Nameは、ユーザー属性に「userPrincipalName」を指定しました。
認証方法ポリシーの動作確認
証明書ポリシーの有効化が完了しましたので、ユーザー認証の動作確認を実施していきたいと思います。今回は、条件付きアクセスにて全てのアプリに対して「多要素認証を要求する」ポリシーを設定しております。なお、SMSについてはレガシーポリシーの際と挙動は変わらないため、今回はMicrosoft Authenticatorと証明書ベースの認証について取り上げます。
Microsoft Authenticatorによる認証
Microsoft Authenticatorを有効にしたグループに所属するユーザーにてOfficeホーム画面にアクセスを行いました。Microsoft Authenticatorアプリの画面は以下の様になり、アクセス先のアプリやアクセス元の場所が表示されることを確認できました。「こちらに番号を入力してください」の入力欄にはPC画面上に表示される2桁の番号を入力します。番号が一致していれば、認証要求が承認される動作になります。
証明書ベースによる認証
次に証明書ベースの認証を有効にしたグループに所属するユーザーにてOfficeホーム画面にアクセスを行いました。
まず、ユーザーパスワードを入力する画面にてパスワードは入力せずに「証明書またはスマートカードを使用する」をクリックします。
事前にPCへインストールしたクライアント証明書を選択する画面が表示されます（2回目以降は表示されません）ので「OK」をクリックします。
Officeホーム画面が表示しました。パスワードを入力せず、証明書のみで認証できることを確認できました。
さいごに
いかがでしょうか？今回は、認証方法ポリシーについて取り上げさせて頂きました。認証方法ポリシーでは、これまでのレガシーポリシーよりも詳細に制御することが可能であり、証明書ベースのような認証メソッドも使用することが可能になっています。レガシーポリシーが廃止されるまで1年以上の猶予が残っておりますので、余裕をもって移行計画をご検討されることをお勧めいたします。
