編集

次の方法で共有


Microsoft Entra 多要素認証に関してよく寄せられる質問

この FAQ では、Microsoft Entra 多要素認証と多要素認証サービスの利用について、よく寄せられる質問に回答します。 FAQ の内容は、サービス全般、課金モデル、ユーザー エクスペリエンス、トラブルシューティングに分けてまとめられています。

重要

2022 年 9 月、Microsoft は Multi-Factor Authentication Server の廃止を発表しました。 2024 年 9 月 30 日以降、Multi-Factor Authentication Server のデプロイでは、多要素認証要求機能が提供されなくなり、組織で認証が失敗する可能性があります。 認証サービスが中断されることなくサポート状態を維持するには、組織が、最新の MFA Server 更新プログラムに含まれている最新の移行ユーティリティを使って、クラウドベースの Microsoft Entra 多要素認証サービスにユーザーの認証データを移行する必要があります。 詳細については、MFA サーバーの移行に関する記事を参照してください。

全般

Azure Multi-Factor Authentication Server ではどのようにユーザー データが処理されますか。

Multi-Factor Authentication Server では、ユーザーのデータはオンプレミス サーバーにだけ格納されます。 永続的なユーザー データはクラウドに格納されません。 ユーザーが 2 段階認証を実行すると、Multi-Factor Authentication Server から Microsoft Entra 多要素認証クラウド サービスにデータが送信され、認証が要求されます。 Multi-Factor Authentication Server と多要素認証クラウド サービス間の通信には、送信方向のポート 443 経由で Secure Sockets Layer (SSL) またはトランスポート層セキュリティ (TLS) が使用されます。

認証要求がクラウド サービスに送信されると、認証レポートと使用状況レポート用のデータが収集されます。 2 段階認証ログには、次のデータ フィールドが含まれています。

  • 一意の ID (ユーザー名またはオンプレミスの Multi-Factor Authentication Server ID のいずれか)
  • 姓と名 (省略可能)
  • 電子メール アドレス (省略可能)
  • 電話番号 (音声通話または SMS メッセージ認証を使う場合)
  • デバイス トークン (モバイル アプリ認証を使用する場合)
  • 認証モード
  • 認証の結果
  • Multi-Factor Authentication のサーバー名
  • Multi-Factor Authentication のサーバー IP
  • クライアント IP (使用可能な場合)

オプション フィールドを Multi-Factor Authentication Server で構成できます。

認証データと共に、認証結果 (成功または拒否) と、拒否された場合はその理由が保存されます。 このデータは、認証と使用状況のレポートで確認できます。

詳細については、「Microsoft Entra 多要素認証のデータ所在地と顧客データ」を参照してください。

ユーザーに SMS メッセージを送る際には、どのショート コードが使われますか。

米国では、Microsoft は次のショート コードを使います。

  • 97671
  • 69829
  • 51789
  • 99399

カナダでは、Microsoft は次のショート コードを使います。

  • 759731
  • 673801

SMS メッセージまたは音声ベースの多要素認証のプロンプトが常に同一番号で配信されるという保証はありません。 ユーザーのために、Microsoft は、ルートを調整して SMS メッセージの配信率を向上させる際に任意のタイミングでショート コードを追加または削除する場合があります。

Microsoft は、米国とカナダ以外の国または地域ではショート コードをサポートしていません。

Microsoft Entra 多要素認証ではユーザーのサインインが調整されますか。

はい。通常、短時間に認証要求の繰り返しを伴う特定のケースでは、通信ネットワークを保護し、MFA 疲労型の攻撃を軽減し、すべての顧客の利益のために独自のシステムを保護するために Microsoft Entra 多要素認証によってユーザーのサインイン試行が調整されます。

具体的な調整に関する制限については共有しませんが、妥当な使用状況に基づいています。

認証用の電話呼び出しやテキスト メッセージの送信について、自分の組織に料金が請求されることはありますか。

いいえ。Microsoft Entra 多要素認証経由でユーザーに対して行われる電話呼び出しや送信されるテキスト メッセージの料金が個別に請求されることはありません。 認証ごとの MFA プロバイダーを使用している場合は認証ごとに料金が請求されますが、認証の手段に対する請求は行われません。

