MENU

Windows Server 2016でNAPは使えない？802.1X/NACで非ドメインPCを安全性チェックして隔離・修復する代替策

Windows Server

Windows Server 2016 のドメイン環境で、来訪者の非ドメインPCをLANに挿した瞬間に「安全性チェック→隔離→修復」まで実現したい──その発想でNAP（ネットワーク アクセス保護）を探すケースは多いものの、Server 2016 ではNAPを前提にした設計が成立しません。本記事では、同じ目的を“現行の仕組み”で実装する具体策を整理します。

目次

Windows Server 2016 で NAP（ネットワーク アクセス保護）を導入できない理由

まず前提として押さえておきたいのは、Windows Server 2016 環境では NAP を使って「端末の準拠状態（ウイルス対策や更新状況）を判定し、未準拠なら隔離ネットワークへ誘導し、修復後に本番へ通す」という構成を組めない点です。NAP は過去の Windows クライアント／サーバー時代の仕組みで、Server 2012 R2 以降は非推奨の位置づけとなり、Windows 10 世代ではクライアント側も前提にできません。

そのため、Windows Server 2016 の Active Directory（AD DS）を中核にした複数拠点環境で「非ドメインPCをLANで検疫したい」と考える場合は、NAPの“名前”を追うより、やりたいことを分解して代替の組み合わせを設計するのが近道です。

やりたいことを要素分解すると、代替策が選びやすくなる

外部作業者のPCにドメインユーザーを付与しつつ、端末はドメイン参加させない運用では、GPOや端末管理の効きが弱くなります。そこで「LANに挿した瞬間に検疫」の要件を、ネットワーク設計の観点で分解します。

やりたいことNAPでのイメージ現行の代表的な実現手段非ドメインPCでの現実度
接続してきた端末を識別するNAP対象端末か判定802.1X（有線/無線）、MAB、端末エージェント、台帳連携高（802.1Xが現実的）
“安全かどうか”を判定するSHAでAV/更新状況NAC製品のポスチャチェック（エージェント/エージェントレス）、MDM準拠判定中～高（NACやMDMが必要）
未準拠端末を隔離する隔離ネットワーク動的VLAN、ダウンロード可能ACL（dACL）、FWポリシー、ゲストVLAN高
修復させる修復サーバーへ到達修復VLANでWSUS/AV更新/ポータルのみ許可、踏み台（RDS/VDI）に誘導中（端末側の操作が必要になりがち）
準拠後に本番へ解放する再評価して解除再認証（reauth）でVLAN変更、CoA（Change of Authorization）、ポリシー更新高

ポイントは、「隔離」はネットワークで実現できても、「準拠判定」と「修復の強制」は端末を管理下に置けないと難しくなることです。つまり、外部作業者PCが“完全な野良端末”であるほど、ネットワークだけでNAPの再現を狙うと運用が破綻しやすくなります。

Windows Server 2016 環境で現実的な代替アプローチ

NAPの代替は大きく3系統に分かれます。求める厳格さ（ポスチャチェックの精度）と、導入コスト／運用負荷で選びます。

代替アプローチできること必要な主な要素向く要件
サードパーティ NAC（有線/無線）準拠チェック＋隔離＋修復＋解放を一連で実装しやすい802.1X対応スイッチ/無線、NACサーバー、ポスチャエージェント/ポータル、連携（AD/証明書/WSUS/AV）「LAN接続＝検疫」を本気でやりたい
802.1X＋動的VLAN（Windows NPS中心）未認証端末を隔離、認証端末だけ業務用へNetwork Policy Server（NPS）、（推奨）証明書基盤、802.1X対応機器“安全性チェック”は別手段で補える/割り切れる
ゲストVLAN＋踏み台（RDS/VDI/AVD等）外部PCを社内資源へ直アクセスさせないゲストネットワーク分離、踏み台サーバー、RD Gateway等、MFA/ログ外部作業者が多い、端末管理ができない
MDM/端末管理（Intune/ConfigMgr等）端末を管理下に置いて準拠状態を担保MDM登録、ポリシー、更新/AV管理、（必要なら）ネットワーク分離と併用BYODや会社貸与端末として管理できる

「非ドメインPCをLANでチェックして隔離して修復」という要求を実装レベルで満たしたいなら、現実的には次のどちらかに寄せると判断が速くなります。

  • 端末の状態まで判定したい：NAC製品（ポスチャ機能あり）＋802.1X＋修復VLAN
  • 端末を信用しない：ゲストVLANに隔離し、業務は踏み台（RDS/VDI）経由に固定

