RADIUS完全ガイド：Wi-Fi・VPN・NACの認証を強化する最新設計と実践ガイド！

社内Wi-FiやVPNの認証、うまくいかない—RADIUSの設定が複雑で、EAPの選択や動的VLAN、共有鍵やMD5の不安…そんな悩みを一気に解決。

この記事ではRADIUSの基本と仕組み、FreeRADIUS/NPSの実践、RadSec移行、トラブル対処を要点だけに絞って、初心者にも分かりやすく解説します！

RADIUSとは何か

ネットワークセキュリティや認証システムの分野でよく耳にする「RADIUS（Remote Authentication Dial-In User Service）」ですが、名前だけを聞いても具体的にどのような仕組みなのか、なぜ必要とされているのかを理解している方は意外と少ないかもしれません。

RADIUSは、企業ネットワークやWi-Fi認証、VPN接続など、日常的に利用されるさまざまな場面で活躍している重要な技術です。

ここでは、RADIUSの定義や歴史的背景、さらにその基盤となるAAAモデルについて、初心者にもわかりやすく解説していきます。

---

1-1. RADIUSの定義と歴史的背景

RADIUSとは「リモート認証ダイヤルインユーザーサービス」の略で、ネットワーク接続を行うユーザーを認証し、利用できる権限を決定し、その利用状況を記録するためのプロトコルです。

最初は1991年にリビオ・ジェイ・シエラ（Livingston Enterprises）によって開発され、その後インターネット標準（RFC 2058, RFC 2059）として定義されました。現在でも、多くのネットワーク機器ベンダーやソフトウェアがRADIUSをサポートしており、標準的な認証基盤の一つとされています。

つまり、RADIUSは「ユーザーが誰であるかを確認し、どこまでネットワークを利用できるかを決め、さらに利用状況を記録する」という役割を果たす仕組みなのです。

RADIUSが広く使われる理由

• 相互運用性：さまざまなメーカーの機器やOSで利用可能
• 軽量性：UDPをベースとした効率的な通信方式
• 信頼性：長年にわたり企業ネットワークやISPで利用されてきた実績

このようにRADIUSは歴史的に実用性が高く、今もなお多くのネットワーク環境で利用され続けています。

---

1-2. AAAモデル（Authentication・Authorization・Accounting）の概要

RADIUSを理解する上で欠かせないのが「AAAモデル」です。AAAとは以下の3つの要素を指します。

項目	内容	RADIUSでの役割
Authentication（認証）	ユーザーが誰であるかを確認する	IDとパスワード、証明書などを使い本人確認
Authorization（認可）	認証されたユーザーが何を利用できるかを決定する	VPN接続の可否、ネットワーク帯域制御など
Accounting（課金・記録）	ユーザーの利用状況を記録する	接続時間や使用リソースをログに保存

このAAAモデルを効率的に処理するために登場したのがRADIUSなのです。

なぜなら、従来のシステムでは「ユーザー確認」「アクセス許可」「利用状況記録」をそれぞれ別々に管理していたため、セキュリティ上の不備や運用負担が大きかったからです

RADIUSを利用することで、これら3つの要素を一元的に管理できるようになり、セキュリティ強化と運用効率化を同時に実現できます。

RADIUSの仕組みと技術的要素

RADIUSは単なる「認証サーバー」ではなく、ネットワーク全体のアクセス制御を支える重要な基盤です。その動作を理解するには、RADIUSがどのように通信を行い、どのようにユーザー情報をやり取りしているのかを知る必要があります。

ここでは、RADIUSのパケット構造や利用される通信プロトコル、そしてユーザー認証に欠かせない属性（Attributes）について解説します。

---

2-1. パケット構造と通信プロトコル（ポート番号、UDP/TCPなど）

RADIUSは、クライアント（ネットワーク機器やWi-Fiアクセスポイントなど）とサーバーの間でメッセージをやり取りすることで動作します。

その際、通信は「パケット」と呼ばれる小さなデータのまとまりで行われます。

RADIUSパケットの基本構造

RADIUSのパケットは、以下のような情報を含んでいます。

• コード（Code）：リクエストかレスポンスかを示す識別子
• 識別子（Identifier）：リクエストとレスポンスを対応させるための番号
• 長さ（Length）：パケット全体のサイズ
• 認証情報（Authenticator）：改ざん検出やセキュリティ強化のためのデータ
• 属性（Attributes）：ユーザー名、パスワード、接続条件などの情報