ユーザーが受ける電話呼び出しやテキスト メッセージの料金は、個人で契約している電話サービスに従って請求されます。

ユーザーごとの課金モデルで、課金の対象となるのは有効化されているすべてのユーザーですか、それとも 2 段階認証を実行したユーザーのみですか。

その月に 2 段階認証を実行したかどうかに関係なく、多要素認証を使用するように構成されたユーザーの数に基づいて課金されます。

多要素認証の請求はどのように行われますか。

ユーザーごとまたは認証ごとの MFA プロバイダーを作成すると、組織の Azure サブスクリプションは毎月使用量に基づいて課金されます。 この課金モデルは、仮想マシンと Web Apps の使用量に対する Azure の課金方法に似ています。

Microsoft Entra 多要素認証のサブスクリプションを購入すると、組織はユーザーごとに年間ライセンス料金のみを支払います。 MFA ライセンスと Microsoft 365、Microsoft Entra ID P1 または P2、あるいは Enterprise Mobility + Security バンドルは、この方法で課金されます。

詳細については、Microsoft Entra 多要素認証を取得する方法に関する記事を参照してください。

Microsoft Entra 多要素認証の無料版はありますか?

セキュリティの既定値群は、Microsoft Entra ID Free レベルで有効にすることができます。 セキュリティの既定値群を使用すると、Microsoft Authenticator アプリを使用しているすべてのユーザーに多要素認証が有効になります。 セキュリティの既定値群では、テキスト メッセージまたは電話による確認を使用することはできず、Microsoft Authenticator アプリだけが使用できます。

詳細については、「セキュリティの既定値群とは」を参照してください。

ユーザーごとおよび認証ごとの使用量課金モデルは、組織でいつでも切り替えることができますか。

使用量ベースの課金方法により、スタンドアロン サービスとして組織で MFA を購入する場合は、MFA プロバイダーを作成する際に課金モデルを選択します。 MFA プロバイダーの作成後に課金モデルを変更することはできません。

MFA プロバイダーが Microsoft Entra テナントにリンクされて "いない" 場合、または新しい MFA プロバイダーを別の Microsoft Entra テナントにリンクする場合、ユーザー設定と構成オプションは転送されません。 また、既存の MFA Server は、新しい MFA プロバイダーによって生成されるアクティブ化資格情報を使用して再アクティブ化する必要があります。 MFA Server を新しい MFA プロバイダーにリンクするために再アクティブ化しても、電話呼び出しやテキスト メッセージによる認証には影響ありませんが、モバイル アプリ通知は、各ユーザーがモバイル アプリを再アクティブ化するまで機能しなくなります。

MFA プロバイダーの詳細については、Azure 多要素認証プロバイダーの概要に関する記事を参照してください。

使用量ベースの課金とサブスクリプション (ライセンスベースのモデル) は、組織でいつでも切り替えることができますか。

場合によります。

ディレクトリに "ユーザーごと" の Microsoft Entra 多要素認証プロバイダーがある場合は、MFA ライセンスを追加できます。 ライセンスを所有しているユーザーは、ユーザーごとの使用量ベースの課金にはカウントされません。 ライセンスのないユーザーに対しては、MFA プロバイダーを通じて MFA を有効化できます。 多要素認証を使用するように構成されているすべてのユーザーにライセンスを購入して割り当てた場合は、Microsoft Entra 多要素認証プロバイダーを削除できます。 将来、ユーザー数がライセンス数を上回るような場合には、ユーザーごとの MFA プロバイダーをいつでも別に作成できます。

ディレクトリに "認証ごと" の Microsoft Entra 多要素認証プロバイダーがある場合は、その MFA プロバイダーがサブスクリプションにリンクされている限り、認証ごとに常に料金が請求されます。 MFA ライセンスをユーザーに割り当てることはできますが、2 段階認証の要求が行われると、それが MFA ライセンスの割り当てられたユーザーによる要求かどうかに関係なく、毎回料金が請求されます。

組織が Microsoft Entra 多要素認証を使用するには、ID の使用と同期が必要ですか。