実装案：サードパーティ NAC で「安全性チェック＋隔離＋修復」を再現する

要件に最も近いのは、NAC（Network Access Control）製品でポスチャチェックを行い、ネットワーク側（スイッチ/無線）で隔離・解放を制御する方式です。ここでは製品名より、実装に必要な部品と通信の流れを中心に整理します。

典型構成（最小でも必要な役割）

役割配置の考え方主な機能冗長化の考え方
NAC ポリシーサーバー（管理/判定）センター拠点（データセンター）端末識別、ポスチャ判定、ポリシー配布、ログ集約2台以上でHA（構成同期）
RADIUS（802.1X 認証基盤）NAC内蔵またはWindows NPSユーザー/端末認証、VLAN/ACL指示、再認証拠点ごとに到達性を確保（冗長経路）
ポスチャチェック（エージェント/ポータル）端末側＋隔離VLAN側のWebAV有効/更新、OS更新、FW状態などの判定配布サーバー・ポータルの冗長化
隔離（修復）ネットワーク各拠点にVLANとして用意修復に必要な宛先だけ通す（出口制御）DHCP/DNSは拠点で冗長化が理想
修復用サーバーセンターまたは拠点WSUS、AV更新リポジトリ、エージェント配布、手順ポータル拠点WAN帯域に応じてキャッシュ/分散

ポスチャ（準拠）判定ルールを、先に文章で定義しておく

NAPの時代に比べ、今の端末はOSもAVも多様です。NACを入れるにしても、まずは「合格ライン」を文章で定義しないと、例外が増え続けます。

判定カテゴリ合格ラインの例実装の勘所
OSWindows 10/11 のサポート内ビルドのみ許可古いOSは修復ではなく“業務不可”に割り切ると安全
Windows Update「最新の品質更新」適用済み、再起動保留なし“適用済み”の定義（何日前まで許容するか）を決める
ウイルス対策リアルタイム保護が有効、定義が一定期間内に更新複数ベンダー混在なら「最低条件」を決め、細部は踏み台で吸収
ファイアウォール有効（少なくともパブリックプロファイル）無効端末は隔離に戻す、例外が必要ならRDS/VDIへ
暗号化BitLocker等のディスク暗号化が有効（必要な場合）外部作業者PCへ強制は難しいため、要件が強いなら端末貸与へ

通信フロー（有線LANの例）

  1. 外部作業者PCがスイッチポートへ接続（802.1X開始）。
  2. 認証に成功しても、初回は隔離VLAN（またはdACL）へ入れる（“未評価”扱い）。
  3. 隔離VLANからは、DNS/DHCPと、修復用ポータル/WSUS/AV更新など必要最小限のみ到達できる。
  4. ポータルやエージェントが端末の準拠状態（AV稼働・更新、Windows Update適用など）を判定。
  5. 準拠したら、再認証（reauth）やCoA（Change of Authorization）で業務VLANへ切替。
  6. 以後も一定間隔で再評価し、未準拠へ戻ったら隔離へ戻す。

隔離解除を“いつ/どうやって”反映するか（再認証設計）

隔離から本番へ切り替わるタイミングを曖昧にすると、利用者からは「直したのに通らない」「突然切れた」という不満になります。次の設計要素を決めておくと運用が安定します。

項目選択肢実務上のおすすめ
切替トリガー定期再認証 / 手動再認証 / CoA可能ならCoAで即時反映、難しければ短めの再認証周期
再認証周期数分～数時間外部作業者VLANは短め（例：15～30分）にして戻しやすくする
失敗時の挙動Fail-open（通す）/ Fail-closed（止める）外部端末は原則Fail-closed。ただし障害時の業務影響を想定して例外手順を用意
例外端末の扱い台帳登録/MAB/別SSIDプリンターや会議室機器は別ポリシーに分離し、外部作業者と混ぜない

隔離（修復）VLANで許可する通信の具体例