この構造により、RADIUSは「誰が接続してきたのか」「どんな認証情報を持っているのか」「接続を許可するか否か」を効率的にやり取りできるようになっています。

通信プロトコルとポート番号

RADIUSは伝統的に UDP を利用して通信します。主なポート番号は以下の通りです。

用途	デフォルトポート番号
認証（Authentication）	UDP 1812
課金・記録（Accounting）	UDP 1813
旧仕様で利用される場合	UDP 1645 / 1646

UDPは軽量で処理速度が速いため、当時のモデム接続やISP環境に適していました。

ただし、UDPは信頼性に欠ける部分もあり、その結果として近年では TCPやTLS（RadSec） を利用したセキュアな通信方式も登場しています。

つまり、従来のRADIUSは「速さ」を重視してUDPを採用しましたが、現代では「セキュリティ強化」のためにTCPや暗号化技術を組み合わせるケースが増えているのです。

---

2-2. 属性（Attributes）とユーザー認証方式（PAP, CHAP, EAP等）

RADIUSの大きな特徴の一つが「属性（Attributes）」です。

属性は、RADIUSパケット内に含まれる追加情報で、ユーザー名やパスワードだけでなく、接続先の情報や利用条件なども含めることができます。

2-2-1 主なRADIUS属性の例

• User-Name：ユーザーID
• User-Password：パスワード（暗号化して送信）
• NAS-IP-Address：接続元のネットワーク機器のアドレス
• Framed-IP-Address：ユーザーに割り当てられるIPアドレス
• Session-Timeout：接続の有効期限

これらの属性を柔軟に設定することで、ネットワーク管理者は「誰が・どこから・どのくらいの時間利用できるか」を詳細にコントロールできます。

2-2-2. RADIUSで利用される認証方式

RADIUSは複数の認証方式に対応しています。

それぞれ特徴が異なるため、環境やセキュリティ要件に応じて選ばれます。

認証方式	特徴	セキュリティレベル
PAP（Password Authentication Protocol）	パスワードを平文で送信する	低い（推奨されない）
CHAP（Challenge-Handshake Authentication Protocol）	パスワードを暗号化してやり取り	中程度
EAP（Extensible Authentication Protocol）	証明書やスマートカードなど、多様な方式に対応可能	高い

例えば、古いシステムではシンプルなPAPが使われることもありましたが、現代ではセキュリティ強化のためにEAPが主流となっています。

特に、企業のWi-Fi認証やVPNアクセスでは「EAP-TLS」や「PEAP」といった高度な方式が多く利用されています。

RADIUSの主な用途と利用シーン

RADIUSは、企業ネットワークの「入口」を守る要であり、ユーザーやデバイスがネットワークに入る瞬間の認証・認可・記録を一手に引き受けます。

つまり、RADIUSがうまく機能すれば、Wi-Fi・VPN・有線LAN・来訪者用ネットワークなど、あらゆる接続ポイントの安全性と運用効率が同時に高まります。

ここでは代表的なユースケースを、実務に即してわかりやすく解説します。

---

3-1. VPN・ワイヤレスネットワークでの認証

RADIUSは、社員や端末が社内ネットワークへ安全に入るための「本人確認役」です。

特に、企業Wi-Fi（WPA2/WPA3-Enterprise）やリモート接続用のVPNで広く使われています。

3-1-1. Wi-Fi（802.1X）でのRADIUS認証の流れ（要点）

• ステップ1：接続要求
  端末（スマートフォン・PC）が企業SSIDへ接続すると、AP/無線LANコントローラ（RADIUSクライアント）がRADIUSサーバーへ認証を依頼します。
• ステップ2：ユーザー/端末の証明
  EAP-TLS（証明書）やPEAP（ID/パスワード＋TLS）などの方式で端末/ユーザーを確認します。
• ステップ3：アクセス権の付与
  RADIUSはVLANやアクセスリスト（ACL）、QoSなどのポリシー属性を返し、適切なネットワークに自動収容します。
• ステップ4：記録
  いつ・誰が・どこから接続したかをAccountingで記録します。

現場のポイント

• 動的VLAN割り当て：部署や端末種類ごとに最適なネットワークへ自動で振り分け。
• デバイス多様化対策：PCはEAP-TLS、IoTやプリンタはMAB（MAC認証）＋制限VLANなど、RADIUSポリシーで安全に共存。
• ゼロトラストの足がかり：RADIUS属性で細かなアクセス制御を行い、ネットワーク内横移動を抑制。

3-1-2. VPNでのRADIUS認証（実務に効く設計観点）

