FIDO2 & Entra 完全パスワードレスのための条件付きアクセス

Last updated at 2025-06-02Posted at 2025-06-02

はじめに

WHfB と FIDO2 のみを許可した完全パスワードレス（Microsoft Authenticator さえも使用させない）を目的とした条件付きアクセスはどういう構成になるのか、研究の成果を共有したいと思います。

想定したシーン
Microsoft Entra テナントを初めて導入する場合、通常は認証に MFA が使われれるため、スマホ (Microsoft Authenticator) の利用が必要です。

しかし、従業員に社用のスマホを貸与できない組織も多く存在していると思います。
そして、個人所有や、協力会社の人のスマホを使ってもらおうとした場合、調整が難航することもあるかと思います。

このスマホの手配が足枷となり、Microsoft Authenticator の利用が困難になることもあります。
そのような場合の解決策として、FIDO2 セキュリティキーを提供する方法があります。

社用スマホが既に導入されていれば、実質コストゼロで Microsoft Authenticator を利用できるのですが、スマホを新規に手配する必要がある場合は、数万円のコストがかかり、さらに通信料もかかるため、認証のためだけにスマホを導入することはナンセンスです。

それに対して、FIDO2 セキュリティキーであれば、数千円の物品を購入するだけで済むため、現実的です。

課題
ユーザーアカウントに FIDO2 セキュリティキーを割り当てる際には、なんと MFA を求められてしまうのが既定の動作となっています。

そして、その MFA 要件を満たすために、Microsoft Authenticator が必要になります。
先ほど説明したとおり、スマホの提供が難しい組織にとっては、これでは完全パスワード化ができません。

ユーザーが FIDO2 を登録する際の要件
https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-enable-passkey-fido2?wt.mc_id=mvp_407731#requirements

解決策
今回の記事で紹介する方法を使うと、そのようなアンバランスな状況を脱却でき、課題を解決できます。

期待される結果（ゴール）

マイアカウント（セキュリティ情報）画面には、TAP (Temporary Access Password) でアクセスを行い、ユーザー自身で、FIDO2 セキュリティキーをプロビジョニングできるようになります（TAP は、MFA の要件を満たします）
ログオンについては、条件付きアクセスで、WHfB or FIDO2 のみが許可されます
ユーザーに対して、Microsoft Authenticator の登録を求めることがなくなります
利用者には、組織が未検証の FIDO2 セキュリティーは、使わせません

前提事項

本章以降の構成を実施する前には、以下の記事を参考に FIDO2 を有効化しておく必要があります。

さらにセキュリティの既定値群が無効化されており、条件付きアクセスが利用できるようになっている必要があります。これは、Microsoft Entra Premium P1 以上のライセンスが必要です。

1. 認証強度についての構成

1-1. 認証強度とは？

Microsoft Entra の 認証強度 は、条件付きアクセスを使って、リソースへのアクセスを許可する際の 認証方法の組み合わせ を指定することができます。

あらかじめ３種類の組み込みの認証強度が用意されており、さらに任意の組み合わせを定義できる、カスタムの認証強度という機能も用意されています。

MFA 強度（多要素認証 / Multifactor authentication）
パスワードレス MFA 強度 (Passwordless MFA)
フィッシングに強い MFA 強度 (Phishing-resistant MFA)
カスタムの認証強度（任意の名前）

公開情報：条件付きアクセスの認証強度
https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-authentication-strengths?wt.mc_id=mvp_407731

公開情報より、抜粋

条件付きアクセスで "認証強度が必要" を使用する際の選択肢

あらかじめ用意された組み合わせ以外で運用したい場合には、カスタムの認証強度 を利用することができます。

公開情報：カスタム条件付きアクセス認証の強度
https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-authentication-strength-advanced-options?wt.mc_id=mvp_407731

1-2. 完全パスワードレス運用を実現するための認証強度は？

今回のシナリオでは、以下の ①～③ だけをテナントへのサインインとして許可する必要があります。
① Windows Hello for Business
② パスキー (FIDO2)
③ 一時アクセスパス(1回限りの使用)

この組み合わせは、組み込みの認証強度 の組み合わせには存在しないため、カスタムの認証強度 を使用する必要があります。

次章の手順で、まずカスタムの認証強度の定義を行って、条件付きアクセスポリシーで利用できる状態にしておきます。