宛先目的例注意点
DHCPIP払い出しUDP 67/68隔離VLAN専用スコープを用意
DNS名前解決UDP/TCP 53内部DNSにするか、隔離用DNSを用意
NTP時刻同期UDP 123証明書/認証の失敗回避
修復ポータル（IIS等）手順表示、エージェント配布TCP 80/443HTTPSを推奨、端末識別の導線に
WSUS または Microsoft UpdateWindows Update修復WSUS: TCP 8530/8531、MU: 443非ドメインPCはWSUS設定が入っていないことが多い
AV更新（McAfee/Defender等）定義ファイル更新製品/設計により異なるプロキシやミラーサーバーを隔離側に置くと安定
証明書失効確認（CRL/OCSP）EAP-TLS等の証明書検証HTTP/LDAPなど閉域化しすぎると認証が失敗する

隔離VLANをインターネットに出す場合の“出口”の作り方

修復のためにインターネットを許可するなら、「許可しすぎない」ことが最重要です。典型的には、隔離VLANの出口はプロキシまたはFWで制御し、HTTP/HTTPSの宛先カテゴリを更新サイト寄りに絞ります。

  • 更新系（Microsoft Update、AVベンダー）以外は基本ブロック
  • DNSは隔離側で制御（外部DNS直指定を避ける）
  • 踏み台や社内サーバー宛ては完全遮断（誤設定で穴が空きやすい）

実装案：802.1X＋動的VLAN（Windows NPS）で“未認証端末”を隔離する

「端末のAV/更新状況までネットワークで判定する」のが難しい場合でも、802.1X を導入して、少なくとも“未認証・不明端末を業務ネットワークへ入れない”ところまでは Windows Server 2016 の標準機能（NPS）を中心に実装できます。

ただしこれはポスチャチェック（安全性チェック）そのものではなく、接続制御と分離です。安全性チェックは、後述の「踏み台方式」や「端末管理（MDM）」などで補完するのが現実的です。

NPS（RADIUS）を使うのはVPNのためだけではない

「RADIUSはVPN用で、今回はリモートアクセスをやりたいわけではない」という声はよくあります。しかし802.1Xの世界では、有線/無線LANの認証でもRADIUS（NPS）が一般的です。目的はVPNではなく、「LANの入口で誰かを確認し、入れるネットワークを変える」ことです。

必要なサーバー役割と配置（例）

役割推奨台数配置補足
AD DS（既存）既存センター＋支店にDCがあると安定NPSの認証バックエンド
NPS（Network Policy Server）最低2台センター拠点（冗長）拠点WANが不安なら支店にも配置
証明書基盤（AD CS推奨）要件次第センター拠点EAP-TLSを採る場合はほぼ必須
DHCP/DNS拠点規模次第各拠点隔離VLAN用スコープも設計

非ドメインPCで選びやすい認証方式

方式概要メリットデメリット/注意
PEAP（ユーザー名/パスワード）ADのユーザー資格情報で認証外部作業者にドメインユーザーを付与する運用と相性が良い端末が管理外だと設定ばらつき、資格情報漏えい対策が重要
EAP-TLS（証明書）端末証明書で認証強固、パスワード依存を減らせる非ドメイン端末への証明書配布/失効管理が運用課題

外部作業者が頻繁に入れ替わる環境では、PEAPで運用しつつ、業務ネットワークへの権限を極小化し、実アクセスは踏み台へ寄せる設計がトラブルを減らします。EAP-TLSを採る場合は、証明書配布の仕組み（MDM、端末配布時の手順、失効の徹底）がないと破綻しやすいです。

動的VLAN設計の考え方（例）

VLAN/セグメント対象許可する主な通信狙い
隔離VLAN未認証/失敗/不明端末修復ポータル、更新系、最低限のDNS/DHCP“まず止める”
外部作業者VLAN認証成功した外部作業者踏み台（RD Gateway等）へのみ社内資源への直アクセスをさせない
社内端末VLAN社内管理端末通常業務従来通り

この設計にすると、NAPのような“端末の健康状態判定”がなくても、少なくとも「認証していない端末がSMB/RDPで社内へ触る」事故を防止できます。外部作業者PCに対しては「踏み台経由のみ許可」にしておくと、ネットワーク側で強制しやすくなります。

実装案：外部作業者はゲストVLANに入れて、業務は踏み台経由に限定する

「非ドメインPC」「来訪者が多い」「拠点が複数」という条件では、最も運用が安定しやすいのは外部PCを社内資源へ直アクセスさせない方式です。端末のAVや更新状況を完璧に判定できなくても、攻撃面を狭められます。