• 多要素認証（MFA）連携
  RADIUSはワンタイムパスワードやプッシュ通知サービスと連携しやすく、ID＋パスワード＋追加要素で堅牢化できます。
• グループベースの権限制御
  RADIUSのFilter-Idやベンダー固有属性（VSA）で、VPNゲートウェイのポリシー（到達可能ネットワーク、分割トンネル可否など）を自動適用。
• 監査の容易化
  認証成功/失敗や接続時間をAccountingで一元記録し、セキュリティ監査や容量計画に活用可能。

3-1-3. Wi-FiとVPNの違い（RADIUS視点の比較）

観点	企業Wi-Fi（802.1X）	VPN（リモート接続）
主目的	社内無線の本人確認＋動的なネットワーク収容	社外から社内リソースへ安全なトンネル接続
認証方式の主流	EAP-TLS/PEAP	EAP/CHAP/PAP＋MFA（ゲートウェイ依存）
付与するポリシー	VLAN/ACL/QoS/タイムアウト	グループ/ACL/クライアントルート/分割トンネル
監査（Accounting）	接続AP、SSID、滞在時間など	接続元IP、接続時間、送受信量など

したがって、RADIUSはWi-Fiでは現場運用の自動化、VPNではリモートアクセスの堅牢化という形で、それぞれのシーンを下支えします。

---

3-2. ネットワークアクセス制御（NAS）、キャプティブポータル、遠隔アクセス

RADIUSは、いわゆるNAC（Network Access Control）や来訪者ネットワーク、さらには在宅・現場作業者の遠隔アクセスでも中心的な役割を担います。

だからこそ、設計次第で安全性と利便性が大きく変わります。

3-2-1. NACでのRADIUSの役割（有線LAN/IoTを含む）

• 802.1Xによる有線認証
  スイッチ（NAS：Network Access Server）がRADIUSクライアントとなり、ポート単位で端末をチェック。合格すれば業務VLAN、未合格なら隔離VLANへ。
• MAB（MAC Authentication Bypass）
  802.1X非対応の機器（プリンタ、IP電話、IoT）には、MACアドレスを使った簡易認証を併用し、RADIUS属性で通信範囲を最小化。
• CoA/Disconnectでの動的制御
  端末姿勢（パッチ適用、EDR稼働など）が変わったら、Change of Authorizationで即時にポリシー変更。その結果、脆弱端末の隔離がスムーズ。

RADIUSでよく使う代表属性（NAC文脈）

• Tunnel-Private-Group-ID：VLAN割り当て
• Filter-Id / VSA：ACL・役割ベースポリシー
• Session-Timeout / Idle-Timeout：接続許可の期間制御

3-2-2. キャプティブポータル（来訪者/店舗Wi-Fi）の実践ポイント

• WebログインとRADIUSの橋渡し
  ゲストがWebポータルで認証すると、コントローラがRADIUSへ認証照会。成功時に、ゲスト専用の帯域制限や時間制限を属性で返却。
• スケジュール/同意管理
  同意文（AUP）に合意したユーザーだけに一時アカウントを払い出し、RADIUS Accountingで滞在状況を可視化。
• セキュリティ分離
  社員ネットワークとは論理的に分離（ゲストVLAN＋ファイアウォール）し、RADIUSポリシーで内部資産への到達を抑止。

3-2-3. 遠隔アクセスとゼロトラストの橋渡し

• IdP/ディレクトリ連携
  RADIUSはAD/LDAPやクラウドIdPと連携し、社内外一貫のアイデンティティ基盤を実現。
• 端末健全性と段階的アクセス
  端末証明書やEDRの有無、OS更新状況に応じて、RADIUS属性で段階的な許可（フル/限定/隔離）を返す設計が有効。
• ログの一元化
  RADIUS AccountingをSIEMに集約し、異常接続やアカウント濫用を早期検知。結果として、ゼロトラストに必要な可観測性が高まります。

---

3-2-4. シーン別：RADIUSが解決する課題と設計ヒント

シーン	代表課題	RADIUSでの解決アプローチ
企業Wi-Fi	部署・端末混在で設定が煩雑	動的VLAN/ACLで自動収容、証明書認証でなりすまし防止
有線LAN（NAC）	未管理デバイスの侵入	802.1X＋MABで可視化し、CoAで即時隔離
ゲストWi-Fi	認証の手間と運用負荷	キャプティブポータル＋一時アカウント、時間帯/帯域制限を属性で返却
VPN	パスワード流出リスク	MFA連携＋グループ属性で最小権限接続
リモート/現場	監査・可視化不足	AccountingをSIEM連携し、接続の痕跡を統合監査

