Zenn
🎃

entra参加端末で、パスワードレスMFAを要求する時の動作

2025/03/25に公開
1
Windows Hello
Entra ID
tech

💻

Entra参加デバイスでは、Windows hello for business(以下、WHfBと記載)は既定で有効になります。
条件付きアクセスでパスワードレスMFAを有効化しているとき、WHfBを使っていれば条件は満たせるような気がしますが、Microsoft Authenticatorのアプリ等は使う場面があるのか？と疑問に思ったので検証，問い合わせしてみました。

【そもそも】

PRTトークン：すごーく簡単に書くと、Entraで認証したときに、その認証に関する様々な情報が付与されて、それを持って他のアプリへのSSO等に利用できるもの。（何回もサインインしなくてよくなる）
詳しい仕組みは下記を参照
https://youtu.be/BU-nVn9CDmw?si=h-DxtOaqA0naR7F7

プライマリ更新トークン (PRT) と Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn

PRT は、ユーザーが組織の資格情報を使ってサインインするとき、Windows ログオンの間に発行されます。

このシナリオでは、Microsoft Entra CloudAP プラグインが PRT のプライマリ機関です。
https://learn.microsoft.com/ja-jp/entra/identity/devices/concept-primary-refresh-token

図解）https://qiita.com/babaneko256/items/2a04866fdd5700c0c6bc

ブログ）Entra https://mitsurublog.com/post-8017/#toc_id_1

  • windows hello for businessとは

Windows Helloは、ユーザーが従来のパスワードではなく生体認証データまたは PIN を使用して Windows デバイスにサインインできるようにする認証テクノロジです。 これは、フィッシング耐性の 2 要素認証と組み込みのブルート フォース保護によって強化されたセキュリティを提供します。

Windows Hello for Businessは、デバイス構成証明、証明書ベースの認証、条件付きアクセス ポリシーなど、エンタープライズ レベルのセキュリティと管理機能を提供するWindows Helloの拡張機能です。 ポリシー設定をデバイスに展開して、セキュリティで保護され、組織の要件に準拠していることを確認できます。

https://learn.microsoft.com/ja-jp/windows/security/identity-protection/hello-for-business/

※Windows helloとWindows Hello for Business の違い　
詳細は別記事で記載します。

  • Windows Hello はパスワード情報そのものを端末の TPM と呼ばれるセキュアな領域に格納し、PIN や生体認証を行うことで TPM からパスワードそのものを提示します。
  • Windows Hello for Business はパスワード自体をログオン処理で使用しておらず、秘密鍵/公開鍵のペアによって認証する仕組みとなり、TPM にはパスワードではなく秘密鍵が格納されます。
  • Windows Hello は Azure AD ユーザーとして認証しない構成 (端末のローカル ユーザーとしてサインイン、もしくはオンプレミス AD に参加して AD ユーザーとしてサインイン) 時のみの利用を想定しています。

https://jpazureid.github.io/blog/azure-active-directory/how-to-disable-whfb/

※entra参加後、windows hello for businessは既定で有効になる

→Entra参加デバイスで、既定でWHfBが有効になる=

entraアカウントでPCログインするようになる。その際ID+パスワード、もしくは、ID+WHfB(生体認証かPINなど)を利用してPCにログオンすることができるということを意味します。
※WHfBのみが利用可能で、ID+パスワードの認証ができないというわけではなく、どちらも利用できます。

【本題】

設定する条件付きクセス

[名前]

ポリシーA

[割り当て]

◇ユーザー

  • 対象 : 任意のユーザーを指定

◇ターゲット リソース

  • 対象 : リソース(以前のすべてのクラウドアプリ)

◇条件

  • デバイス プラットフォーム
      • 構成 : はい
        --- 対象
        ---- デバイス プラットフォームの選択
        ----- Windows

[アクセス制御]

◇許可

  • アクセス権の付与

      • 認証強度が必要

    --- Passwordless MFA (パスワードレス MFA)

パスワードレスMFAとは

https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-authentication-strengths

参考)Authenticator のパスワードレスサインイン　https://zenn.dev/takuyaot/books/45d4f4494a63ce/viewer/9717d5

MS公式サポートブログ

https://jpazureid.github.io/blog/azure-active-directory/why-are-my-users-not-prompted-for-mfa-as-expected/