1-3. カスタムの認証強度を定義する手順

1．引き続き、Microsoft Entra 管理センターで作業を行います。
左ペインの保護を開き、条件付きアクセス　を選択します。
続いて、認証強度 を選んでから 新しい認証強度 を押します。

オプション
条件付きアクセスでセキュリティキーの種類（メーカー、製品）も制限したい場合は、以下の ▶ を開いて追加の手順を確認してください。

セキュリティキーの種類で制御したい場合の追加手順

セキュリティキーの種類を制御するためには、AAGUID を知る必要があります。

AAGUID について
以下の記事を参考にしてください。
以下の記事のうち、AAGUID の確認方法 の章だけ参照いただければ OK です。

Microsoft Entraで特定製品の FIDO2 セキュリティキーのみを許可する
https://qiita.com/carol0226/items/4d26717594c2b11126b4

上記の記事の内容を適用すると、該当の AAGUID のセキュリティキーだけをユーザーに紐づけできるようにすることで、結果的に認証でも使えなくなります（テナント内の全ユーザーに一律で適用）

条件付きアクセスで制御する場合は、ユーザーへの紐づけはどのセキュリティキーでも可能にしておきますが、条件（ユーザー・場所・デバイス・アプリ）の組み合わせごとに、個別に AAGUID を可変させて制御することが可能になります。

AAGUID を指定する手順
a) 新しい認証強度のウィンドウが開いたら、パスキー(FIDO2) 欄の 詳細オプション を選択します。

b) パスキー (FIDO2) の詳細オプションのウィンドウで導入した FIDO2 セキュリティキーの AAGUID を入力して、保存を押します。

以上で、指定した AAGUID を持つセキュリティキーのみをこの認証強度として定義することができました。

2．新しい認証強度のウィンドウが開いたら、任意の名前を指定したあと、以下の項目にチェックを入れてから次へを押します。

ビジネス/プラットフォーム資格情報のWindows Hello
パスキー (FIDO2)
一時アクセスパス(1回限りの使用)

3．レビュー タブでは、以下のように表示されたことを確認して作成を押します。

4．以下の通知が表示されれば OK です。

5．以下のようにカスタムの認証強度が追加されていれば OK です。

（参考）
2022 年 10 月 19 日にパブリックプレビューされ、2023 年 5 月 31 日に一般公開 (GA) された機能です。

Support Blog：認証強度 - シナリオに適した認証方式を選択可能に（2022/10/19 パブリックプレビュー）
https://jpazureid.github.io/blog/azure-active-directory/authentication-strength-choose-the-right-auth-method-for-your/

Support Blog：条件付きアクセスの認証強度一般提供開始のお知らせ（2023/5/31 一般公開）
https://jpazureid.github.io/blog/azure-active-directory/ca-authentication-strength-ga/

2. 条件付きアクセスで認証強度を強制する

前章で定義した カスタムの認証強度 は、条件付きアクセスで設定を行うことで、テナントの動作に反映させることができます。

2-1. 既存の条件付きアクセスの状態を確認する

まず、完全パスワードレス用のポリシーを新規で作成するか、既に運用されているポリシーをカスタマイズすれば良いのかを考えます。

今回初めて条件付きアクセスを展開した場合
もし、今回のためにセキュリティの既定値群を無効化して初めて条件付きアクセスを構成した場合は、以下の　オレンジ枠（MICROSOFT マネージド）またはグリーン枠（ユーザー管理）のポリシーが作成されていることと思います。

グリーン枠（ユーザー管理）のポリシーが作成されている場合は、そのポリシーをカスタマイズして利用することができます。

オレンジ枠（MICROSOFT マネージド）は、今回の完全パスワードレスの構成とは共存できません。
そのため、以下のセキュリティの既定値群の記事を参考に、MICROSOFT マネージドのポリシーをオフに構成して、４章の "条件付きアクセスを構成する" に記載されている手順を使って、"ユーザー" のポリシーを作成してください。

セキュリティの既定値群と条件付きアクセスの初回利用について
https://qiita.com/carol0226/items/51a70a561b78af567972

運用中のポリシーに反映させる場合
従来から、条件付きアクセスを使って運用中のテナントの場合は、基本的には、次章（ポリシーの変更箇所）を見ながら、「多要素認証を要求する」が構成されているポリシーを「認証強度が必要」へ変更いただけば良いはずです。

