Technical Requirements for eduroam Deployment¶

This document summarizes the minimum technical and operational requirements for running eduroam as an Identity Provider, Service Provider, or both.

Institutional Prerequisites¶

Before deployment, an institution should have:

• public IP connectivity for RADIUS peers where required
• a domain name and published realm under institutional control
• operational ownership for systems, wireless, and security
• 24x7 service support or a clear escalation model
• acceptable use, incident response, and retention policies

1. Wireless Network Requirements¶

Access points and controllers must support:

• SSID exactly set to eduroam
• IEEE 802.1X
• WPA2-Enterprise and preferably WPA3-Enterprise
• AES-CCMP
• RADIUS authentication and accounting
• dynamic VLAN or role assignment

eduroam must not use captive portals.

Coverage and Capacity¶

Plan AP placement for:

• lecture rooms and classrooms
• libraries and laboratories
• offices
• common areas and residences where offered
• high-density event spaces

Capacity planning should consider:

• concurrent devices per user
• roaming behavior
• video and collaboration traffic
• building materials and RF attenuation
• uplink and PoE capacity

Network Segmentation¶

Recommended segmentation:

Keep eduroam clients away from management and sensitive internal subnets unless explicitly required by policy.

2. RADIUS Infrastructure¶

Most institutions deploy FreeRADIUS 3.x. The RADIUS environment should provide:

• EAP processing for local users
• proxying for foreign realms
• logging and accounting
• TLS certificate support
• policy enforcement for VLANs or roles

FreeRADIUS Architecture¶

Typical FreeRADIUS 3.x components:

• mods-enabled/eap for EAP processing
• mods-enabled/ldap or mods-enabled/sql for identity lookup
• proxy.conf or modular proxy definitions for realm forwarding
• clients.conf for NAS definitions
• sites-enabled/default and sites-enabled/inner-tunnel for request processing

Do not remove default and inner-tunnel without understanding the virtual server flow. For most deployments, clone and tailor them or keep the packaged structure and apply site-specific policy.

RADIUS Ports¶

Allow as required:

• UDP 1812 for authentication
• UDP 1813 for accounting

Some legacy devices use 1645 and 1646, but new deployments should standardize on 1812 and 1813.

3. Server Specifications¶

Sizing depends on user population and accounting volume. A practical baseline for a small to medium institution is:

• 2 to 4 vCPU
• 4 to 8 GB RAM
• 60 GB or more of resilient storage
• 1 Gbps network interface
• current LTS Linux distribution supported by FreeRADIUS 3.x packaging

For production, deploy at least two instances where possible.

4. Identity Store Requirements¶

An IdP must authenticate users against a reliable identity source such as:

• Microsoft Active Directory
• OpenLDAP or 389 Directory Server
• institutional SQL-backed identity database
• Google Workspace via an approved bridging design or external identity sync process

Important requirements:

• unique user identifiers
• secure password handling
• clear account lifecycle management
• reliable group membership data for policy decisions
• sufficient availability for authentication traffic

Username and Realm Format¶

Users should authenticate with a realm-qualified identity, for example:

username@institution.ac.ke

Separate staff and student realms may be used, for example:

username@institution.ac.ke
username@students.institution.ac.ke

Separate realms do not require separate IdP servers. Policy can be based on:

• realm
• LDAP or AD group
• SQL attributes
• returned RADIUS reply items

5. Accounting and SQL¶

SQL accounting is strongly recommended for production deployments.

Typical implementation:

• MySQL or MariaDB backend
• radacct table for accounting records
• interim updates every 5 to 10 minutes
• retention aligned with institutional policy

Track at least:

• start and stop events
• session duration
• octet counters
• AP or controller identity
• client MAC address
• assigned IP address
• realm

6. Security and Operations¶

Production readiness should include:

• strong per-client shared secrets
• restricted firewall policy
• certificate renewal planning
• configuration validation using freeradius -XC
• debug and test procedures
• backups for configuration, SQL, and certificates
• monitoring for service health and certificate expiry

7. High Availability¶

Recommended resilience measures:

• two or more FreeRADIUS servers
• AP/controller configuration with multiple RADIUS servers
• SQL replication or resilient managed database platform
• load balancer or DNS-based distribution where appropriate
• routine failover testing