【図解】RADIUSの一般的な使われ方〜AD/LDAPとの違い, 認証シーケンス〜

Radius と AD/LDAP の使われ方の違い

Radius も AD/LDAP も認証を行うサーバですが、それらが出来た背景から、使われ方が違います。

Radius は主に ISDN のダイヤルアップでのインターネット接続時代に出来た、ネットワーク機器の認証に特化したプロトコルです。

従量課金が当たり前の時代で、ISP 事業者はユーザが正規であることを確認（認証）し、そのユーザに適した権限を付与（認可）し、そして接続時間をしっかり管理して請求書に反映させる（課金）必要がありました。

Radius のアカウンティングが課金とも表現されるのはこのためですが、今では『接続ログを取り、後からどのユーザがネットワークを使ったかを確認する』という意味合いが強いです。

一方、AD/LDAP はそれぞれ Windows 系, UNIX/Linux 系のクライアントやサーバ用のユーザアカウントを一元的に管理するツールとして登場した、クライアント・サーバの認証に特化したプロトコルです。

なので主にクライアントやサーバ (メールサーバやファイルサーバ等) が認証するときに使われます。

Radius の一般的な実装例を考えます。登場人物としては以下の通りです。

リモート接続を行うPCもしくはルータ等が該当します。例えば『ISP へ PPP 接続するルータ』、『L2TP、IPsec、SSL-VPN といったリモートアクセスプロトコルを使い、RAS サーバへ接続する PC』等です。

リモート接続を受けるルータ等。これは Radius 用語では NAS (Network Access Server) (註: Network Attached Storage とは違います)とも呼ばれますし、Radius クライアントとも呼ばれます。

PPP 等のリモートアクセスという観点ではサーバですが、認証を Radius サーバへ聞きにいく、という観点ではクライアントになります

今回の主テーマのサーバです。

例えば、メールサーバの認証用等で、すでに LDAP サーバを利用していて、ネットワークの Radius 認証も同じ ID パスワードを使わせたい場合。このようなケースでは、Radius からさらに LDAP サーバへ認証情報を問い合わせさせることで実現できます。

ある Realm (Domain) のユーザは自サーバ内で認証をさせる、という通常の機能を持たせつつ、 Radius プロキシという機能を使って、ある別の Realm (Domain) のユーザを他の Radius サーバへ取り次ぐ、ということができます。

ISP の PPPoE 接続の ID に、@ が使われていることがしばしばありますが、この @ 以降が、Realm (Domain) として扱われます。つまり、@ 以降の Realm によって、認証させる Radius サーバが決まっているのです。

図にもある通り、Radius の一般的なシーケンスとしては以下の通りです。

リモートアクセスクライアントがリモートアクセスサーバへ接続
リモートアクセスサーバが Radius サーバへ認証情報を問い合わせ (Access-Request)
Radius サーバからリモートアクセスサーバへ認証結果を返信。成功の場合、Radius サーバから付加情報として、ユーザに応じた属性値を返すことができる (Access-Accept or Access-Reject)。二要素認証を行いたい場合などは、Access-Challenge を返し、Access-Challenge を受信した NAS は PIN やワンタイムパスワード、Smart カードのトークン等を送信する。
成功の場合、リモートアクセスが行われた時間をログする (Accounting-Request / Accounting-Response)
定期的にリモートアクセス状況を確認する (Accounting-Request / Accounting-Response)
リモートアクセスを終了する (Accounting-Request / Accounting-Response)