セキュリティ上の課題と対策

RADIUSは長年にわたり企業ネットワークの認証基盤として使われてきました。しかし、歴史的経緯ゆえの設計上の制約が残っているのも事実です。

つまり、適切な設定と近代的な拡張（TLS/TCP など）を取り入れないと、RADIUSが想定どおりの強度を発揮できない場合があります。

ここでは、RADIUSの代表的な課題と、その場しのぎではない実践的な対策を整理します。

---

4-1. パスワード保護・暗号化の限界（MD5の問題など）

RADIUSは当初、軽量性と相互運用性を重視して設計されました。

したがって、メッセージの保護に古典的な手法（MD5 を用いたオブフスケーションや整合性確認）が残っています。なぜなら、当時の計算資源とネットワーク事情では十分だったからです。

ところが現在では、計算能力の向上や攻撃手法の高度化により、従来の保護だけでは不十分になりつつあります。

4-1-1. RADIUSでMD5が使われる代表箇所

• User-Password の保護
  共有鍵とリクエスト情報を組み合わせた MD5 ベースのオブフスケーションでパスワードを隠す方式。完全な暗号化ではありません。
• メッセージ整合性の確認
  Request/Response Authenticator や Message-Authenticator で HMAC-MD5 相当の検証を行うケースがあります。
• EAP 絡みの下位プロトコル
  たとえば MS-CHAPv2 のように、近年の基準では脆弱とされる方式が混在することがあります。

4-1-2. 何が問題なのか（実務的な視点）

• 辞書攻撃・オフライン解析の余地
  PAP や弱い EAP メソッドでは、盗聴・ログ漏えい時にパスワード推測の足がかりとなります。
• 共有鍵運用の難しさ
  RADIUS クライアントとサーバー間の**共有秘密鍵（shared secret）**の配布・ローテーションが疎かになりがちです。
• MD5 の近代的評価
  MD5 は衝突耐性が弱く、将来にわたり安全性を期待できません。結果として、完全性や機密性をMD5に依存する設計は避けるのが安全です。

4-1-3. 現場で起きがちなリスク例

• 来訪者用 Wi-Fi で PAP を許可し、平文パスワードが実質的に保護されない構成になっている。
• スイッチや AP の RADIUS 共有鍵が長年固定で、退職者や外注先に知られたまま更新されていない。
• EAP-MS-CHAPv2 を広範囲で使い続け、パスワードクラックの踏み台になっている。

4-1-4. すぐできる対策（優先度つき）

1. PAP を無効化、または極力限定（やむを得ない場合は隔離 VLAN と最小権限）。
2. EAP-TLS（証明書ベース）を第一選択、次点で PEAP など TLS を内包する方式を使用。
3. RADIUS 共有鍵の強化とローテーション（長く・複雑に、台帳管理、定期更新）。
4. Message-Authenticator の必須化やベンダー推奨の厳格検証オプションを有効にする。
5. 監査ログ（Accounting）をSIEMに連携し、失敗回数の異常、深夜帯の急増などを検知。

---

4-2. RadSecなどの拡張、TLS/TCP利用、接続の安全性向上

RADIUSの本来の通信は UDP ですが、近年は RADIUS over TLS（通称 RadSec） や RADIUS over TCP/DTLS など、近代的なトランスポートで機密性・完全性・相互認証を高める手法が整備されています。

だからこそ、RADIUS区間の盗聴・改ざん・なりすましリスクを物理ネットワーク任せにしない設計が重要です。

4-2-1. RADIUS over TLS（RadSec）の要点

• 暗号化と完全性の確保
  TLS により RADIUS メッセージが暗号化され、改ざん検出も強化されます。
• 相互認証
  サーバー証明書に加え、クライアント証明書を使えば NAS ↔ RADIUS サーバー間の相互認証が可能です。
• プロキシ／拠点間中継で威力
  インターネット越しやマルチテナント環境でも、経路の安全性をTLSで担保しやすくなります。

4-2-2. RADIUS over TCP / DTLS の位置づけ

• TCP：再送制御や輻輳制御により、安定性や大量同時接続時の扱いやすさが向上。
• DTLS：UDP の軽さを保ったまま、TLS 同等の暗号化を提供。リアルタイム性重視の環境で選好される場合があります。
• したがって、要件（レイテンシ、機器対応、運用体制）に応じて TLS/TCP/DTLS を使い分けます。