踏み台方式が強い理由

  • 社内資源（SMB/RDP等）へ接続する端末が、社内で管理できる踏み台サーバー/VDIに限定される。
  • 外部PCはゲストVLANに隔離したままでも業務が回るため、“準拠判定”の難しさを設計で回避できる。
  • ログ（誰がいつ何にアクセスしたか）を、踏み台側で集約しやすい。

最小構成の例（RDSを使うケース）

要素役割配置の目安ポイント
ゲストVLAN外部PCの収容各拠点社内LANとL3で分離、ACL/FWで絞る
RD Gateway（推奨）外部PCからの入口（HTTPS）センター拠点（冗長）3389直開放を避け、443に集約
RDS セッションホスト or VDI実作業環境センター拠点パッチ/AV/設定を社内で統制
ファイルサーバー/業務サーバー社内資源既存アクセス元を踏み台に限定（FW）

ネットワーク許可ルールの例

通信元通信先許可プロトコル意図
ゲストVLANRD GatewayTCP 443業務経路を一本化
ゲストVLANインターネット必要最小限（HTTP/HTTPS、更新用途）隔離を維持しつつ最低限の利便性
ゲストVLAN社内サーバー群原則禁止SMB/RDP直アクセスを遮断
踏み台（RDS/VDI）社内サーバー群必要なものだけ“管理下端末だけが触れる”状態を作る

踏み台方式を採る場合、外部作業者のADユーザーは権限を最小化した専用OU/グループにまとめ、ファイル共有も「専用共有＋専用アクセス制御」に寄せると事故が減ります。RDPはRD Gateway＋NLA、可能ならMFA、踏み台へのクリップボード/ドライブリダイレクト制御なども併せて検討します。

“修復”を成立させるための具体策（WSUS / McAfee ePO を活かす）

隔離して終わりではなく「修復させて本番へ通す」をやりたい場合、修復導線を具体化しておく必要があります。ここでは、よくある詰まりどころと実装の落としどころをまとめます。

非ドメインPCにWSUSを使わせる現実的な方法

非ドメインPCはGPOが効かないため、WSUS利用を強制しづらいのが実情です。次のいずれかに寄せます。

  • 隔離VLANはインターネットへ出して Microsoft Update を許可し、端末側でWindows Updateを実行してもらう（ネットワークで出口制御しやすい）。
  • 隔離ポータルで「WSUS設定を投入するスクリプト」を配布し、管理者権限で実行してもらう（より統制したい場合）。

WSUS設定を投入する例（環境に合わせてサーバー名は置き換え）。

reg add "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate" /v WUServer /t REG_SZ /d "http://wsus.example.local:8530" /f
reg add "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate" /v WUStatusServer /t REG_SZ /d "http://wsus.example.local:8530" /f
reg add "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU" /v UseWUServer /t REG_DWORD /d 1 /f

net stop wuauserv
net start wuauserv

隔離ポータルで配布できる“簡易セルフチェック”例

外部作業者PCは環境差が大きいため、完璧な自動判定は難しいものの、ポータルで「自分の端末状態を表示できる」だけでも問い合わせが減ります。PowerShellが使える前提なら、次のような表示スクリプトを用意できます。

# インストールされているAV（Windows Security Center）を表示
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct |
  Select-Object displayName, productState, timestamp

# Windows Defender の状態（Defender利用時）

Get-MpComputerStatus |
Select-Object AMServiceEnabled, AntivirusEnabled, AntivirusSignatureLastUpdated, QuickScanEndTime

productState の解釈はベンダーや環境で異なることがあるため、運用上は「表示結果のスクリーンショット提出」などに寄せ、最終判定はNACのポスチャ機能または踏み台方式で担保する方が安全です。

McAfee ePO を“修復”に使うときの注意

  • 外部PCへエージェント導入が可能か（契約・セキュリティポリシー）を最初に整理します。導入NGなら、ePOでの準拠判定はできません。
  • 導入OKの場合は、隔離VLANからエージェント配布サイト（IIS等）へ誘導し、必要な通信（ePOサーバー/Agent Handler/リポジトリ）だけ許可します。
  • 隔離VLANの端末は“社内ネットワークの一員ではない”前提で、ePO側の権限・タグ・ポリシーを分離します（外部端末用のポリシーを作る）。

隔離ポータルに載せると便利なチェック項目

「修復が終わったか」を利用者自身に判断させると、結局“抜け”が出ます。隔離ポータルには、最低でも次のチェックを載せると運用が回りやすくなります。