ポイント #2 - Windows Hello for Business のサインインは MFA の一種である

• ユーザーが持っているもの - デバイス そのもの

• ユーザーが知っているもの (またはユーザーそのもの) - PIN、指紋、顔のスキャン

ポイント #3 - Windows Hello for Business のサインイン後、PRT には、ユーザーが MFA を完了したことを示す追加要素 (または “クレーム”) が入ります。

ポイント #4 - Azure AD は WHfB を用いたサインインによる MFA クレームを、他の “典型的な” MFA (SMS テキスト、電話など) と同等に扱います。

ポイント #5 - MFA のクレームは PRT が有効である限り維持されます。

要は、このユーザーが MFA を必要とするリソース (Azure AD 条件付きアクセス ポリシーで保護されている) にアクセスしようとしても、Azure AD はサイレントに PRT と既存の MFA クレームを確認し、ユーザーには MFA の要求がなされない。

仮説

条件付きアクセスでパスワードレスMFA要求する

→windows hello for businessを使っていれば、PCログオンの後、MFAを要求されることは一切ないのでは？？

回答

──────────────────────────────────────

■ご質問 1

#質問1

この際、端末AからM365各アプリへアクセスする際は、パスワードの入力や、Authenticatorによる認証は必要なく、entraでの認証が実施できる認識ですが合っていますでしょうか。

■ご質問 1 へのご案内

はい、ご認識の通りです。

──────────────────────────────────────

■ご質問 2

その理由としては、Windows hello for businessでのMFAのクレームが付与されたPRTを持っているためでしょうか？

参考にした公開情報：

https://learn.microsoft.com/ja-jp/entra/identity/devices/concept-primary-refresh-token#how-is-a-prt-issued

https://jpazureid.github.io/blog/azure-active-directory/why-are-my-users-not-prompted-for-mfa-as-expected/

■ご質問 2 へのご案内

はい、こちらもご認識の通りです。

──────────────────────────────────────

■ご質問 3

＃質問2

＃前提　に記載の通り設定をしている場合において、

端末Aからのサインインにおいて、AuthenticatorもしくはSMSを使って認証が必要になるシチュエーションはありますでしょうか。

シチュエーションが想定される場合、どのようなシチュエーションかご教示ください。

■ご質問 3 へのご案内

Windows Hello for Business がプロビジョニングされた後の端末 A からのサインインにおいては、以下の条件がすべてそろった場合は Microsoft Authenticator アプリや SMS での MFA が必要になるかと存じます。

・Edge の InPrivate ウインドウなど、PRT が認証に使われないアクセスを実施。

・ポリシー A の対象にならないサインインが発生。

・MFA の要求が発生。

──────────────────────────────────────

**

結論
・基本いらないが、予備としてAuthenticator アプリ(電話によるサインイン)を設定しておくべき。

**おまけ1
WHfBの初回登録時には、その顔認証を登録する本人が本物か(なりすましではないかどうが)を確認するために、WHfB以外の方法で多要素認証を実施する必要があります。
これは条件付きアクセスを設定していなければ、SMSをはじめとするMSが掲示しているすべての多要素認証の方法で実施できることが想定されますが、
今回設定した条件付きアクセスでは「パスワードMFA」を要求しているため、Microsoft Authenticator 電話によるサインイン/FIDO2セキュリティキー/証明書ベースの認証 (多要素)のいずれかを実施する必要があります。
つまり、運用開始後には基本的にWHfB以外の手段で認証することはありませんが、初回登録時/PRTが機能しない事態等に備えて、もう一つの多要素認証の手段は必要。。

**おまけ2
冒頭で　下記のように記載しました。
※WHfBのみが利用可能で、ID+パスワードの認証ができないというわけではなく、どちらも利用できます。
ですが、今回設定している条件付きアクセス「パスワードレスMFA」に対して、ID+パスワードでPCへのログオンした場合はその要求を満たしていないことになります。
つまり端末にログオンする時にID＋パスワード、WHfBのどちらでもPC自体にはログオンできるのに、
ID+パスワードでPCログオンした場合は、Microsoft365等のアクセスには失敗するという事件がおきます。
この点は運用開始時にユーザーによく注意喚起しておく必要があります。
ID+パスワードでログインすることを禁止し，WHfBのみ許可するという制御ができるかは現在調査中です。。

1

Discussion

ログインするとコメントできます