4-2-3. 段階的な移行計画（無理なく強化する手順）

1. 現状棚卸し：RADIUS クライアント一覧、共有鍵、対応プロトコル（EAP 種別・UDP/TCP/TLS）を可視化。
2. 方針決定：社内はまず EAP-TLS/PEAP 徹底、機器間は RadSec 優先、例外は短期で是正。
3. 証明書基盤（PKI）整備：CA、証明書プロファイル、失効管理（CRL/OCSP）を運用に落とし込む。
4. 並行運用：検証拠点で RadSec を有効化し、フォールバックを段階的に封じる。
5. ローテーション・監査：共有鍵・証明書ともに有効期限と交代計画を設定、ログで恒常監視。

4-2-4. 設計・運用ベストプラクティス集

• サーバー・クライアント双方の証明書検証を厳格化（CN/SAN、信頼チェーン、失効確認）。
• TLS 1.2/1.3 を強制し、古いスイートを無効化。
• EAP-TLS を標準、非対応端末は隔離ネットワーク＋最小権限に固定。
• CoA（Change of Authorization）と組み合わせ、違反端末を即時に再収容/切断。
• Accounting を必須とし、SIEM で異常値アラート（失敗急増、1ユーザーの多拠点同時接続など）。
• ベンダー固有属性（VSA）を活用し、役割ベースのアクセス制御を一元化。
• 運用ドキュメント整備：RADIUS クライアント登録手順、証明書更新手順、障害時フォールバック基準を明文化。

4-2-5. 従来RADIUSとRadSecの比較（要点早見表）

項目	従来 RADIUS（UDP＋共有鍵）	RADIUS over TLS（RadSec）
機密性	User-Password 等はオブフスケーション中心	TLS で全メッセージ暗号化
完全性	MD5 系に依存しがち	TLS の完全性で強化
相互認証	共有鍵ベース、配布が課題	証明書ベースの相互認証が容易
中継・拠点間	経路の安全性を物理/網側に依存	インターネット越しでも安全に中継可能
運用	共有鍵の台帳・更新が負担	証明書の期限管理に集約しやすい

他プロトコルとの比較と選定基準

RADIUSは企業ネットワーク認証の定番ですが、同じ“認証まわり”の文脈で語られるTACACS+、LDAP、Diameterとは役割や得意分野が異なります。

つまり、目的に合ったプロトコルを選ぶことで、セキュリティと運用効率が同時に向上します。

ここでは、RADIUSとの違いと、実運用での選定基準を整理します。

---

5-1. TACACS+、LDAP、Diameterとの違い

5-1-1. RADIUSとTACACS+の違い（ネットワーク機器管理に強いTACACS+）

• 主な用途の違い
  RADIUSはネットワーク接続の認証・認可・記録（AAA）に最適で、Wi-Fi（802.1X）やVPN、有線LANのNACで広く利用されます。
  一方TACACS+は、ルータやスイッチ、ファイアウォール等の管理者ログインに特化し、コマンド単位の認可が細かく行えるのが強みです。
• 技術的な違い（要点）
  • トランスポート：RADIUSは主にUDP、TACACS+はTCP（安定性と制御がしやすい）
  • 暗号化範囲：RADIUSは属性ごと、TACACS+はペイロード全体を暗号化する実装が一般的
  • 認可粒度：RADIUSは接続ポリシー（VLAN/ACL等）に強く、TACACS+はコマンドレベルでの許可・拒否が得意

5-1-2. RADIUSとLDAPの違い（ディレクトリとAAAの役割分担）

• 役割の位置づけ
  LDAPは「プロトコル」というよりディレクトリアクセス手段です。ユーザー情報（属性、所属、公開鍵など）を格納したディレクトリ（AD/LDAPサーバー）に読み書きするために使われます。
  したがって、LDAP単体はネットワークアクセス制御のAAAフレームワークではありません。
• 現場での関係
  RADIUSサーバーが裏側でLDAP/ADに問い合わせ、資格情報の検証や属性取得を行う構成が王道です。つまり、RADIUS＝フロントのAAA、LDAP＝バックエンドの“身元台帳”という分担になります。

5-1-3. RADIUSとDiameterの違い（テレコム領域での後継）

• 設計思想
  DiameterはRADIUSの後継として設計され、信頼性・拡張性・状態管理を強化。トランスポートにTCPやSCTPを用い、機能交渉や冗長性を標準化しています。