チェック利用者に求める操作補足
OSがサポート範囲かOSバージョン確認古いOSは隔離解除しない割り切りも必要
Windows Updateが最新か更新実行→再起動更新が複数回必要なケースを想定
ウイルス対策が有効/更新済みか定義更新→クイックスキャン製品が混在するなら“最低条件”を定義
FWが有効か有効化業務要件で例外が必要なら踏み台側で吸収

可能であれば、NAC製品のポスチャ機能やMDM準拠判定を使って「条件を満たさない限り解除されない」仕組みに寄せます。そこまでできない場合でも、隔離ポータル＋踏み台方式の組み合わせで、リスクを現実的に下げられます。

複数拠点（支店＋センター）での配置パターン

拠点が複数あると、認証や修復の通信がWANに集中しがちです。典型パターンを比較します。

パターン概要メリットデメリット
集中型（センターにNPS/NAC/WSUSを集約）全拠点がセンターへ問い合わせ運用が一元化、ルールが統一しやすいWAN障害/遅延に弱い、更新トラフィックが集中
分散型（支店にも認証/修復を配置）支店にNPSや更新キャッシュを置く拠点の自立性が高い、体感が良いサーバー台数と運用負荷が増える
ハイブリッド（認証は分散、ポリシーは集中）支店にRADIUSプロキシ/ローカルノード運用と性能のバランスが取りやすい構成が複雑になりがち

外部作業者が支店にも頻繁に来るなら、少なくとも隔離VLANのDHCP/DNSは支店側で完結させ、更新系は「支店キャッシュ（更新キャッシュ/プロキシ）」を用意すると、WAN圧迫を抑えられます。WSUSを使う場合は、ダウンストリームWSUSや更新キャッシュ（BranchCache等）の検討余地もあります。

非ドメインPCに社内資源を触らせる前に、最低限入れておきたい対策

NAPの代替を検討している背景には、「未更新PCが社内に入るのが怖い」というセキュリティ要件があります。検疫の仕組みに加えて、入口と出口を締めておくと効果が上がります。

  • SMBは“踏み台からのみ”アクセス可能にする（ファイルサーバー側FW/ACLでクライアントセグメントを制限）。
  • RDPはRD Gateway経由に統一し、端末→サーバー直通の3389を極力消す。
  • 外部作業者アカウントは専用OU＋期限付き（運用ルール化）にし、退職/終了時の棚卸しを自動化する。
  • ログを一箇所に集める（NPSログ、NACログ、スイッチの認証ログ、FWログ）。「誰がいつどのポートに挿したか」が追えると、事故対応が速くなります。

導入を成功させる進め方（段階的に固める）

いきなり全拠点・全ポートで802.1Xや隔離を有効にすると、現場が止まるリスクがあります。段階的に進めるのが安全です。

フェーズやること成果物落とし穴
現状把握外部PCが使う業務、必要な通信、拠点WAN帯域、機器の802.1X対応を棚卸し要件表、通信一覧「必要」だと思い込んでいる通信が多い
分離の設計ゲスト/隔離/外部作業者/社内のVLANとFWルールを設計ネットワーク設計書隔離VLANの“許可先”が広がりすぎる
小規模パイロット1拠点・一部ポートで試験（監視→強制へ）手順、例外ルールプリンター/会議室機器など非802.1X端末の扱い
修復導線の整備隔離ポータル、更新/AV修復、踏み台環境を整備修復手順、FAQ非ドメインPCは管理者権限がないと修復できない
全社展開拠点展開、ログ監視、運用ルール（アカウント期限、例外申請）運用手順書例外が増えすぎて形骸化

まとめ：NAPの代わりに「ネットワーク分離」か「踏み台」を軸に設計する

Windows Server 2016 では NAP を前提とした“安全性チェック＋隔離＋修復”は組めません。代わりに、

  • 厳格にやるならサードパーティNAC＋802.1Xでポスチャ判定まで含めて実装する
  • 標準機能中心なら802.1X＋動的VLAN（NPS）で未認証端末を隔離し、業務経路は踏み台に寄せる
  • 端末管理ができないならゲストVLAN＋踏み台（RDS/VDI）で社内資源への直アクセスを断つ

という選択が現実的です。特に「非ドメインPC」「来訪者が多い」「拠点が複数」という条件では、端末を信頼しない前提で“通し方”を設計することが、結果として安全かつ運用可能な落としどころになります。

Windows Server
wsus NAC Windows Server 2016 NPS 802.1x NAP

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次