| Name | FreeRadius |
|---|---|
| Deployed on | sown-auth |
| Website | http://www.freeradius.org/ |
Freeradius is an open source software for the authentication of dialed-in users. SOWN uses it for the authentication of its users.
Contents |
The server is configured to listen on ports 1812 and 1813 for authentication and accounting (respectivelly) and is accessible by any SOWN[at]HOME node. As SOWN has a peering arangement with ECS, our RADIUS server hands off any non SOWN accounts to them to process as either University of Southampton accounts and/or eduroam accounts.
SOWN uses radius for authentication of its Captive Portal system as well as authentication of 802.1x requests.
For security reasons, SOWN stores Community Account passwords as a salted hash. This prevents them from being compromised. Under Captive Portal conditions where the password sent is not hashed, this is fine. However when using RADIUS for authentication of 802.1X requests, this causes problems.
Due to the above SOWN Community Accounts attempting to use 802.1X authentication can only use EAP types that support PAP. Work is currently underway to make use of ntlm_auth as a mechanism for allowing more EAP types, including the Microsoft Windows default of PEAP.
Eduroam and University of Southampton users are unaffected by the above constraints and may use whatever mechanism which is supported by their Home institution.
The encryption mechanism used traditionally by SOWN is based on the Unix PAM system. We keep unix shadow files with authentication information.
As of FreeRadius 3.0.1 the configuration requirements for this changed, as you can no longer specify the location of shadow type files in the unix module. see [1]'
${confdir}/modules/myshadow
passwd myshadow {
filename = /etc/freeradius/shadow
format = "*User-Name:Crypt-Password::Group:::::"
hashsize = 100
authtype = PAP
}
${confdir}/sites-enabled/default
authorize {
...
myshadow
...
}
Nb. SOWN's configuration is currently being migrated to LDAP so this will eventually become defunct
The SOWN captive portal authenticates users by determining the realm from the dropdown box, and handing off authentication to the relevant Radius server - either to ECS for eduroam and/or ECS Wireless accounts, or ISS ldap for any @soton.ac.uk accounts.
For 802.1x SOWN makes use the radius proxy module. This determines the realm from the authentication EAP message, and either handles it locally (for SOWN community accounts), or passes it off to a higher authority for non local realms.
ECS radius can handle all other requests, as they peer with ISS ORPS for soton authentication, and ISS peer with JANET NRPS for eduroam authentication.
proxy.conf configures the settings for how to go about doing this.
There are 2 ecs radius servers. These are configured as home servers :
home_server ecs1 {
type = auth
ipaddr = ecs-radius1-dmz-ip
port = 1645
response_window = 20
zombie_period = 40
secret = sown's_radius_secret
revive_interval = 120
status_check = status-server
num_answers_to_alive = 3
}
home_server ecs2 {
type = auth
ipaddr = ecs-radius2-dmz-ip
port = 1645
response_window = 20
zombie_period = 40
secret = sown's_radius_secret
revive_interval = 120
status_check = status-server
num_answers_to_alive = 3
}
These are then assigned to a pool of query servers
home_server_pool ecs {
type = fail-over
home_server = ecs1
home_server = ecs2
}
Next in the configuration are the realms. There are 3 events to handle here.
realm sown.org.uk {
authhost = LOCAL
}
realm NULL {
authhost = LOCAL
}
realm DEFAULT {
auth_pool = ecs
}
For compliance with the Eduroam TOS Sown-auth should be globally pingable and be available on port 1812 to the next server in the chain which it is under the current network configuration.
The underlying code for logging in SOWN is taken from code produced by the University of Bristol with special regard for Appendix A [1]
Under JRS Terms of Service, RADIUS logs for outbound packets and inbound packets should be logged for 3-6 months after authentication occurs.
Logging is ordered by date and logs are rotated hourly. This has the benefit of making the cleanup of logs more simple, and aids in the rapid location of pertinent files.
For logging the following needs to be added The following changes need to be made Accounting_Log will not exist by default
raddb/Modules/accounting_log
detail accounting_log {
detailfile = ${radacctdir}/%Y%m%d/accounting-detail-%H:00
header = "%{Packet-Src-IP-Address} - %t"
detailperm = 0600
}
raddb/sites-enabled/default
accounting {
...
accounting_log
...
}
raddb/Modules/auth_log
detail auth_log {
detailfile = ${radacctdir}/%Y%m%d/request-detail-%H:00
detailperm = 0600
header = "%{Packet-Src-IP-Address} - %t"
log_packet_header = yes
suppress {
User-Password
}
}
raddb/sites-enabled/default
authorize {
...
auth_log
...
}
detail reply_log { detailfile = ${radacctdir}/%Y%m%d/reply-detail-%H:00 header = "%{Packet-Src-IP-Address} - %t" detailperm = 0600 } post-auth { ... reply_log Post-Auth-Type REJECT { ... reply_log } }
Required for JRS peering - Logs all packets that are sent up to ECS Radius raddb/Modules/pre_proxy_log
detail pre_proxy_log {
detailfile = ${radacctdir}/%Y%m%d/pre-proxy-detail-%H:00
detailperm = 0600
header = "%{Packet-Src-IP-Address} - %t"
suppress {
User-Password
}
}
raddb/sites-enabled/default
pre-proxy {
...
pre_proxy_log
}
Deugging scripts. raddb/Modules/post_proxy_log
detail post_proxy_log {
detailfile = ${radacctdir}/%Y%m%d/post-proxy-detail-%H:00
header = "%{Packet-Src-IP-Address} - %t"
detailperm = 0600
}
raddb/sites-enabled/default
post-proxy {
...
post_proxy_log
}
[1] JNT Association, A Case Study in Complying with the JANET Roaming Service Technical Specifi cation, published JNT 2006, available from http://www.ja.net/documents/services/janet-roaming/jrs-compliance-case-study.pdf accessed August 2008