• 主な用途
  主戦場は通信事業者（3G/4G/5Gコア、IMS、課金連携）。一方で、エンタープライズのWi-FiやVPNでDiameterを採用するケースは少数です。
• 実務的含意
  企業ネットワークの認証はRADIUSで十分かつ現実的、テレコムのAAAやポリシー制御はDiameterが適任という棲み分けです。

5-1-4. 機能比較（早見表）

観点	RADIUS	TACACS+	LDAP	Diameter
主用途	ネットワーク接続のAAA（Wi-Fi/VPN/NAC）	機器管理者の認証・コマンド認可	ディレクトリ参照・属性管理	テレコムAAA・課金・ポリシー
トランスポート	主にUDP（拡張でTCP/TLS）	TCP	TCP（389/636）	TCP/SCTP
暗号化	伝統的RADIUSは限定的、RadSec/TLSで強化可能	ペイロード全体暗号化（実装依存）	StartTLS/LDAPS	内在するセキュア機構
認可粒度	ネットワーク側ポリシー（VLAN/ACL/QoS）	コマンド単位のポリシー	認可はアプリ側実装次第	テレコム用の細粒度AVP
連携相手	AD/LDAP、IdP、MFA、NAC	AD/LDAP、ログ監査	各種アプリ・RADIUS/TACACS+の裏側	PCRF/PCF等のコア機能
エンタープライズ適合	非常に高い	管理者運用で高い	台帳として必須級	一般企業では限定的

---

5-2. どのシステム／環境でどのプロトコルが適しているか

用途に応じて最適解は変わります。したがって、下の“環境別マップ”を基準に選ぶと迷いにくくなります。

5-2-1. 環境別の推奨マップ

環境・システム	推奨プロトコル	理由と設計のヒント
企業Wi-Fi（WPA2/WPA3-Enterprise、802.1X）	RADIUS	EAP-TLS/PEAPで端末・ユーザー認証、動的VLAN/ACLを属性で付与。RadSecで拠点間をTLS化。
有線LANのNAC（スイッチポート認証）	RADIUS	802.1X＋MABで多様な端末を制御。CoAで隔離・再収容を即時反映。
VPN（リモートアクセス）	RADIUS＋MFA	ゲートウェイと連携し、グループ/ACLをRADIUS属性で適用。監査はAccountingをSIEMへ。
ネットワーク機器の管理者ログイン	TACACS+	コマンド単位の認可と詳細監査が必要。運用チーム向けに権限分離が容易。
社内アプリのユーザー認証・属性参照	LDAP（AD）	台帳はAD/LDAP、アプリはLDAP Bind/属性参照。ネットワーク接続のAAAはRADIUSと分担。
通信事業者のAAA/課金/ポリシー	Diameter	大規模・多拠点・高信頼が前提。RADIUSより豊富な制御と冗長化が前提設計。
来訪者Wi-Fi（キャプティブポータル）	RADIUS	WebポータルとRADIUS連携で一時アカウント、時間/帯域制限を属性で返却。
ゼロトラスト移行（段階的）	RADIUS＋IdP（SAML/OIDC）	端末証明書とユーザー属性を組み合わせ、最小権限アクセスをネットワーク側で実装。

5-2-2. 選定のための意思決定フロー（簡易）

1. 接続か管理か
   • 接続の制御が目的 → RADIUS中心
   • 機器の管理者操作制御 → TACACS+
2. 台帳はどこか
   • 既にAD/LDAPがある → RADIUS/TACACS+は裏側でLDAP参照
3. 暗号化要件
   • 経路暗号化が必須 → RadSec/TLS（RADIUS）またはLDAPS/TLS
4. 粒度要求
   • コマンド単位の権限が要る → TACACS+
   • ネットワーク収容ポリシー（VLAN/ACL） → RADIUS
5. スケール/領域
   • テレコム級のAAA/課金/ポリシー → Diameter

5-2-3. 実装時のチェックリスト（RADIUSを軸に）

• 認証方式はEAP-TLSを第一選択（非対応端末は隔離＋最小権限）。
• 経路はRadSec/TLSで暗号化、古い暗号や平文方式は段階的に廃止。
• バックエンドはAD/LDAPと連携し、属性（グループ/部門/端末種別）で動的ポリシーを返却。
• Accountingログを必須化し、SIEMで失敗急増や異常同時接続を検知。
• 機器管理はTACACS+で分離し、コマンド権限と監査証跡を厳密化。

導入と運用の実践ガイド

