Windows Server 2016 の NPS（Network Policy Server）で「Idle Timeout」と「Session Timeout」を設定しても、期待どおりに切断されなかったり、逆に作業中に切れてしまったりすることがあります。両者は似ていますが、切断の“条件”と“目的”がまったく別物です。本記事では違いをRADIUS属性レベルで整理し、「60」設定時の挙動、機器依存ポイント、現場での使い分けまで具体的に解説します。
結論：Idle Timeoutは「無通信が続いたら切断」、Session Timeoutは「最大利用時間で切断」
NPS のネットワークポリシー（Constraints/制約）にある 2 つのタイムアウトは、ざっくり言うと次の違いです。
| 項目 | 何を見て切る？ | 切断されるタイミング | 主な目的 | 短くしすぎた場合の典型トラブル |
|---|---|---|---|---|
| Idle Timeout（アイドル／無通信タイムアウト） | 通信が「無い」状態が連続した時間 | 一定時間“通信が無い”と切断 | 放置セッションの掃除、IP・セッション枠など資源の回収 | 席を外しただけで切れる、スマホの省電力で“無通信扱い”になりやすい等 |
| Session Timeout（セッションタイムアウト） | セッション開始からの経過時間（絶対時間） | 通信中でも上限到達で切断 | 最大接続時間の制限、一定周期の再認証・再評価 | 作業中の強制切断、オンライン会議・リモート作業が途切れる等 |
ポイントは「Idle Timeout は“無操作”ではなく“無通信”」ということです。ユーザーが触っていなくてもバックグラウンド通信があれば Idle と判定されない場合がありますし、逆にユーザーが触っていても（アプリが通信しない状態なら）Idle と見なされる場合もあります。
RADIUS属性としての定義を押さえる（NPSは“値を返す側”）
NPS の「制約」設定は、RADIUS の標準属性（Standard RADIUS Attributes）として NAS（VPN サーバー、無線 LAN コントローラ、スイッチなどの RADIUS クライアント）へ返されます。つまり NPS は通信を中継してタイマーを監視する装置ではなく、Access-Accept などの応答で「この接続は最大◯秒」「無通信が◯秒続いたら切ってよい」という“ルール（属性値）”を渡す立場です。
RFC 2865（RADIUS の基本仕様）では次のように定義されています。
| RADIUS属性名 | 属性番号 | 意味 | 単位 | 誰が切断する？ |
|---|---|---|---|---|
| Session-Timeout | 27 | ユーザーに提供するサービス（接続）の最大継続時間 | 秒 | NAS（RADIUSクライアント）が切断 |
| Idle-Timeout | 28 | 無通信（アイドル）が連続して許容される最大時間 | 秒 | NAS（RADIUSクライアント）が切断 |
RFC では、Session-Timeout は「このユーザーが NAS 上で接続し続けてよい最大秒数」、Idle-Timeout は「無通信が連続して許容される最大秒数」として定義され、いずれも NAS 側で切断に利用される想定です。
ここで大事なのは、NAS（VPN装置/無線コントローラ/スイッチ等）がその属性を“尊重するかどうか”は機器実装・設定次第という点です。たとえば機器側に「RADIUS の Session-Timeout をローカル設定より優先する」ようなオプションがあり、無効だと NPS 側で設定しても効かないことがあります。
「60」に設定すると何が起きるか（単位のズレで混乱しやすい）
RADIUS 属性（RFC）の値は秒です。一方、NPS の管理画面では入力欄の近くに単位が表示され、環境や対象のウィザードによって「分」表記で設定するケースがあります。まずは NPS 画面に表示されている単位で解釈してください。そのうえで「実際に NAS に返っている値（秒）」をログやパケットで確認すると、誤設定を最短で潰せます。
パターン別：60 を入れたときのイメージ
| 設定 | 管理画面の単位が「秒」だった場合 | 管理画面の単位が「分」だった場合 | 体感として起きること |
|---|---|---|---|
| Idle Timeout = 60 | 無通信が 60 秒連続で続くと切断 | 無通信が 60 分連続で続くと切断（RADIUS では 3600 秒相当） | キープアライブやバックグラウンド通信があると切れないことがある |
| Session Timeout = 60 | 接続開始から 60 秒で切断（通信中でも切れる） | 接続開始から 60 分で切断（RADIUS では 3600 秒相当） | 短いと「作業中に突然切れる」現象になりやすい |
特に無線 LAN やゲスト Wi-Fi などで、Idle Timeout が「思ったより切れない」のはよくある現象です。理由は単純で、「無通信」の判定がベンダー実装に依存するためです。たとえば Cisco Meraki のドキュメントでは、Idle-Timeout は秒で解釈され、さらにRADIUS アカウンティングが有効でないと Idle-Timeout が無視されると明記されています。
両方を設定した場合：先に条件を満たしたほうで切断される
Idle Timeout と Session Timeout の両方を設定した場合、基本はシンプルで先に条件を満たした方のタイミングで切断されます。
- 通信が続いている場合：Idle は満たしにくいため、Session の上限で切れることが多い
- 放置されて通信が途切れている場合：Session 上限より前に Idle で切れることが多い
仕様上、Session-Timeout も Idle-Timeout も NAS が切断判断に用いる値（秒）です。したがって「どちらが優先」というより「どちらが先に到達するか」で決まります。
重要：切断するのは NPS ではなく RADIUS クライアント（NAS）
ここが一番の誤解ポイントです。NPS は RADIUS サーバーであり、VPN サーバーや無線 AP/コントローラ、802.1X スイッチなどのネットワークアクセス機器（NAS）が RADIUS クライアントとして NPS に問い合わせます。NPS 自体がトラフィックを流しているわけではありません。
つまり、NPS の制約に値を入れても「NAS がその属性を受け取って、タイマーとして採用する」構成になっていなければ期待どおりの挙動になりません。現場でハマりやすいのは次のパターンです。
- 機器側が Session-Timeout / Idle-Timeout を無視する仕様（ローカル固定タイマーしか使わない）
- 機器側に “RADIUS のタイムアウトを優先する” 設定があるが無効
- Idle 判定が「通信量」「方向」「アカウンティング間隔」に依存していて想定とズレる
- 再認証（re-auth）に Session-Timeout が使われる機器で、意図せず頻繁に再認証が走る
「効いている/効いていない」を最短で判断する方法（ログとパケット）
おすすめは「NPS が返した値」をまず確認することです。NPS 側のアカウンティングログは、既定で %SYSTEMROOT%\System32\Logfiles\ 配下に保存され、列の中に Session-Timeout / Idle-Timeout が含まれます。ここで値が出ていれば、少なくとも NPS が属性を返すところまでは成功しています。
- NPS ログに値が出ているのに NAS が切らない → 機器側が無視/未対応/上書き設定が原因の可能性が高い
- NPS ログに値が出ていない → そもそも該当ネットワークポリシーがマッチしていない、制約が未適用、別ポリシーに負けている可能性が高い
さらに確実に見るなら、NAS と NPS 間をパケットキャプチャして Access-Accept に属性 27/28 が載っているか確認します（Wireshark なら “RADIUS” で追えます）。「60（分）のはずが 60（秒）として返っていた」など、単位の取り違えもここで発見できます。
ベストプラクティス：どちらを使うべきか（目的別に決める）
“正解の値”は環境で変わりますが、設計としては次の順で考えると失敗が減ります。
まずは目的をはっきり分ける
- Idle Timeout：放置接続を切って資源を回収したい（IP枯渇、同時接続数制限、ゲスト回転、セキュリティ）
- Session Timeout：最大利用時間を制限したい／一定周期で再認証させたい（規程、セキュリティ要件、運用ルール）
現場で使いやすい“目安”例（まずは長め→徐々に詰める）
以下は「よくある目的」に対して、業務影響とセキュリティのバランスを取りやすい設定例です。まずは長めにして、問い合わせが出ない範囲で段階的に調整するのが安全です。
| 利用シーン | Idle Timeout の考え方 | Session Timeout の考え方 | 注意点 |
|---|---|---|---|
| 社内 Wi-Fi（802.1X） | 短すぎるとモバイル端末が切れやすい。まずは長め（または未設定）から検討。 | 「1日1回」など長めの上限で強制更新したいときに使う。 | 機器によって Session-Timeout が「再認証周期」になることがある。 |
| ゲスト Wi-Fi（サインオン／キャプティブポータル） | 放置回線を早めに回収しやすい。混雑やIP枯渇対策として有効。 | 「滞在時間の上限」や「再ログイン」要件があるなら設定価値が高い。 | ベンダーによって Idle-Timeout がアカウンティング必須で無視される場合がある。 |
| VPN（RRAS / IKEv2 / SSTP など） | アイドル回線を切りたいなら有効。まずは業務に支障が出にくい時間から。 | シフト・勤務時間に合わせて最大利用時間を決めると揉めにくい。 | OS/クライアントの keepalive が Idle 判定に影響することがある。 |
| ネットワーク機器の管理ログイン（RADIUS） | 短めにしやすい（放置管理セッションはリスク）。 | 長時間ログインを許さない規程がある場合に有効。 | そもそも機器側が RADIUS の Idle/Session を採用しないこともある。 |
“運用で詰む”設定を避けるコツ
- Session Timeout を短くしすぎない：作業中に切れるとクレームが最速で来ます。最初は「長め」にして、必要なら段階的に短くします。
- Idle Timeout は「無通信」を前提にする：人の操作ではなく通信量で判定されます。スマホ/PC のバックグラウンド通信、VPN の keepalive、装置の実装差を織り込んで設計します。
- “誰が切るか”を設計に入れる：NPS 側で値を返しても、NAS が採用しなければ意味がありません。導入前に 1 台で良いので検証します。
トラブルシューティング：期待どおりに切れない／すぐ切れる
Idle Timeout が効かないときに見るポイント
- NAS が Idle-Timeout 属性（28）を採用しているか：機器の設定や仕様を確認（“RADIUS timeout override” など）。
- RADIUS アカウンティングが必要な機器か：Meraki の例では、アカウンティングが無効だと Idle-Timeout が無視されるとされています。
- “無通信”の定義が想定と違う：送信だけでリセットされるのか、受信も含むのか、一定以上のトラフィック量が必要なのかは装置によります。
- バックグラウンド通信が発生している：OS の更新確認、DNS、NTP、クラウド同期、VPN keepalive などが「無通信ではない」状態を作ることがあります。
Session Timeout で作業中に切れるときに見るポイント
- Session Timeout が短すぎる：まずは値を伸ばして影響範囲を切り分けます。
- 再接続時の体験：VPN や Wi-Fi で切断→再認証がすぐ走る設計だと、ユーザーは「頻繁にログインさせられる」と感じます。
- ポリシーが複数あり、想定外のポリシーがマッチ：NPS は上から順に評価されるため、優先順位で結果が変わります。
無線LAN・802.1X で「一定間隔で再認証される」場合
ネットワーク機器によっては、Session-Timeout（属性 27）を“セッションを切る上限”としてではなく、“周期再認証のタイマー”として扱うことがあります。Cisco の 802.1X 設定ガイドでも、RADIUS 環境ではスイッチが Session-Timeout（属性 27）や Termination-Action（属性 29）をタイマーに利用する旨が説明されています。
このタイプの機器で Session Timeout を短くすると「切断というより、再認証が頻繁に走って通信が瞬断する」といった体感トラブルになりがちです。802.1X 環境では、Session Timeout を“セキュリティ目的の周期”として慎重に決め、必要なら機器側の再認証設定（inactivity / reauthenticate など）と合わせて設計してください。
検証手順：NPS の「60」が何秒として返っているかを確認する
「60 を入れたのに 1 分で切れた」「1 時間で切れるはずが切れない」などの混乱は、（1）単位の取り違えと（2）NAS 側が採用していないでほぼ説明できます。以下の順で確認すると早いです。
- NPS ログで Session-Timeout / Idle-Timeout の列を確認
NPS のアカウンティングログは既定で%SYSTEMROOT%\System32\Logfiles\に保存され、列としてSession-TimeoutとIdle-Timeoutが含まれます。 - Access-Accept の RADIUS 属性（27/28）をパケットで確認
ここで「60」「3600」など実際の秒数が見えます。RFC 定義どおり、値は秒です。 - NAS 側のログで“切断理由”と“適用されたタイマー”を確認
機器によっては「RADIUS の値を採用した／採用しなかった」がログに出ます。
NAP の補足：Windows Server 2016 以降は NAP が利用できない（ただし NPS/RADIUS は現役）
「NPS（NAP/RADIUS）」とセットで語られがちですが、NAP（Network Access Protection）そのものは Windows Server 2012 R2 で非推奨となり、Windows Server 2016 以降では利用できません。既存の NAP 展開を Windows Server 2016 以降へ移行できない点も含め、長期運用では代替（別の NAC、端末準拠性チェックの仕組み）を検討対象に入れるのが現実的です。
一方で NPS は Windows Server 2016 でも引き続き利用されており、RADIUS サーバーとして無線 LAN、認証スイッチ、VPN などの認証・認可・（任意で）アカウンティングを集中管理できます。つまり本記事で扱った Idle Timeout / Session Timeout は「NAP の有無」とは別軸で、RADIUS 認証を運用する上で今も重要な設計ポイントです。
まとめ：迷ったら「目的」と「誰が切るか」を起点に設計する
- Idle Timeout＝無通信が連続したら切る（放置接続の掃除向き）
- Session Timeout＝最大利用時間で切る（最大接続時間の制限・周期運用向き）
- NPS は切断を実行する装置ではなく、RADIUS 属性として値を返す役。NAS 側の採用・仕様が成否を決める
- 「60」が何を意味するかは、NPS 画面の単位と、実際に返っている秒数（ログ/パケット）で確定させる
設計・検証のコツは、いきなり厳しくしないことです。まずは業務に支障が出ない長めの値で導入し、ログで実態を見ながら、段階的に“狙いどおりの切れ方”に寄せていくと失敗が少なくなります。
コメント