組織で使用量ベースの課金モデルを使用する場合、Microsoft Entra ID の利用は任意であり、必須ではありません。 MFA プロバイダーが Microsoft Entra テナントにリンクされていない場合は、Azure Multi-Factor Authentication Server をオンプレミスにのみデプロイできます。

ライセンス モデルでは Microsoft Entra ID が必要です。これは、ライセンスを購入してディレクトリ内のユーザーに割り当てると、そのライセンスが Microsoft Entra テナントに追加されるためです。

ユーザー アカウントの管理とサポート

ユーザーが電話で応答を受信できない場合、そのユーザーにはどのように伝えればよいですか。

認証用の電話または SMS メッセージを受け取るための操作を、5 分間に 5 回を上限として試行するようユーザーに伝えてください。 Microsoft では、発信と SMS メッセージの配信には複数のプロバイダーを使っています。 このアプローチがうまくいかない場合は、サポート ケースを開いてさらにトラブルシューティングを行うことができます。

サードパーティのセキュリティ アプリでは、確認コードのテキスト メッセージまたは音声通話をブロックすることもできます。 サードパーティのセキュリティ アプリを使用している場合は、保護を無効にしてから、別の MFA 検証コードを送信するように依頼するようにしてください。

上記の手順でうまく行かない場合は、ユーザーが複数の認証方法に構成されているかどうかを確認します。 再度サインインを試しますが、その際にサインイン ページで別の認証方法を選択します。

詳細については、エンドユーザー向けトラブルシューティング ガイドを参照してください。

アカウントに入れないユーザーがいる場合はどうすればよいですか。

ユーザーに登録プロセスを再度実行してもらうことで、ユーザーのアカウントをリセットできます。 詳細については、クラウドでの Microsoft Entra 多要素認証によるユーザーおよびデバイスの設定の管理に関するページを参照してください。

アプリ パスワードを使用している携帯電話を紛失したユーザーがいる場合は、どうすればよいですか。

未承認のアクセスを防ぐには、そのユーザーのアプリ パスワードをすべて削除します。 ユーザーは、代わりのデバイスを入手した後に、パスワードを再作成できます。 詳細については、クラウドでの Microsoft Entra 多要素認証によるユーザーおよびデバイスの設定の管理に関するページを参照してください。

ユーザーがブラウザー以外のアプリにサインインできない場合はどうすればよいですか。

組織でまだ従来型クライアントを使用しており、かつアプリ パスワードの使用を許可している場合、ユーザーがこのような従来型のクライアントにユーザー名とパスワードでサインインすることはできません。 代わりに、ユーザーはアプリ パスワードを設定する必要があります。 ユーザーはサインイン情報をクリア (削除) してアプリを再起動し、ユーザー名と、通常のパスワードではなく "アプリ パスワード" を使用してサインインしなければなりません。

組織で従来型クライアントを使用していない場合は、アプリ パスワードの作成をユーザーに許可しないようにしてください。

注意

Office 2013 クライアントのための最新の認証

アプリ パスワードは、先進認証をサポートしていないアプリにのみ必要になります。 Office 2013 クライアントでは、先進認証プロトコルがサポートされますが、構成が必要です。 Office 2013 の 2015 年 3 月以降の更新を実行しているすべてのお客様が、最新の認証を利用できます。 詳細については、「Updated Office 365 modern authentication (Office 365 の先進認証の更新)」を参照してください。

テキスト メッセージが届かない場合や、認証がタイムアウトになる場合があると、ユーザーが訴えています。

サービスの信頼性に影響する可能性がある制御不能な要因があるため、SMS メッセージの配信は保証されません。 これらの要因には、宛先の国または地域、携帯電話会社、信号の強さなどがあります。

サードパーティのセキュリティ アプリでは、確認コードのテキスト メッセージまたは音声通話をブロックすることもできます。 サードパーティのセキュリティ アプリを使用している場合は、保護を無効にしてから、別の MFA 検証コードを送信するように依頼するようにしてください。

テキスト メッセージがユーザーに確実に届かない問題が頻発する場合は、代わりに Microsoft Authenticator アプリか電話呼び出しによる認証方法を使用するようユーザーに指示してください。 Microsoft Authenticator は、携帯電話と Wi-Fi 接続の両方で通知を受け取ることができます。 さらに、デバイスに信号がまったくない場合でも、モバイル アプリは検証コードを生成できます。 Microsoft Authenticator アプリは、AndroidiOSWindows Phone で利用できます。