RADIUSの導入は、単なるサーバーの立ち上げでは終わりません。

なぜなら、ディレクトリ連携、証明書、ポリシー、ログ、そして冗長化まで含めて初めて“運用に耐える認証基盤”になるからです。

ここでは主要製品の選び方と設定の勘所、さらにトラブル時の切り分けと運用ベストプラクティスを、実務目線で整理します。

---

6-1. 主なRADIUSサーバー製品の選び方と設定のポイント（例：FreeRADIUS, Microsoft NPS等）

6-1-1. 製品選定の考え方（用途・規模・運用体制）

観点	FreeRADIUS	Microsoft NPS	クラウド型RADIUS（ベンダー各種）
強み	柔軟な拡張性、細かなポリシー、パフォーマンス	AD連携が容易、Windows運用に自然にフィット	導入が速い、拠点間での可用性を確保しやすい
向く環境	マルチベンダー機器、複雑なNAC、細粒度要件	AD中心の企業Wi-Fi/VPN、Windows統制が強い環境	拠点多数、運用リソースが限られるケース
学習/運用コスト	中〜高（設定の自由度が高い）	低〜中（GUI中心）	低（ただし月額費用と依存度に留意）
代表ユースケース	802.1X＋MAB、VLAN/ACLの動的割当、CoA活用	PEAP/EAP-TLSのWi-Fi、VPNのグループ制御	来訪者Wi-Fi、拠点分散、迅速なスケール

要するに、要件が複雑ならFreeRADIUS、AD密結合ならNPS、スピード重視ならクラウドが起点になります。

6-1-2. FreeRADIUSの構成と設定要点（はじめの一歩）

• 基本ディレクトリ（一般例）：mods-available／mods-enabled、sites-available／sites-enabled、clients.conf、mods-available/eap、sites-enabled/default と sites-enabled/inner-tunnel。
• クライアント登録：clients.conf にAP/スイッチ/VPNなどのNASを登録し、強固なshared secretを設定。
• EAPの中核設定：mods-available/eap で EAP-TLS/PEAP を有効化。サーバー証明書と中間CAを正しく配置。
• ポリシー適用：sites-enabled/default の authorize／authenticate／post-auth、および inner-tunnel で役割（role）→ VLAN/ACLを返すロジックを実装。
• VLAN割当の標準属性：
  • Tunnel-Type = VLAN
  • Tunnel-Medium-Type = IEEE-802
  • Tunnel-Private-Group-ID = “VLAN_ID”
• 辞書ファイル：ベンダーVSA（例：Aruba/Juniper/Cisco等）用に dictionary.* を読み込むと、ロールやACLを返しやすい。
• デバッグ：freeradius -X（フォアグラウンド）で詳細ログ。radtest（PAP）や eapol_test（EAP）で疎通確認。

ポイントは、inner-tunnelの理解（EAPの内側で再認証されるフロー）と、属性での動的制御を確実に返すことです。

6-1-3. Microsoft NPSの構成と設定要点（AD密結合の定番）

• RADIUSクライアント登録：APやスイッチ、VPNをRADIUSクライアントとして登録し、強固なshared secretを設定。
• ポリシー二段構え：
  1. 接続要求ポリシー（CRP）：どのNASからの要求を受けるか、プロキシ有無を決定。
  2. ネットワーク ポリシー（NP）：条件（グループ/SSID/NASポート等）→ 許可/拒否 → 返す属性を定義。
• EAP設定：PEAP（内部MS-CHAPv2）またはEAP-TLSをサーバー側で有効化。NPSサーバーに正しいサーバー証明書（目的：サーバー認証）を配備。
• VLAN/ACL付与：標準RADIUS属性（前述のTunnel属性）やVSAをネットワークポリシーの設定で追加。
• ログ/監査：イベントビューア（Network Policy and Access Services）で成功/失敗理由を確認。AccountingログはCSVやTSVで出力し、SIEMに集約。

要するに、NPで“誰に何を返すか”を明示し、証明書とグループ条件をブレなく運用するのがコツです。

6-1-4. 証明書とEAPの実装Tips（安定運用の分水嶺）

• EAP-TLSを第一選択：端末証明書で強固な本人確認。PEAPは段階的な移行や例外用に限定。
• PKI運用：CAの有効期限、CRL/OCSP、サブCA有無、失効手順をドキュメント化。
• 信頼の連鎖：サーバー証明書の中間CAを必ず配布。端末に正しいルートCAを事前配備。
• 時刻同期：NTPずれは認証失敗の温床。RADIUS/NAS/クライアントの時刻を厳密に。
• TLSの強化：TLS 1.2/1.3を強制し、弱い暗号スイートや古いEAP（EAP-MD5, LEAP等）は無効化。

