【EPS技術記事】NetAttest EPSを用いたeduroam対応RADIUS環境の構築ガイド

概要

本記事は、RADIUSサーバーアプライアンスNetAttest EPSを用いてeduroamに対応した認証環境を構築するためのテクニカルガイドです。
教育・研究機関のネットワーク担当の方や構築を担当するエンジニアの方をターゲットに記載していますが、一般企業等でRADIUSプロキシを構築･運用したいケースでも参考にしていただけると思います。

本記事では検証環境全体の構成を紹介していますが、実際に自機関でeduroamへ参加するために必要なEPSの設定手順は目次の｢ベースとなるEPSの設定｣と｢自機関EPSの設定1～5｣です。

eduroamとは

eduroam(education roaming)は、初等・中等・高等教育機関や研究機関の間でキャンパス無線LAN の相互利用を実現する、国際的なネットワークローミングの仕組みです。
日本国内では国立情報学研究所(NII)がeduroam JPとして運営しています。
eduroamの詳細については公式サイトを参照してください。
https://www.eduroam.jp

RADIUS認証の観点からeduroamの仕組みを説明すると下記のようになります。
加盟機関のRADIUSサーバーは、外部ユーザーからの認証要求を受けた際に、ユーザーの識別情報をもとに所属機関を判別し、eduroam JPが運営するRADIUSプロキシサーバー(Federation Level RADIUS：FLR)へ認証要求を転送します。
FLRはその要求をユーザーの所属機関のRADIUSサーバーへプロキシし、認証結果を接続元の加盟機関へ返送することで、ネットワークへの接続可否を制御する仕組みです。

検証の構成について

本記事では、RADIUS認証の観点でeduroamに参加した教育・研究機関のローカルRADIUSサーバーとしてEPSを使用するための設定にフォーカスします。
EPSはベースとなる設定が完了し、認証ができる状態となっている前提で記載します。
検証で使用したEPSのファームウェアバージョンはv5.2.10です。

eduroam環境での検証はできないため、eduroam JPのFLRの代わりとしてもEPSを使用します。
実際のeduroam JPではNIIが運用するFLRを利用します。
また、外部機関のRADIUSサーバーとしてもEPSを使用します。
本記事での登場人物は下記のとおりです。

検証環境の構成は下記のとおりです。

認証動作のイメージは下の図のようになります。

実際のeduroam環境構築においては、以下の2点が必要です。

• 自機関RADIUSサーバーとしてのEPSの設定
• eduroam JPへのeduroam参加申請と必要情報の提出

一般企業等でRADIUSプロキシを使用する場合はFLRを除いた構成が基本となります。

ベースとなるEPSの設定

本記事ではEPSの管理GUIを使用して設定を行います。
検証に使用する3台のEPSは、初期セットアップウィザードを完了し、EPSのローカルDBに登録したユーザーアカウントでの認証に応答できる状態をベースとします。
説明を簡潔にするためローカルDBを使用していますが、AD等の外部ユーザーDBを参照する場合もRADIUSプロキシに関する設定は同様です。
本記事での認証方式はPEAP-MSCHAPv2を使用します。
実際の環境においては、よりセキュアなEAP-TLS等の認証方式も選択肢となります。

自機関EPSの設定

1. サーバー証明書のインポート

サーバー証明書の用意

eduroamで使用するサーバー証明書を用意します。
eduroamとしては特に発行元の指定はありませんが、一般的にはパブリックCAまたは機関内のプライベートCAを利用します。
プライベートCAでサーバー証明書を発行した場合、各ユーザーの端末側にルート証明書を事前に配布して信頼させる必要がありますので、｢eduroam CAT｣等を利用して対応を行ってください。

eduroamにおけるサーバー証明書の必須要件としては下記があります。
その他の要件/制限についてはeduroamの技術ガイドをご確認ください。
また、eduroamの規約が更新されている場合があるため構築時点での最新情報を確認してください。

• CN(Common Name): FQDN形式。ワイルドカードは不可
• SAN(Subject Alternative Name): DNS名の登録必須
• CNとSAN: 同一の値を登録(大文字/小文字も一致)
• ハッシュアルゴリズムはSHA-256以上。SHA-1は不可