ユーザーが認証コードを入力しなければならない、テキスト メッセージを受信してからシステムがタイムアウトになるまでの制限時間は変更できますか。

場合によりますが、変更できます。

MFA Server v7.0 以降の単方向 SMS の場合、レジストリ キーを設定してタイムアウト設定を構成できます。 MFA クラウド サービスがテキスト メッセージを送信すると、確認コード (またはワンタイム パスコード) が MFA サーバーに返されます。 MFA サーバーは、既定ではコードをメモリ内に 300 秒間保存します。 300 秒が経過する前にユーザーがコードを入力しないと、認証は拒否されます。 既定のタイムアウト設定を変更するには、次の手順を実行します。

  1. HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor にアクセスします。
  2. pfsvc_pendingSmsTimeoutSeconds という名前の DWORD レジストリ キーを作成し、MFA Server でワンタイム パスコードを保管する時間を秒単位で設定します。

ヒント

MFA サーバーが複数ある場合、ユーザーに送信された確認コードを認識しているのは、元の認証要求を処理した 1 つだけです。 ユーザーがコードを入力する際に、そのコードを検証するための認証要求を同じサーバーに送信する必要があります。 コードの検証を別のサーバーに送信すると、認証が拒否されます。

ユーザーが定義されたタイムアウト期間内に SMS に応答しない場合、認証は拒否されます。

クラウドの Microsoft Entra 多要素認証を使用した一方向の SMS の場合 (AD FS アダプターやネットワーク ポリシー サーバー拡張機能を含む)、タイムアウト設定を構成することはできません。 Microsoft Entra ID は、確認コードを 180 秒間保存します。

Multi-Factor Authentication Server でハードウェア トークンを使用できますか。

Multi-Factor Authentication Server を使用している場合、サード パーティによるオープン認証 (OATH) の時間ベースのワンタイム パスワード (TOTP) トークンをインポートして 2 段階認証で使用できます。

CSV ファイル内に秘密キーを配置して Multi-Factor Authentication Server にインポートすると、OATH TOTP トークンである ActiveIdentity トークンを使用できます。 クライアント システムでユーザー入力を受け入れられる限り、OATH トークンは、Active Directory フェデレーション サービス (ADFS)、インターネット インフォメーション サーバー (IIS) のフォームベース認証、リモート認証ダイヤルイン ユーザー サービス (RADIUS) で使用できます。

以下の形式のサードパーティによる OATH TOTP トークンをインポートできます。

  • 移植可能な対称キー コンテナー (PSKC)
  • CSV。シリアル番号、Base 32 形式の秘密キー、および時間間隔がファイルに含まれている場合

Multi-Factor Authentication Server を使用してターミナル サービスをセキュリティで保護することはできますか。

はい。ただし、Windows Server 2012 R2 以降を使用している場合は、リモート デスクトップ ゲートウェイ (RD ゲートウェイ) の使用によってのみターミナル サービスをセキュリティで保護できます。

Windows Server 2012 R2 におけるセキュリティの変更により、Multi-Factor Authentication Server から Windows Server 2012 以前のバージョンのローカル セキュリティ機関 (LSA) のセキュリティ パッケージに接続する方法が変わりました。 Windows 2012 以前のターミナル サービスのバージョンでは、Windows 認証でアプリケーションをセキュリティで保護することができます。 Windows Server 2012 R2 を使用している場合は、RD ゲートウェイが必要です。

MFA Server で発信者 ID を構成しましたが、ユーザーがまだ匿名の発信者から多要素認証の呼び出しを受けます。

公衆電話網経由で多要素認証の呼び出しが行われた場合、発信者 ID をサポートしていない通信事業者を通じて呼び出しがルーティングされることがあります。 この通信事業者のビヘイビアーにより、多要素認証システムが常に発信者 ID を送信していても、発信者 ID は保証されません。

セキュリティ情報の登録を求めるメッセージがユーザーに表示されるのはなぜでしょうか。

