Windows Server 2016 の NPS（Network Policy Server）で、NAP（ヘルスポリシー）を使って「更新状況やウイルス対策の状態に応じて接続可否を変える」端末検疫をやりたい、という相談は今でも見かけます。ですが結論として、Server 2016 以降では NAP が提供されないため、当時の仕組みをそのまま再現することはできません。代替の現実解を含めて整理します。
結論：Windows Server 2016 の NPS で「NAP のヘルスポリシー運用」はできない
先に結論を明確にすると、Windows Server 2016 以降の NPS では、NAP（Network Access Protection）を使った健康状態チェック（検疫）を運用できません。理由はシンプルで、NAP（および HRA/HCAP などの NAP 関連機能）は Windows Server 2012 R2 の時点で非推奨（deprecated）となり、Windows Server 2016 以降では提供されないためです。
よって、Windows Server 2016 の NPS 上で「ヘルスポリシー」を作って、端末のパッチ適用や AV 状態を評価し、条件分岐して隔離 VLAN に入れる、といった “古典的な NAP 運用” は実装できません。NAP の前提となるコンポーネント自体がサーバー側にありません。
参考：NPS の概要（NAP が非推奨／提供されない旨の整理を含む）
Network Policy Server (NPS) overview | Microsoft Learn
「EAP-TLS は NAP 拡張をサポートしない」と言われる理由
質問でよく出てくるのが「EAP-TLS 認証は NAP 拡張をサポートしない（= 端末の健康状態情報を EAP 経由で渡せない）」という情報です。ここは少しややこしいのですが、ポイントは次の通りです。
- NPS は 802.1X/EAP による認証（誰が繋いだか）を扱う役割が中心です。
- NAP は “認証に加えて” 健康状態（SoH：Statement of Health）を評価し、隔離や修復（Remediation）まで行う仕組みです。
- EAP の方式（EAP-TLS / PEAP など）によって、NAP の健康情報（NAP 拡張）を絡めた運用が難しい／できないケースがあり、「EAP-TLS では NAP ができない」という話だけが独り歩きしがちです。
ただし、これを突き詰めても最終的な結論は変わりません。Server 2016 では NAP 自体が提供されないため、EAP-TLS と NAP 拡張の相性問題を解決しても NAP を動かす土台がありません。質問の論点は「EAP の方式」よりも「NAP が製品として終わっているか」が本質です。
参考：EAP-TLS と NAP 拡張に関する Q&A
EAP-TLS and NAP extension – Microsoft Q&A
ヘルスポリシーの対象 OS が Windows 8 系しか出ないのは仕様か？
これも結論は「仕様として自然」です。NAP のクライアント側プラットフォームは、Windows 10 以降で利用できません。そのため、ヘルスポリシーの対象 OS が古い世代（Windows 8/8.1 など）に寄って見える挙動は、NAP の設計・サポート状況と一致します。
「Windows Server 2016 側で頑張れば Windows 10/11 の健康状態チェックができるのでは？」と考えがちですが、クライアントに NAP という機構が存在しないため成立しません。
参考：NAP のスタートページ（Win32）
Network Access Protection – Win32 apps | Microsoft Learn
NPS は今も使える：できること／できないことを切り分ける
NAP が使えない＝NPS が終わった、ではありません。ここを誤解すると、設計を一気に作り直すことになります。NPS は引き続き RADIUS/802.1X/VPN 認証基盤として利用可能で、終わったのは NAP の「健康状態チェック＋隔離＋修復」という領域です。
| 項目 | Windows Server 2016 の NPS で可能 | NAP を使わないと難しい（= Server 2016 単体では不可） |
|---|---|---|
| 802.1X 認証（有線/無線） | 〇（EAP-TLS/PEAP など） | — |
| VPN 認証（RRAS と連携） | 〇 | — |
| ユーザー/端末（コンピューター）証明書で「管理端末のみ許可」 | 〇（EAP-TLS＋証明書配布） | — |
| AD グループ条件でのアクセス制御 | 〇 | — |
| 動的 VLAN 割り当て（RADIUS 属性） | 〇（NW 機器側対応が前提） | — |
| 端末のパッチ適用状況・AV 状態を評価して接続可否を変える | △（NPS 単体では評価不可） | 〇（従来は NAP が担った領域） |
| 非準拠端末を隔離し、修復サーバーへ誘導して自動復旧 | × | 〇（典型的な NAP の世界） |
つまり、NPS には「認証・認可（誰を通すか）」を任せ、健康状態の判定は別の仕組みへ分離するのが、Server 2016 以降の現実的な設計です。
代替案の方向性：NAP の代わりに何を使うべきか
端末の健康状態チェック（コンプライアンス）を前提にしたアクセス制御をやりたい場合、よく採用される選択肢は大きく 3 つです。要件（対象が有線か無線か、VPN か、社内かクラウドか、BYOD を許可するか）で最適解が変わります。
| 代替案 | 得意なこと | 苦手なこと/注意点 | 向くシーン |
|---|---|---|---|
| MDM（Intune など）＋証明書配布＋802.1X（EAP-TLS） | “管理端末だけ通す” を堅牢に実現。Wi-Fi/有線プロファイルと証明書を一元配布できる。 | NPS 自体は MDM の準拠判定を直接参照しないため、設計で工夫が必要。 | Windows 10/11 の社給端末中心、ゼロトラスト寄りに寄せたい |
| SCCM（ConfigMgr）や Defender for Endpoint を軸にした運用 | 更新・AV・脆弱性・準拠の可視化と是正が強い。運用ノウハウが多い。 | ネットワーク接続の瞬間に “健康状態を見て通す/通さない” をやるには別の仕組みが要る。 | 端末管理を強化し、結果として安全性を上げたい |
| NAC 製品（Cisco ISE / Aruba ClearPass 等） | ポスチャチェック、隔離、修復誘導、ゲスト/BYOD、動的 ACL など “NAP がやっていた世界” を現代的に実装。 | ライセンス費用・設計/運用の難易度が上がる。ネットワーク機器との相性が出る。 | 厳格な端末検疫が必須、BYOD/ゲストも制御したい |
質問にあった「Intune や System Center Configuration Manager が代替」という方向性はまさにこの整理で、Microsoft 側も NAP を置き換える流れとして MDM や端末管理製品へのシフトが前提になっています。
おすすめ設計：NPS は 802.1X の中核に据え、健康状態は “証明書と準拠” で間接的に担保する
「NPS を使い続けたい」「802.1X/EAP-TLS を採用したい」「Windows 10/11 を前提にしたい」という条件なら、実務上もっとも採用されやすいのは次の考え方です。
“健康状態を NPS が判定する” 発想を捨てて、健康な端末だけが証明書を持てる（＝EAP-TLS に合格できる）状態を作るというアプローチです。
考え方の要点
- NPS は EAP-TLS で証明書を検証し、接続の入口を守る（管理端末だけ通す）。
- 端末が「準拠」していることを MDM（Intune 等）で定義・監視・是正する（更新・暗号化・Defender・パスコードなど）。
- 準拠していない端末は、証明書の配布/更新を止める、あるいは 別ネットワーク（ゲスト/隔離）に誘導する。
これにより、NAP のように接続の瞬間に SoH を評価して修復まで回す “完全な検疫” とは違いますが、現代の端末管理の前提（MDM/EDR）と整合し、運用の現実性が高い構成になります。
具体例：Windows Server 2016 NPS＋EAP-TLS で「社内端末のみ接続」を実現する手順イメージ
ここでは「まずは NAP の置き換えとして、未管理端末を社内 LAN/Wi-Fi から排除する」最小構成を具体化します。健康状態チェックそのものは MDM/EDR の領域に寄せ、ネットワーク側は “管理端末のみ通す” を徹底します。
構成要素（最小）
| 要素 | 役割 | ポイント |
|---|---|---|
| NPS（Windows Server 2016） | RADIUS（認証・認可） | 802.1X の認証基盤。EAP-TLS を推奨。 |
| 証明書基盤（AD CS / Intune 証明書配布 など） | 端末/ユーザー証明書の発行 | “証明書を持つ＝管理下” の状態を作る。 |
| ネットワーク機器（スイッチ/AP/無線コントローラ） | 802.1X の実施、VLAN/ACL 制御 | RADIUS 属性（VLAN など）に対応していると柔軟。 |
| 端末管理（Intune / SCCM / EDR） | 準拠ルールと是正 | 更新・暗号化・Defender 等を統制する本体。 |
実装チェックリスト
- 802.1X の方式を決める（推奨：EAP-TLS）
- 「ユーザー認証」か「端末認証」か、または併用（ユーザー＋端末）を決める
- 証明書の配布方法（AD CS 自動登録 / Intune の SCEP/PKCS 等）を決める
- NPS のネットワークポリシーを設計する（許可/拒否、条件、順序）
- 未認証端末の扱い（ゲスト VLAN、隔離 VLAN、完全遮断）を決める
- ログ設計（NPS ログ、RADIUS、スイッチ/AP 側ログ）を決める
“隔離 VLAN” を作るなら：RADIUS 属性での VLAN 割り当て例
NAP の「修復ネットワーク」に近い運用をしたい場合、ネットワーク機器が対応していれば、NPS から VLAN を返して端末を振り分けることができます（ベンダーにより設定名は異なります）。
| 振り分け先 | 端末の条件（例） | NPS 側の考え方 | ネットワーク側の意図 |
|---|---|---|---|
| 社内 VLAN | 証明書が有効、認証成功 | 通常の許可ポリシー | 通常アクセス |
| ゲスト VLAN | 認証不能、未管理端末 | 拒否せずゲストへ（可能なら） | インターネットのみ |
| 隔離 VLAN | 条件を満たさない管理端末（例：証明書期限切れ等） | 特定条件で隔離へ | 更新/登録サイトのみ |
重要なのは、隔離 VLAN に入れる条件が “健康状態” ではなく “認証条件” になりやすい点です。NAP のような「AV が最新ではないから隔離」という判定を NPS 単体で行うことはできません。隔離の入口条件をどう作るか（証明書の配布/更新、端末登録、準拠判定）を MDM/運用設計側で固めるのがポイントです。
健康状態チェックを “本当に” ネットワーク接続の瞬間にやりたい場合
要件として「パッチ未適用や EDR 未導入の端末は、社内ネットワークに一切入れたくない」「接続の瞬間に検疫し、直すまで隔離したい」という場合、NPS＋MDM だけで NAP 相当を完全再現するのは難しくなります。そうした要件は、いわゆる NAC（Network Access Control） の領域です。
NAC 製品は、802.1X や証明書認証を入口にしながら、端末の状態（エージェント、EDR、OS バージョン、暗号化、脆弱性情報など）を統合し、動的 ACL や VLAN で制御する設計が主流です。導入コストは上がりますが、「NAP でやりたかったこと」に最も近い到達点になりやすいです。
「古い OS が残っているから NAP を延命したい」はおすすめできるか
現場では、Windows 8.1 などの古い端末が残っていて「対象 OS が出るなら NAP を使えるのでは？」という発想になりがちです。しかし、NAP は Windows Server 2012 R2 時点で非推奨とされ、以降の世代では提供されません。さらに、古い OS を検疫のために残す判断は、セキュリティ上のリスクと保守コストが大きくなりがちです。
端末の健康状態を理由に NAP を復活させるよりも、端末を Windows 10/11 に寄せ、MDM/EDR を前提にゼロトラスト寄りの統制へ移行する方が、長期的には安定します。
参考：Windows Server 2012 R2 の Network Policy and Access Services 概要（NAP の位置付けを含む）
Network Policy and Access Services Overview | Microsoft Learn
よくある誤解と、設計時の落とし穴
「NPS の画面にヘルスポリシーがある＝使える」は誤解になりやすい
管理ツールの表示や過去情報が残っていると「設定できそう」に見えますが、実際に機能が提供されるか（役割サービスが存在するか、クライアントが対応するか）が重要です。NAP はこの前提が崩れているため、画面上の期待と実装可能性が一致しません。
「EAP-TLS で健康状態を見たい」は “入口の認証” と “状態評価” を分離すると整理しやすい
EAP-TLS は強力な認証手段ですが、基本は「証明書を持つ端末/ユーザーかどうか」を検証するものです。健康状態（更新済み、AV 正常など）は別系統で評価し、その結果を証明書運用やアクセス権へ反映する設計が現実的です。
“隔離ネットワーク” を作るなら、更新・登録に必要な通信だけを通す
隔離 VLAN を作っても、そこから社内に自由に出られるなら意味がありません。最低でも次を満たすと運用が破綻しにくくなります。
- 隔離 VLAN から社内宛の通信は原則遮断（必要最小限だけ許可）
- MDM 登録、証明書取得、Windows Update、EDR 更新などに必要な宛先のみ許可
- 社内ポータル（手順書）や問い合わせ窓口だけ許可して自己解決を促す
まとめ：Windows Server 2016 で NAP を探すより、NPS＋端末管理で “今の正解” を作る
Windows Server 2016 の NPS で NAP（ヘルスポリシー）を使って端末の健康状態チェックを行う、という設計は、製品のライフサイクル上成立しません。ですが、NPS 自体は今でも 802.1X/VPN の中核として有効です。
これから設計するなら、次の分担にすると失敗しにくいです。
- NPS：認証・認可（誰を通すか、どこへ入れるか）
- MDM/SCCM/EDR：健康状態（準拠）を定義し、是正し続ける
- ネットワーク機器：VLAN/ACL でセグメントを分け、被害範囲を限定する
NAP を前提にした発想をいったんリセットし、Windows 10/11 を中心に “管理下の端末だけが証明書で通れる” 仕組みへ寄せていくのが、Windows Server 2016 時代の現実的な落としどころです。
コメント