参考：GÉANT ”EAP Server Certificate considerations”

上記以外に、eduroamには不要ですがSANにIPアドレスを登録しておくと利便性が高いです。
今回は初期セットアップ時にEPS自身のCAで発行しているためCSRの作成は行っていません。
サーバー証明書のサブジェクトの設定についてはEPS自身で発行する場合も同様です。
パブリックCA等の外部CAで発行する場合、EPSでCSRを作成し、外部CAにて証明書の発行を行います。
秘密鍵を含むサーバー証明書のインポートも可能です。

参考：CSRを作成する場合の手順 (本記事ではEPS自身で発行)

EPSサービス管理画面の｢管理｣メニューから｢サーバー証明書｣を選択

｢他のCAで署名･発行する(サーバー証明書署名要求の生成)｣を選択します。

サーバー証明書のパラメーターを設定します。
｢サーバー名｣がCN、｢DNS名｣がサブジェクト別名のDNS名です。
｢IPアドレス｣は必須ではありませんが、登録していない状態でEPSの管理画面にIPアドレスで接続した際等にブラウザが警告を表示するため、登録しておいた方が汎用性が高いです。
続く画面で｢確定｣ボタンを押すと証明書要求の作成が行われます。

作成した証明書要求はシステム管理画面の｢設定｣タブ-｢サーバー証明書｣メニューからダウンロードしてください。

2. 利用者リポジトリの設定

ユーザーIDの形式について

eduroamにて使用するユーザーIDは｢所属機関のアカウント名@機関のドメイン｣の形式です。
アカウント名に何を用いるかは所属機関により異なりますが、ユーザー名か学籍番号が使われるケースが多いようです。
EPS内部にユーザーを登録する場合、ユーザーIDの形式として2つのパターンがあります。

• ”user01” のように所属機関のアカウント名のみ
• ”user01@domain.ac.jp” のようにドメイン名まで含める

どちらが推奨というものではないため、運用管理の観点から決めて良いと思います。
どちらの登録方法かによって、この後のRADIUSプロキシの設定に差異があります。

利用者アカウントの登録

本記事では学籍番号を想定してユーザーIDを"a12345"とし、識別子は含めない方式で設定します。
サービス管理画面の[利用者]-[利用者一覧]から登録を行います。

3. RADIUSプロキシ設定

RADIUSプロキシとは

RADIUSプロキシは、RADIUSサーバーがRADIUSクライアントから受けた認証要求を他のRADIUSサーバーに転送する機能です。転送するかどうかの判断には、ユーザーIDに含まれる識別子｢レルム(realm)｣を参照します。”username@domain.ac.jp”の場合は”domain.ac.jp”がレルムです。
eduroamにおいては、接続してきたユーザーのレルムが自機関のものなら自機関のRADIUSサーバーで認証、レルムが外部機関のものならeduroamのFLRにプロキシし認証結果を受け取る、という動作をしています。

RADIUSプロキシの有効化

｢有効｣、｢利用者リポジトリに存在しない場合のみ転送する｣にチェックをいれます。

プロキシ転送先の登録

サービス管理画面の[RADIUS]-[プロキシ]にて設定を行います。
ローカルはデフォルトで転送先として登録されているため、eduroamのFLRを転送先に追加します。

転送先のサーバーのアドレス、認証ポート番号、シークレットはeduroam JP(NII)への利用申請後に案内されます。
eduroamの指針に従い、アカウンティングのプロキシはしないようにアカウンティングポートは空欄とします。
参考：GÉANT ”RADIUS Accounting in eduroam”
ここでは、転送先サーバーを192.168.1.150、認証ポート番号を1812と設定します。

プロキシ識別子の登録

eduroamではプロキシの条件として、自機関の識別子の場合とそれ以外の場合の判別が必要です。
EPSの設定では、

• 未登録の識別子
• 自機関の識別子

の2つを設定します。
識別子｢なし｣の認証はローカルで処理するため設定変更は不要です。

