社内のActive Directory（AD）に「スマホで承認するMFA（多要素認証）」を足したいと考えたとき、最初に引っかかるのが、ADの標準機能だけではVPNの入口やファイルサーバへのアクセスにスマホの承認を挟めない、という点です。そのため、MFAの製品はADのまわりのどこかに部品を足して、認証の途中に割り込む作りになっています。
この記事では、AD運用者・構築者の目線で「どこに何を入れると、どの認証にMFAがかかるのか」「ADやクライアントの設定は何が変わるのか」を、構成図とシーケンス図で整理します。後半では、利用者のスマホで何が起きるかと、いま動いているADにMFAを足していく進め方も説明します。
この記事は、Cisco Duo、Silverfort、Microsoft（Entra多要素認証のNPS拡張、Entra Private Access）の公開資料を参考に、ADにMFAを足すしくみを一般化して整理したものです。特定の製品の仕様や設定手順を説明するものではありません。
部品の名前と置き場所、MFAを求めるタイミング、対応するプロトコル、障害時の既定の動作は、製品やバージョンによって異なります。導入を検討するときは、各メーカー・販売元の最新のドキュメントで確認してください。
- ADの標準機能だけでは、VPNやファイルサーバにスマホ承認を挟めない理由
- MFAを差し込む場所は4つ（認証プロキシ、ログオン画面、DC、クラウドIdP）
- それぞれ何を追加し、ADとクライアントのどこが変わるか（シーケンス図つき）
- 利用者のスマホでは何が起きるか（プッシュ、番号照合、ワンタイムパスワード）
- いま動いているADにMFAを足していく手順と、設計で決めておくこと
ADの標準機能だけではMFAが難しい理由
ADの認証は「パスワードを知っていること」の証明だけで進む
ADのドメインで使われる認証は、主にKerberosとNTLMです。どちらも、ユーザーがパスワード（またはパスワードから作った鍵）を持っていることを、DCとの間で確かめるしくみです。やり取りの途中に「スマホに通知を送って、承認されるまで待つ」という手順はありません。
Kerberosの流れを図にすると、次のようになります。サインイン時にDCからTGT（チケットを発行してもらうためのチケット）を受け取り、ファイルサーバに接続するときは、そのTGTを使って「ファイルサーバ用のサービスチケット」をもらいます。ファイルサーバはチケットを確かめるだけで、利用者に何かを聞くことはしません。
さらに、ファイル共有への接続のような「ネットワークログオン」は、サインイン時に取得した資格情報を使って裏側で自動的に行われ、入力画面は出ません。発行されたチケットはPCにキャッシュされ、有効期限の間は使い回されます（ADの既定では、TGTの有効期限が10時間です）。つまり、画面を出してMFAを求める場所も、DCに毎回聞きに行くタイミングも、もともと用意されていないのです。
標準でできるのは「サインイン時の多要素」まで
Windowsにも多要素のしくみはあります。スマートカードと、Windows Hello for Business（PINや生体情報で端末内の鍵を使う方式）です。どちらも、サインイン時にTGTを取得するところ（KerberosのPKINITという拡張）で、パスワードの代わりに証明書や鍵を使います。
ただし、多要素になるのはサインインの瞬間だけです。その後のファイルサーバやRDP先へのアクセスは、取得済みのTGTやチケットで進みます。また、VPN機器やWi-Fiのように「RADIUSでIDとパスワードを受け取る機器」、LDAPでパスワードを確かめる業務アプリには、この方式はそのまま使えません。
| 認証の場面 | 使われるしくみ | AD単体でのMFA |
|---|---|---|
| PCへのサインイン（コンソール） | Kerberos（NTLMもある） | スマートカード、Windows Hello for Business で多要素にできる |
| サーバへのRDP接続 | Kerberos／NTLM（CredSSP経由） | スマートカードなどは使えるが、スマホ承認は挟めない |
| ファイルサーバ（SMB）、PowerShellリモート、管理ツール | Kerberos／NTLM（ネットワークログオン） | 画面が出ないため、MFAを求める場所がない |
| VPN、Wi-Fi（802.1X） | RADIUS（WindowsのNPSなど）→ AD | パスワードでの認証になる |
| LDAPで認証する業務アプリ・機器 | LDAP（Bind） | パスワードでの認証になる |
| Webアプリ・SaaS | SAML／OIDC（AD FSやクラウドIdP） | IdP側でMFAをかけられる |
VPN、ファイルサーバ、RDPのそれぞれにスマホの承認を挟むには、ADのまわりに何かを足すことになります。RADIUSとLDAPのしくみは、RADIUSの基本とLDAPの基本の記事で説明しています。
MFAを差し込む場所は4つ
製品ごとに名前は違いますが、ADのまわりでMFAを差し込む場所は、おおむね次の4つに分けられます。どれも「認証が通ろうとしている途中で一度止め、クラウドのMFAサービス経由でスマホに承認を求め、承認されたら先に進める」という点は同じです。違うのは、止める場所です。
| 場所 | 止める認証 | 主な対象 |
|---|---|---|
| ① 認証プロキシ | RADIUS、LDAP | VPN、Wi-Fi、LDAPで認証する機器・アプリ |
| ② ログオン画面のエージェント | Windowsの対話型サインイン | PC・サーバへのサインイン、RDP、UACでの昇格。PowerShellリモートなどは受ける側のサーバに別の仕組みを入れる |
| ③ DC（MFAモジュール） | Kerberos、NTLM | ファイルサーバ、PowerShellリモート、管理ツールなど、ADで認証する社内のアクセス |
| ④ クラウドIdP | SAML、OIDC | Webアプリ、SaaS |
どの場所でも、部品は社内から外（クラウドのMFAサービス）へHTTPS（TCP 443）でつなぎに行きます。インターネットから社内へ通信を受け入れる必要がない作りが一般的です。以降、①〜③を順に見ていきます。④はWebのしくみなので、最後に短く触れます。
① 認証プロキシ型：VPN・Wi-Fi・LDAPの入口で止める
VPN機器と、その先のADの間に「認証プロキシ」を挟み、VPNの認証がADに届く手前で止めます。
何を追加するか
社内に「認証プロキシ」と呼ばれるサーバ（WindowsまたはLinuxにソフトウェアを入れる形が多い）を置きます。VPN機器から見ると、認証プロキシはRADIUSサーバそのものです。認証プロキシは受け取ったIDとパスワードをADで確かめ（一次認証）、成功したらMFAサービスに二要素目を要求し、両方そろったところでVPN機器に許可を返します。
一次認証の確かめ方は2通りあります。認証プロキシがDCにLDAP（LDAPS）で問い合わせる方法と、既存のRADIUSサーバ（NPSなど）に転送する方法です。既存のNPSにMFAの拡張機能を足して、NPS自身に二要素目を要求させる形もあります。
NPS（Network Policy Server）は、Windows Serverに入っているMicrosoftのRADIUSサーバです。「ネットワークポリシーとアクセスサービス」の役割を追加すると使えるようになります（Server Coreのインストールでは使えません）。RADIUSサーバとしても、別のRADIUSサーバへ転送するRADIUSプロキシとしても動きます。
一般的なRADIUSサーバ（Linuxのソフトウェアや、ネットワーク機器メーカーのアプライアンスなど）との一番の違いは、ADとのつながり方です。NPSはドメインに参加させると、ADをそのままユーザーのデータベースとして使い、ADのグループやユーザーのダイヤルインのプロパティを条件に「このグループならVPNを許可」といったネットワークポリシーを作れます。802.1XでよくあるPEAP（MS-CHAPv2）も、ADのパスワードでそのまま確かめられます。一般的なRADIUSサーバでは、ADと連携する設定が別に必要です。特にMS-CHAPv2は、ADから平文のパスワードを取り出せないためLDAPだけでは確かめられず、RADIUSサーバをドメインに参加させてADに確認してもらう仕組み（Linuxなら Samba の ntlm_auth など）を追加するのが一般的です。
一方で、NPS自体にはスマホでMFAをかける機能はありません。MFAを足すには、図のようにNPSの前に認証プロキシを置くか（B）、NPSにMFAの拡張機能を入れる（C）ことになります。Microsoftが提供する拡張機能（Entra多要素認証のNPS拡張）を使う場合は、ADのユーザーをEntra IDに同期しておく必要があります。
ADとまわりの機器で変わる設定
| 対象 | 変わること |
|---|---|
| DC・AD | DC自体には何も入れない。LDAPで問い合わせる場合は、検索用のサービスアカウント（読み取りだけの権限）を用意する |
| 認証プロキシ（新規） | 社内にサーバを用意してインストールする。冗長化のため2台以上にすることが多い |
| VPN機器・無線コントローラ | RADIUSサーバの宛先を、NPSなどから認証プロキシに変える。スマホの承認を待つ時間があるので、RADIUSのタイムアウトを長くする（製品の推奨値、例えば60秒以上に合わせる） |
| クライアントPC | 何も入れない（VPNクライアントはそのまま） |
| 通信 | VPN機器→認証プロキシ：RADIUS（UDP 1812）、認証プロキシ→DC：LDAP／LDAPS（TCP 389／636）、認証プロキシ→クラウド：HTTPS（TCP 443） |
VPNのログイン画面にはMFA用の欄がないため、既定ではスマホに自動でプッシュ通知が飛ぶ設定がよく使われます。製品によっては、パスワード欄に「パスワード,ワンタイムパスワード」のようにつなげて入力し、二要素目を選ばせることもできます。ワンタイムパスワードを入力させる方式では、VPN機器との間の認証方式（PAPかMS-CHAPv2か）に制約が出ることがあるので、製品の資料で確認してください。
このパターンで守れないもの
認証プロキシが止められるのは、認証プロキシを通る認証だけです。VPNでつながった後、PCからファイルサーバへの接続はKerberosでDCとやり取りするので、認証プロキシは関わりません。社内に入った後のアクセスまで守りたい場合は、②や③と組み合わせます。
② ログオン画面のエージェント型：サインインとRDPで止める
Windowsのサインイン画面にMFAの手順を足し、画面でのサインインを止めます。エージェントは「サインイン画面が出る側」に入れるのがポイントです。
何を追加するか
サインインを守りたいコンピュータに、エージェント（ソフトウェア）をインストールします。Windowsのサインイン画面は「Credential Provider」という部品で作られていて、エージェントはこの部品として組み込まれます。パスワードを入力した後にMFAの画面が加わり、スマホで承認するとサインインが完了します。
どこに入れるかは、どのサインインを守りたいかで決まります。PCの前で行うサインインを守るならそのPCに、サーバへのRDP接続を守るならRDPで接続される側のサーバに入れます。RDPのサインイン画面は接続先のサーバが出しているので、接続元のPCにエージェントは要りません。DCには、パスワードの確認でいつもどおり使われるだけなので、何も入れません。
ADとまわりの機器で変わる設定
| 対象 | 変わること |
|---|---|
| DC・AD | DCには何も入れない（認証のしくみは変わらない）。エージェントの配布にグループポリシーなどを使うことはある。DCへのRDPも守りたい場合は、DCも「RDP先のサーバ」の1台としてエージェントを入れることになるので、製品がDCへのインストールに対応しているか確認する |
| 利用者のPC | PCへのサインインを守るなら、1台ずつエージェントを入れる。RDPの接続元として使うだけなら、入れなくてよい |
| RDP先のサーバ | RDPのサインインを守るサーバに、1台ずつエージェントを入れる。RDPのときだけMFAを求める、コンソールでも求める、といった範囲を選べることが多い |
| 通信 | 各PC・サーバ→クラウド：HTTPS（TCP 443） |
管理者権限への昇格（UAC）にもMFAをかけられる
「管理者として実行」を選んだときに出るUAC（ユーザーアカウント制御）の確認画面にも、MFAを足せる製品があります。UACで管理者のIDとパスワードを入力する画面も、サインイン画面と同じく、Credential Providerのしくみで資格情報を受け取っています。そのため、エージェントがそこにMFAの手順を加えられます。サインイン時はMFAを求めず、昇格のときだけ求める設定を選べる製品もあります。
ただし、参考にした製品の資料で対象として書かれているのは、パスワードを入力して昇格する場面（図のA）です。管理者アカウントでサインインしていて「はい／いいえ」を押すだけの確認画面（図のB）は、パスワードを入力しないので止める場所がありません。昇格のたびにMFAを求めたいなら、普段は標準ユーザーで作業し、必要なときだけ管理者のIDとパスワードを入力して昇格する運用が前提になります。
オフライン時と障害時
エージェントはサインインのたびにクラウドへ問い合わせるので、ノートPCを社外でネットにつながずに使うときの扱いを決めておく必要があります。製品によっては、事前に登録したスマホのワンタイムパスワードやセキュリティキーで、決めた回数・日数だけオフラインでのサインインを認める機能があります。クラウドに届かないときにMFAを省いて通す（フェイルオープン）か、止める（フェイルクローズ）かも設定で選びます。
このパターンで守れないもの
エージェントが止めるのは、サインイン画面（とUACの昇格画面）を通るサインインだけです。ファイル共有への接続（ドライブの割り当てを含む）、PowerShellのリモート操作（Enter-PSSession、Invoke-Command）、「別のユーザーとして実行」、サービスやタスクスケジューラのログオンは、画面を通らないのでMFAの対象になりません。また、端末の管理者がセーフモードで起動するとエージェントを迂回できる場合があるなど、端末側の仕組みゆえの限界もあります。
このうちPowerShellのリモート操作は、次の節のように受ける側のサーバに別の仕組みを入れると止められます。「別のユーザーとして実行」をドメインアカウントで行う場合は、認証がDCに届くので、③のDC連携型なら製品のポリシーしだいで対象にできます。
PowerShellリモートやSSHは、受ける側のサーバで止める
PowerShellのリモート操作やWindowsのSSHは、サインイン画面を通りません。そこで、リモート操作を受ける側のサーバに「セッションが始まったところでMFAを求める仕組み」を入れる方法があります。参考にした製品では、PowerShellのリモート接続の設定（セッション構成）に、接続されたときに最初に動くスクリプトを登録し、そのスクリプトがスマホに承認を求めます。承認できなければ、接続は拒否されます。
| 対象 | 変わること |
|---|---|
| リモート操作を受けるサーバ | MFAの仕組みを入れる。PowerShellのリモート接続（WinRM）が有効になっていること、署名済みスクリプトを実行できる実行ポリシーになっていることが前提になる製品がある |
| 管理者のPC | 何も入れない。Enter-PSSession などの使い方も変わらない |
| DC・AD | 何も入れない。DCへのリモート操作も守るなら、DCも受ける側のサーバとして入れることになるので、製品がDCを対象にできるか確認する |
| 通信 | 受ける側のサーバ→クラウド：HTTPS（TCP 443） |
画面がないので、承認は自動で届くプッシュ（または電話）になるのが一般的です。利用者は事前にスマホを登録しておく必要があります。また、タスクやジョブから自動で Invoke-Command を実行している場合、人が承認できないので、自動化で使うアカウントや接続先をMFAの対象から分けて考える必要があります。
③ DC連携型：Kerberos・NTLMをDCで止める
ドメインアカウントの認証はすべてDCに集まるので、DCで止めれば、画面が出ないアクセスにもMFAをかけられます。PCやファイルサーバには何も入れません。
何を追加するか
ファイルサーバやPowerShellのリモート操作のように画面が出ないアクセスにもMFAをかけたいときは、すべての認証が集まるDCで止めます。認証を受け付けるすべてのDCに、MFA用のモジュール（製品によって「アダプタ」「センサー」「フィルタ」などと呼ばれる）を入れます。製品によっては、ポリシーを判断する専用のサーバ（社内の仮想アプライアンスやクラウドのサービス）を別に置きます。
動きは次のとおりです。DCはいつもどおりパスワードを確かめ、成功した認証をモジュールが捕まえます。モジュールはポリシーに当てはまるかを判断し、MFAが必要ならDCの応答を保留したまま、スマホに承認を求めます。承認されればDCはチケットを発行し、拒否やタイムアウトなら認証を失敗させます。
ADとまわりの機器で変わる設定
| 対象 | 変わること |
|---|---|
| DC | すべてのDC（RODCを含む、認証を受け付けるDC）にモジュールを入れる。インストールにDCの再起動が必要な製品もある。参考にした製品の資料には、ADのスキーマを変更しないと明記しているものがある |
| AD（グループ・アカウント） | MFAをかける対象のグループと、除外するグループを作る。サービスアカウントやコンピュータアカウントはスマホで承認できないので、除外するか別の制御にする |
| ポリシーサーバ（製品による） | 社内に仮想アプライアンスを置くか、クラウドのサービスを使う |
| クライアントPC・ファイルサーバ | 基本的に何も入れない。製品によっては、MFAの通知をPCの画面に出すためのデスクトップアプリを入れる |
| 通信 | DC（またはポリシーサーバ）→クラウド：HTTPS（TCP 443）。DCとポリシーサーバの間の通信は製品による |
MFAを求めるタイミングは製品で大きく違う
DC連携型で一番差が出るのが、「どの要求でMFAを求めるか」です。大きく分けて、サインイン時のTGTの要求（KerberosのAS-REQ）やNTLMの認証で一度だけ求める作りと、ファイルサーバ用・リモート管理用といったサービスチケットの要求（TGS-REQ、宛先のサービスごと）で求める作りがあります。前者は「ドメインに入るとき」、後者は「どのサーバのどのサービスに入るか」で絞り込めます。
どちらの作りでも、発行されたチケットの有効期限の間は、同じアクセスでスマホが鳴り続けることはありません。逆に言うと、ファイルを開くたびにMFAを求めるような動きにはなりません。
注意しておきたいこと
- アプリ側は「MFA待ち」を知らないので、画面には何も出ません。利用者はスマホに届く通知に気づく必要があります。承認が遅れると、アプリ側がタイムアウトしてエラーになることがあります。
- 画面に番号を出せないので、番号照合（後述）は使えず、「承認／拒否」のプッシュになることが多いです。
- DCはドメイン全体の認証を担う、最も重要なサーバです。クラウドに届かないときに止める設定（フェイルクローズ）にすると、ドメイン全体のサインインが止まるおそれがあります。参考にした製品では、既定をフェイルオープンにしているものもあります。
- NTLMの扱いは製品によって違います。Kerberosだけを対象にし、NTLMの利用を減らすことを前提にしている製品もあります。
このパターンで守れないもの
DCで止められるのは、DCに届くドメインアカウントの認証だけです。サーバのローカルアカウント（.\Administrator など）でのサインインは、サーバ自身が持つアカウント情報で確かめるのでDCを通らず、MFAの対象になりません。ローカルの管理者アカウントは、パスワードをサーバごとに変えて管理する、使える場所を絞る、といった別の対策と組み合わせます。DCに届かないときに、PCにキャッシュされた資格情報でサインインする場合も同じです。
④ クラウドIdP型：Webアプリの入口で止める
AD FSにMFAのアダプタを足す方法や、Entra ConnectなどでADのユーザーをクラウドのIdPに同期し、IdPのサインイン画面でMFAをかける方法です。SAMLやOIDCに対応したWebアプリ・SaaSは、この形でMFAをかけるのが一般的です。ブラウザでIdPの画面を通るアクセスだけが対象なので、社内のKerberos／NTLMによるアクセスは守れません。クラウドのIdPとADの違いは、Microsoft Entra IDとActive Directoryの違いで紹介しています。
4つのパターンを並べると
| 項目 | ① 認証プロキシ | ② ログオン画面 | ③ DC連携 | ④ クラウドIdP |
|---|---|---|---|---|
| 追加するもの | 認証プロキシのサーバ | 各PC・サーバのエージェント | 全DCのモジュール（＋ポリシーサーバ） | IdP、同期ツール、AD FSのアダプタ |
| DCへのインストール | なし | なし | あり | なし（AD FSを使う場合はAD FSサーバに入れる） |
| 端末へのインストール | なし | あり（守るPC、RDP先のサーバ） | 基本なし | なし |
| 守れる場面 | VPN、Wi-Fi、LDAPアプリ | サインイン、RDP | ファイルサーバ、リモート管理などのKerberos／NTLM | Webアプリ、SaaS |
| 守れない場面 | 社内に入った後のアクセス | ネットワークログオン（PowerShellリモートは受ける側に別の仕組みが必要） | 製品の対象外のプロトコル、チケットの有効期限内の再アクセス | Kerberos／NTLM |
| 番号照合 | 使えないことが多い | 使えることが多い | 使えないことが多い | 使えることが多い |
| 影響の大きさ | VPNなど入口だけ | 入れた端末だけ | ドメイン全体 | 連携したアプリだけ |
実際には1つを選ぶのではなく、「VPNは①、サーバへのRDPは②、管理者によるファイルサーバやリモート管理は③」のように、守る場面ごとに組み合わせて使います。
利用者から見たMFA
最初にスマホを登録する
MFAサービスは、ADのユーザーとスマホを直接つなぐわけではありません。間にMFAサービス上の「ユーザー」があり、ADのユーザーとスマホが、それぞれそこに結び付く形です。
| 手順 | だれが | 何をするか |
|---|---|---|
| ① 同期 | 管理者 | ADのMFA対象グループのユーザーを、MFAサービスに同期する。同期はADからMFAサービスへの一方向で、MFAサービスからADへ書き戻すことはない。参考にした製品では、パスワードは取り込まず、同期の部品は認証プロキシが兼ねる |
| ② 登録の案内 | 管理者（MFAサービス） | 利用者に、登録用のリンクやQRコードをメールなどで届ける |
| ③ スマホの登録 | 利用者 | スマホに認証アプリを入れ、QRコードを読み取る。このとき、そのユーザーの認証に使う秘密の情報（鍵）がアプリの中に保存される |
| ④ 紐付け | MFAサービス | MFAサービス上のユーザー「yamada」に、登録したスマホが記録される |
サインインのときは、認証プロキシやDCのモジュールがユーザー名をMFAサービスに送り、MFAサービスはそのユーザーに紐付いたスマホへ通知を送ります。そのため、ADのユーザー名とMFAサービスのユーザー名がそろっている必要があります（別名を登録できる製品もあります）。
認証プロキシ型やDC連携型は、利用者に画面を見せられないので、その場で登録させることができません。対象にする前に、登録を済ませてもらう必要があります。
承認のしかたは3通り
| 方法 | 利用者の操作 | 注意点 |
|---|---|---|
| A プッシュで承認 | スマホに届いた通知を開き、アプリ名や時刻を見て「承認」を押す | 身に覚えのない通知を何度も送りつけて、うっかり承認させる攻撃（MFA疲労攻撃）に注意が必要。身に覚えのない通知は「拒否」するよう周知する |
| B 番号を入力して承認（番号照合） | PCのサインイン画面に出た数字を、スマホに入力して承認する | PCの前にいる本人しか数字を知らないので、MFA疲労攻撃に強い。画面に数字を出せる場面でしか使えない |
| C ワンタイムパスワード | 認証アプリに表示される数字（6桁が多い）を入力する | スマホがネットにつながっていなくても使える。入力欄がない場面では、パスワードの後ろにつなげて入力する方式になる |
スマホをなくしたとき
スマホの紛失や機種変更に備えて、管理者が一時的なコード（バイパスコード）を発行できる製品が一般的です。一度使うか一定時間が過ぎると無効になる設定にしておき、本人確認をしてから伝えるよう、ヘルプデスクの手順も決めておきます。
いま動いているADにMFAを足していく手順
ADは止められない基盤なので、いきなり全員に有効にはしません。参考にした製品の資料や導入事例でも、見える化→監視→段階的に有効化、という順で進めています。
守る場面を洗い出す
VPN、Wi-Fi、サーバへのRDP、管理者によるファイルサーバやリモート管理など、MFAをかけたい場面を挙げます。同時に、ADでどんな認証が行われているか（NTLMがどこで使われているか、サービスアカウントがどこにログオンしているか）を確かめます。ADの認証ログの取り方は、ユーザーのログオン認証の監査を設定する方法で紹介しています。
場面ごとにパターンを決める
STEP 1で挙げた場面ごとに、①〜④のどれで守るかを決めます。迷ったときは、守りたい認証が「どこを通るか」で考えます。VPN機器を通るなら①、サインイン画面やUACを通るなら②、PowerShellリモートなら受ける側のサーバか③、画面を通らず社内でKerberos／NTLMを使うなら③です。
ユーザーを同期し、スマホを登録してもらう
同期の対象にするグループを決め、ADのユーザーをMFAサービスに同期します。利用者にはスマホの登録を案内し、登録が済んだことを管理画面で確認します。登録していない人を対象にすると、その人はサインインできなくなります。
監視だけのモードで動かす
DC連携型の製品には、MFAを強制せずに「この設定ならMFAを求めていた」という記録だけを残すモード（監査モード、レポートのみ、など）を持つものがあります。しばらく動かして、サービスアカウントやバッチ処理が対象に入っていないか、思わぬ機器からの認証がないかを確かめ、除外の設定を整えます。
小さく有効にして、広げる
最初は、IT部門のテストユーザーや管理者アカウントなど、影響の小さい範囲で有効にします。問題がなければ、重要なサーバ、一般のユーザーへと広げます。障害時に備えて、MFAの対象から外した緊急用の管理者アカウントを用意し、使ったら気づけるように監視しておきます。
設計で決めておくこと
| 項目 | 決めること |
|---|---|
| 障害時の動作 | クラウドのMFAサービスに届かないとき、MFAを省いて通す（フェイルオープン）か、止める（フェイルクローズ）か。DC連携型でフェイルクローズにすると、ドメイン全体のサインインが止まるおそれがある。特権の操作だけ止める、のように対象で分けられるかも確認する |
| 通信 | 社内から外へのHTTPS（TCP 443）。宛先は製品ごとに決まっており、IPアドレスが変わることがあるので、FQDNで許可できるか確認する。プロキシを経由させる場合はその設定も |
| 冗長化 | 認証プロキシは2台以上。DC連携型はすべてのDCに入れ、ポリシーサーバがある場合はその冗長化も |
| タイムアウト | VPN機器やアプリが、スマホの承認を待てる時間になっているか |
| 除外の範囲 | サービスアカウント、コンピュータアカウント、緊急用アカウント。除外したアカウントは別の手段（ログオン先の制限、監視）で守る |
| 登録と紛失時の手順 | 新入社員の登録の流れ、機種変更、バイパスコードを発行するときの本人確認 |
| ログ | 誰が、いつ、どのアクセスで承認・拒否したか。SIEMに送るかどうか |
まとめ
ADにMFAを足すときに最初に考えるのは、製品の比較より先に「守りたい認証がどこを通るか」です。止める場所によって、追加する部品も、ADやクライアントで変わる設定も、守れる範囲も変わります。
| 守りたいもの | 止める場所 | 追加するもの |
|---|---|---|
| VPN、Wi-Fi、LDAPで認証する機器 | ① 認証プロキシ | 社内の認証プロキシ（VPN機器のRADIUSの宛先を変える） |
| PC・サーバへのサインイン、RDP、UACでの昇格 | ② ログオン画面 | 守る端末ごとのエージェント |
| PowerShellリモート、SSH（Windows） | ② の仲間 | リモート操作を受けるサーバごとのMFAの仕組み（③で止める方法もある） |
| ファイルサーバ、リモート管理（Kerberos／NTLM） | ③ DC | すべてのDCのモジュール（＋ポリシーサーバ） |
| Webアプリ、SaaS | ④ クラウドIdP | IdPとADの同期、またはAD FSのアダプタ |
この記事は、複数の製品の公開資料をもとに、ADにMFAを足すしくみを一般化したものです。記載した動き（部品の置き場所、MFAを求めるタイミング、対応プロトコル、障害時の既定の動作、番号照合の可否など）は、すべての製品に当てはまるものではありません。実際の構成や設定は、各メーカー・販売元のドキュメントや窓口で確認してください。
参考にした資料
この記事は、次の公開資料をもとにまとめました（2026年10月10日に確認）。製品の資料は、仕組みを一般化するための参考として使っています。
Microsoft（Windows・AD・Entra）
- Credentials processes in Windows authentication（Credential Provider、UAC、ローカルアカウント、キャッシュされた資格情報）
- Windows logon scenarios（ネットワークログオン）
- Maximum lifetime for user ticket（TGTの既定の有効期限）
- Windows Hello for Business authentication
- Smart card certificate requirements and enumeration（スマートカードとPKINIT）
- Network Policy Server (NPS)
- Integrate your existing NPS infrastructure with Microsoft Entra multifactor authentication（NPS拡張）
- Number matching in MFA push notifications（番号照合とNPS拡張）
- Configure Microsoft Entra Private Access for Active Directory domain controllers（DCのセンサー、監査モード）
- Tutorial: Configure Secure Hybrid Access with Microsoft Entra ID and Silverfort
Cisco Duo
- Duo Authentication Proxy Reference
- Duo Authentication Proxy for RADIUS
- Duo Authentication Proxy for LDAP
- Duo Authentication for Windows Logon & RDP（UACの昇格、オフライン時、対象外のログオン）
- Duo Windows Command Line Protection（PowerShellリモート、SSH）
- Duo Legacy AD Protection（DCでのKerberos／NTLMの保護）
- Synchronizing Users from Active Directory
- Duo for Microsoft AD FS
- Duo Administration – Managing Users（バイパスコード）
- Duo Authentication Methods Security Guide（番号を入力するプッシュ）
- Duo Guide: Enrollment（QRコードでの登録）
Silverfort
- Silverfort General 2-Pager（PDF）（認証をDCで確認した後に判断する流れ）
- Silverfort on Your Domain Controllers（PDF）（DCに置く部品、スキーマを変更しないこと）
- Silverfort for Active Directory（PDF）（導入の進め方）
その他
- Configuring Authentication with Active Directory（FreeRADIUS）（一般的なRADIUSサーバとADの連携）
コメント