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

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

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

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

オプションのフィールドは、多要素認証サーバーで構成できます。

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

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

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

• 97671
• 69829
• 51789
• 99399

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

• 759731
• 673801

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

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

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

特定の調整制限は共有しませんが、適切な使用に基づいています。

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

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

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

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

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

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

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

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

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

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

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

場合によります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多要素認証呼び出しが公衆電話ネットワーク経由で発信される場合、発信者番号をサポートしていない通信事業者経由でルーティングされる場合があります。 この通信事業者のビヘイビアーにより、多要素認証システムが常に発信者 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 エラーは、2 段階認証を必要とするアカウントでは機能しないローカル コンピューターにインストールされている非ブラウザー アプリケーションにサインインしようとすると発生します。

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

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

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

次のステップ

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

• Microsoft サポート技術情報を検索して、一般的な技術上の問題の解決方法を探します。
• このコミュニティで技術的な質問と回答を検索して参照したり、Microsoft Entra の Q&A で独自の質問を投稿したりできます。
• 多要素認証サーバーサポートMicrosoft プロフェッショナルにお問い合わせください。 お問い合わせの際は、問題に関する情報をできるだけお知らせいただくと役に立ちます。 エラーが表示されたページ、具体的なエラー コード、具体的な ID、エラーが表示されたユーザーの ID などの情報をご提供ください。