6-1-5. 冗長化・拠点間・安全な輸送（止めない/盗ませない）

• 冗長化：AP/スイッチ側にプライマリ/セカンダリRADIUSを設定。ハートビート/タイムアウト/再試行回数を適切に。
• Accountingの設計：Start/Stopに加えて Interim-Update を有効化し、利用状況を継続把握。
• CoA/Disconnect：違反端末を即時隔離。UDP 3799 を用いる実装が一般的。
• 経路暗号化：対応機器があれば RadSec（RADIUS over TLS, 既定ポート例：TCP 2083） を検討。非対応ならIPsecで区間保護。
• スケール：スレッドプール/同時接続数/DB接続を見積もり、負荷試験で落としどころを把握。

---

6-2. トラブルシューティングとベストプラクティス

RADIUSは“どこで落ちているか”が分かれば怖くありません。

つまり、クライアント（端末）／NAS／RADIUS／ディレクトリ／証明書／ネットワークのどこで失敗しているかを素早く切り分けられれば、復旧は早いのです。

6-2-1. 典型的な失敗の原因と対処

症状	よくある原因	対処の方向性
認証が毎回失敗する	shared secret不一致／NAS未登録	RADIUSクライアント定義とshared secretを再確認
EAPで失敗（Wi-Fi）	サーバー証明書の不備／中間CA未配布	端末の信頼ストアを整備、証明書チェーンを是正
一部端末だけ失敗	古いEAP/暗号、時刻ずれ	端末のEAP設定更新、NTP同期の徹底
VLANが割り当たらない	返す属性の欠落/綴り違い/VSA未読込	Tunnel属性3点セットを正しく返す、辞書を更新
途中で切断される	セッションタイムアウト/Idle設定	Session-Timeout/Idle-Timeoutを要件に合わせ調整
ローミングが不安定	Accounting/再認証のタイミング不整合	Interim-Update、再認証間隔、APの設定を見直し

6-2-2. 解析ツールとログの読み方（順番が速さ）

1. NAS側ログ：AP/スイッチ/VPNでRADIUS送受信のエラーを確認（タイムアウト、認証サーバー未達など）。
2. RADIUS側デバッグ：
   • FreeRADIUS：freeradius -X で属性の入出力を追跡。
   • NPS：イベントビューアのNetwork Policy and Access Servicesで失敗理由を確認。
3. パケットキャプチャ：tcpdump/wireshark で UDP 1812/1813、またはTCP 2083（RadSec）を確認。
4. ディレクトリ連携：AD/LDAPのBind失敗（資格情報・接続先DN）、グループ照会条件の誤りに注意。
5. クライアント検証：eapol_test やOSのWi-Fi詳細ログでEAPハンドシェイクの段階を追う。

この順番で辿れば、通信路 → 認証ハンドシェイク → 属性/ポリシー → 台帳のどこで落ちているかが見えます。

6-2-3. 運用ベストプラクティス（長く安定して回すために）

• EAP-TLS標準化：例外は明確に隔離し、最小権限ネットワークへ。
• RadSec/TLS活用：拠点間・プロキシ経由を安全化。TLS 1.2/1.3を必須に。
• 共有鍵の管理：RADIUSクライアント台帳を整備し、鍵は定期ローテーション。
• CoAで即応：EDRや姿勢監視と連携し、違反を検知したら即時再収容/切断。
• Accountingの可観測性：失敗急増・同時接続の異常をSIEMで検知。
• 変更管理とバックアップ：設定はGit等でバージョン管理、ロールバック手順を明文化。
• 定期監査：弱いEAP/暗号の残存チェック、不要クライアント/古い証明書の棚卸し。

6-2-4. 移行と拡張のチェックリスト（実行順序の例）

1. 現状把握：RADIUSクライアント一覧、EAP種別、共有鍵、証明書、ログ基盤。
2. 方針決定：RADIUSは EAP-TLS＋RadSec を基本、例外は期限付き許容。
3. PKI整備：CA/失効管理、端末配布、更新ポリシー。
4. 検証環境：パイロットSSID/スイッチで並行運用、互換性を確認。
5. 段階移行：部署や拠点ごとにロールアウト、古い方式を段階的に無効化。
6. 運用定着：ダッシュボード化、アラート閾値、月次レポートで改善サイクル。