｢未登録｣の識別子はFLRにプロキシします。ここでは｢削除せずに転送する｣を有効にし、転送先にFLRを指定してください。

｢削除せずに転送する｣が無効な場合、識別子なしのユーザーIDの認証をFLRに送るため各ユーザーの所属機関にプロキシされず認証に失敗します。

自機関の識別子”univ-a.ac.jp”を登録します。
今回はユーザーIDとして”a12345”とアカウント名部分のみを登録しているため、｢削除せずに転送する｣は無効にします。
”a12345@univ-a.ac.jp”のようにドメイン名込みで登録する場合は有効化してください。

4. RADIUSクライアントの登録

自機関ユーザーが外部機関でeduroamネットワークに接続した際はFLRから自機関EPSへ認証要求がプロキシされます。
この認証要求を受け付けるため、FLRをRADIUSクライアントとして登録します。
[RADIUS]-[NAS/RADIUSクライアント]にて下記のように登録します。

5. 補足設定

eduroamを使う上での補足設定を行います。
一般企業で使用する場合には設定不要です。

外部から受信した不要なRADIUSアトリビュートを削除する設定

外部機関のRADIUSサーバーからの認証結果の応答に何かしらのRADIUSアトリビュートが含まれていた場合に、自機関のRADIUSクライアントへの応答前に削除する設定です。
外部から受信したVLAN IDによって意図しないネットワークを割り当てようとする等のリスクを排除できます。
自機関でRADIUSアトリビュートを用いた制御を行っていない場合は設定しなくても問題ありません。
将来的にeduroamの要件として必要なアトリビュートが追加された場合は、本設定も更新が必要です。
[RADIUS]-[詳細設定]-[アドバンス設定]にて｢post-proxy.in｣を下記のように編集します。
｢DEFAULT｣以下に記載されたアトリビュートのみRADIUSクライアントに応答します。

<%
  local enable_post_proxy = true
%>

<% if enable_post_proxy then %>
DEFAULT
    EAP-Message =* ANY,
    Message-Authenticator =* ANY,
    MS-MPPE-Recv-Key =* ANY,
    MS-MPPE-Send-Key =* ANY,
    State =* ANY

<% end -- enable_post_proxy %>

不要なRADIUSアトリビュートをeduroam側に応答しないための設定 