セキュリティ情報の登録を求めるメッセージがユーザーに表示される場合、以下のようないくつかの理由が考えられます。

  • そのユーザーは Microsoft Entra ID の管理者によって MFA が有効化されているが、まだアカウントにセキュリティ情報を登録していない。
  • そのユーザーに対して、Microsoft Entra ID でのセルフサービス パスワード リセット が有効化されている。 セキュリティ情報は、将来パスワードを忘れた場合に、それをリセットするために役立ちます。
  • そのユーザーは、MFA を要求する条件付きアクセス ポリシーが設定されたアプリケーションにアクセスしたが、以前に MFA に登録していない。
  • そのユーザーは Microsoft Entra ID (Microsoft Entra Join を含む) にデバイスを登録しようとしており、ユーザーの組織ではデバイスの登録に MFA を要求しているが、ユーザーは事前に MFA への登録を行っていない。
  • そのユーザーは Windows 10 で (MFA を要求する) Windows Hello for Business を生成しているが、以前に MFA に登録していない。
  • 組織で作成および有効化されている MFA 登録ポリシーが、そのユーザーに適用されている。
  • そのユーザーは事前に MFA への登録を行っているが、選択した認証方法が、その後管理者によって無効化されている。 このため、ユーザーはもう一度 MFA 登録を行い、新しい既定の認証方法を選択する必要があります。

エラー

ユーザーがモバイル アプリの通知を使用しているときに "認証要求はアクティブ化されたアカウントのものではありません" というエラー メッセージが表示された場合、そのユーザーはどうすればよいですか。

次の手順を完了して、Microsoft Authenticator から自分のアカウントを削除し、再度追加するようにユーザーに依頼します。

  1. 自分のアカウント プロファイルに移動して、組織のアカウントでサインインします。
  2. [追加のセキュリティ確認] を選択します。
  3. Microsoft Authenticator アプリから既存のアカウントを削除します。
  4. [構成] をクリックし、Microsoft Authenticator を再構成するための手順を行います。

ブラウザー以外のアプリケーションでサインインしたときに 0x800434D4L エラー メッセージが表示された場合、ユーザーはどうすればよいでしょうか。

0x800434D4L エラーは、2 段階認証を要求するアカウントでは機能しない、ローカル コンピューターにインストールされているブラウザー以外のアプリケーションにサインインしようとすると発生します。

このエラーを回避するには、管理関連の操作用と管理以外の操作用に異なるユーザー アカウントを使用します。 非管理アカウントを使用して Outlook にサインインできるように、後ほど、管理アカウントと非管理アカウントのメールボックスにリンクを作成することができます。 このソリューションの詳細については、「管理者がユーザーのメールボックスの内容を開いたり表示したりできるようにする」を参照してください。

エラー コード"LsaLogonUser failed with NTSTATUS -1073741715 for MFA Server (MFA サーバーで LsaLogonUser が NTSTATUS -1073741715 で失敗しました)" のエラーが発生する原因として考えられるものは何ですか?

エラー 1073741715 = ステータス ログオン エラー -> 試行されたログオンが無効。 これは、無効なユーザー名または認証のいずれかが原因です。

このエラーの考えられる理由: 入力されたプライマリ資格情報が正しい場合は、MFA サーバーとドメイン コントローラーでサポートされている NTLM バージョンが一致していない可能性があります。 MFA サーバーでは、NTLMv2 (LmCompatabilityLevel = 5) ではなく NTLMv1 (LmCompatabilityLevel = 1 から 4) のみがサポートされます。

次のステップ

ここで質問に対する回答が見つからない場合は、次のサポート オプションをご利用いただけます。

  • Microsoft サポート技術情報を検索して、一般的な技術上の問題の解決方法を探します。
  • このコミュニティで技術的な質問と回答を検索して参照したり、Microsoft Entra の Q&A で独自の質問を投稿したりできます。
  • さらにサポートが必要な場合は、Multi-Factor Authentication Server サポートを通して、Microsoft の専門家に問い合わせてください。 お問い合わせの際は、問題に関する情報をできるだけお知らせいただくと役に立ちます。 エラーが表示されたページ、具体的なエラー コード、具体的な ID、エラーが表示されたユーザーの ID などの情報をご提供ください。