なお、ポリシーの影響が運用中の既存ユーザーに及ばないように、注意しながらテストを行ってください。推奨は別途検証用テナントを使って、仕組みを理解してから本番適用いただいた方がベターです。

2-2. ポリシーの変更箇所

テンプレートから展開したポリシーの場合は、以下の ① と ② に該当するポリシーを変更していきます。
① すべてのユーザーに多要素認証を要求する
② 管理者に対し多要素認証を要求する

上記 ① と ② のポリシーは、テンプレートから展開した以下のポリシーと同様のものを想定しています。

注意点
ゲストユーザー（つまり社外の人）は FIDO2 セキュリティーキーを持っているのか分かりません。

すべてのユーザーに対して完全パスワードレス化を実施しつつ、ゲストアクセスに例外を構成するためには、以下の記事を参考にしてください。

FIDO2 & Entra 完全パスワードレス環境でゲストアクセスはどうする？
https://qiita.com/carol0226/items/49bfa0dcf67dfaca7d1f

ポリシーの設定変更箇所
① と ② のポリシーを順に開いて同じように作業を行います。
ポリシーを開いたら、赤枠の許可を選択します。
右ペインが開いたら、グリーン枠の 多要素認証を要求する にチェックが入っているので、これを外します。

続いて、下図のように、認証強度が必要 にチェックを入れて、前章で定義したカスタムの認証強度である "WHfB&FIDO2" が選択できるようになっているので、これを選択し、選択ボタンを押します。
続いて保存ボタンを押します。

以下の通知が表示されれば OK です。

以上の作業でもともとは Microsoft Authenticator（WHfB / FIDO2 も可）の認証だった構成から、フィッシングに強い MFA（WHfB / FIDO2 / TAP のみ）の認証に移行できました。

公開情報：Microsoft Entra 多要素認証を有効にする
https://learn.microsoft.com/ja-jp/entra/identity/authentication/tutorial-enable-azure-mfa?wt.mc_id=mvp_407731

公開情報：条件付きアクセスの認証強度のトラブルシューティング
https://learn.microsoft.com/ja-jp/entra/identity/authentication/troubleshoot-authentication-strengths?wt.mc_id=mvp_407731

3. ユーザーが FIDO2 セキュリティキー以外を登録できなくする

ここまでの設定を行っても、まだ穴がありました。
ユーザーがマイアカウントのセキュリティ情報から登録する画面では、なんと Microsoft Authenticator や電話の登録ができてしまうのです・・・

以下の画面で Microsoft Authenticator , Hardware token , Phone を "いいえ" にしても反映はされませんでした。

解決策
私のテナントでは、以下の設定をすべて無効化することで、対処することができました。

これで、セキュリティキーだけになりました。目的達成です。

本件の対応については、ハマったのですが以下のコミュニティの投稿をみつけて、解決することができました。

例外
検証オプションが以下のように表示されていて、先ほど説明したようなチェックボックスが表示されていない場合があります。このようなテナントの場合は、この回避策が使えません。

これらのメソッドは現在、検証方法ポリシーで管理されています。認証およびパスワードリセット認証方法ポリシーに使用される方式を管理するには、ここに移動します。

私の身近では、昔から運用しているテナントだとチェックボックスが表示されたのですが、最近サインアップしたようなテナントだと、この状態でした。
認証方式ポリシーの画面に遷移して、"いいえ" にしてみても表示が消えず、回避策が分かっていません。誰か教えてください。

4. オプション：例外設定

以下のような例外がある場合は、どのように対応すればよいか、別の記事に記載してあります。

他社のテナントからのゲストアクセス（前章でも紹介した内容です）

自宅にセキュリティキーを置き忘れて出社してしまった場合
（記載中、後日公開予定）
　
セキュリティキーの PIN を失念した場合
（記載中、後日公開予定）

5. 動作検証

以下の観点で検証していきましょう。
① ID + パスワードでサインインしようとした場合は、ブロックされること
② FIDO2 セキュリティキーを渡された利用者が、自身の Microsoft Entra アカウントに紐づけを行えること
※TAP (Tempory Access Password) でのログオンのみになります。
③ FIDO2 を登録したユーザーが問題なくサインインができること