自機関ユーザーが外部機関で接続しRADIUSプロキシされてきた認証要求に対して、eduroamのFLRへの認証結果の応答からノイズとなるアトリビュートを削除するための設定です。
[RADIUS]-[詳細設定]-[アドバンス設定]にて｢default.in｣を編集します。
設定ファイル中の｢post-auth { ｣直下に以下を追記します。

    if (&Client-Shortname == "RADIUSクライアント登録名1" || &Client-Shortname == "RADIUSクライアント登録名2") { 
        update reply {
            Filter-ID !* ANY
            Session-Timeout !* ANY
            Tunnel-Type !* ANY
            Tunnel-Medium-Type !* ANY
            Tunnel-Private-Group-Id !* ANY
        }
    }

｢RADIUSクライアント登録名｣はEPSにNAS/RADIUSクライアントとして登録したFLRの名前です。
｢update reply { ｣のセクションが削除するアトリビュートです。
追記後の設定は以下のようになります。

  post-auth {
    if (&Client-Shortname == "RADIUSクライアント登録名1" || &Client-Shortname == "RADIUSクライアント登録名2") { 
        update reply {
            Filter-ID !* ANY
            Session-Timeout !* ANY
            Tunnel-Type !* ANY
            Tunnel-Medium-Type !* ANY
            Tunnel-Private-Group-Id !* ANY
        }
    }
    if ( &session-state:Framed-MTU ) {
    update session-state {
        &Framed-MTU !* ANY
                    (以下省略)

認証ログにeduroamのアトリビュートを表示するための設定

｢eduroamコンプライアンス･ステートメント｣には、記録する認証ログに関して以下の条件が記載されています。

• 認証要求とそれに対応する応答のタイムスタンプ
• 認証要求における外部 EAP アイデンティティ(User-Name 属性)
• 内部 EAP アイデンティティ(実際のユーザの識別子)
• 接続しているクライアントの MAC アドレス(Calling-Station-Id 属性)
• Operator-Name 属性が存在すれば、訪問先 SP
• eduroam-SP-country 属性が存在すれば、認証要求の訪問国
• 認証応答のタイプ(すなわち、Accept または Reject)

このうち、Operator-Nameとeduroam-SP-countryは認証ログに記録されないため、記録するための設定が必要です。
ここでのSP(サービスプロバイダー)は認証要求の送信元の外部機関を指します。
アドバンス設定の｢radiusd.conf.in｣の｢msg_goodpass｣｢msg_badpass｣をそれぞれ下記に置き換えます。

msg_goodpass = "request parameters(NAS-Identifier=%{NAS-Identifier},NAS-IP-Address=%{NAS-IP-Address},Packet-Src-IP-Address=%{Packet-Src-IP-Address},Operator-Name=%{Operator-Name},eduroam-SP-country=%{eduroam-SP-country}%{NAEPS-Client-Cert-Info})"

msg_badpass = "request parameters(NAS-Identifier=%{NAS-Identifier},NAS-IP-Address=%{NAS-IP-Address},Packet-Src-IP-Address=%{Packet-Src-IP-Address},Operator-Name=%{Operator-Name},eduroam-SP-country=%{eduroam-SP-country}%{NAEPS-Client-Cert-Info})"

上記はEPSのデフォルトのログ形式にeduroam用の属性を追加したものです。
参考として、eduroamのFreeRADIUS用サンプル設定に記載されていたログ形式は下記です。

• msg_goodpass = "(O-N: %{Operator-Name}, NAS-ID: %{NAS-Identifier}, SID: %{Called-Station-Id}, CUI: %{reply:Chargeable-User-Identity})"
• msg_badpass = "(O-N: %{Operator-Name}, NAS-ID: %{NAS-Identifier}, SID: %{Called-Station-Id})"

ログの保管について

eduroamでは、少なくとも3か月の認証ログの保管が必要とされています。
参考：https://eduroam.org/wp-content/uploads/2025/07/eduroam_Compliance_Statement_v2-FINAL.pdf

どの程度のログを保管できるかはそれぞれの環境次第ですが、EPS SXモデル/STモデルはログの長期保管を前提としていないため、外部Syslogサーバーへの転送を推奨します。
なお、EPSはデフォルトではアカウンティング機能が無効となっているため、自機関でアカウンティングログを取得したい場合は有効化を行ってください。

FLRの設定

FLRはeduroam JPの管理するサーバーのため、実際のeduroam利用にあたっては設定不要です。

1. RADIUSクライアント登録

自機関EPSからプロキシされた認証要求を受け付けるためRADIUSクライアントとして登録します。

2. RADIUSプロキシ設定

プロキシ転送先の設定

自機関EPSから受けた認証を外部機関RADIUSにプロキシするため、外部機関RADIUSを転送先に登録します。

プロキシ識別子の設定

外部機関の識別子として”univ-b.ac.jp”を登録します。

外部RADIUSの設定

概要

設定についての考え方は自機関EPSと同様です。
同様の設定をすれば自機関ユーザーが外部機関でeduroamネットワークに接続した場合を想定した検証も可能です。
今回の検証にあたっては、FLRからプロキシされた認証に応答するための最低限となる下記2点を設定します。

利用者アカウントの登録

外部機関のユーザーは”b98765”とします。

RADIUSクライアントの登録

FLRからの認証要求に応答します。

まとめ

本記事ではeduroam環境を想定したEPSの構築方法について解説いたしました。
お客様環境に合わせて

• 自機関ローカルネットワークへの接続とeduroamネットワークへの接続のRADIUSサーバーを兼用したい
• 自機関のユーザーDBとしてAD/LDAPサーバーを使用したい
• 自機関ユーザーに対してVLAN IDの応答等の制御を行いたい

等のご要件にも対応可能です。
実際の対応可否はお客様環境やご要件の内容にもよりますので是非お問い合わせください。