Contents
Freeradius 1.x konfigurálás
FreeRadius installáció
Installáljuk fel a kiszemelt Radius gépre a FreeRadius csomagot.
Access point konfiguráció
Feltételezve, hogy az Eduroamhoz használt access point IP címe a.b.c.d akkor a clients.conf fájlba a következőket kell írni:
client a.b.c.d {
secret = <a secret password>
shortname = <a name for your wireless AP>
}A secret password-nak meg kell egyeznie a secret password-el amit a wireless access point-on konfiguráltunk ehhez a radius szerverhez.
EAP mód konfiguráció
EAP/TTLS konfiguráció
Az eap.conf fájlba a következőket kell beírni:
eap {
default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
tls {
private_key_file = <path to a private key for your Radius server>
certificate_file = <path to the corresponding certificate file for the Radius server>
CA_file = <path to the file containing the certificate of the Certificate Authority>
dh_file = ${raddbdir}/certs/dh
random_file = /dev/urandom
fragment_size = 1024
include_length = yes
copy_request_to_tunnel = no
use_tunneled_reply = no
}
ttls {
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = no
}
}Tanusítványt ugyanúgy lehet szerezni pl. az NIIF CA-tól mint EAP/TTLS esetében. Az, hogy az NIIF CA-tól legyen tanusítvány nem követelmény, mivel ezt a tanusítványt csak helyi felhasználók authentikációjakor fogja a rendszer használni a TLS tunnnel kiépítésekor. NIIF CA-tól beszerzett tanusítvány ajánlott, mert az együttmüködési tesztek könnyebben mennek és a felhasználóknak csak 1 gyökér tanusítványt kell telpíteniük.
Az TLS szekció pontos kitöltése nagyon fontos, különben nem fog müködni az authentikáció, mivel a TTLS a TLS helyes müködésére épít.
Az EAP-MD5 authentikáció alkalmazása nem ajánlott alapesetben, de mivel az authentikáció WPA/WPA2 segítségével és TLS tunnelben történik ezért elég megbizhatónak számít. Az egyéb lehetséges beállítások: CHAP, MSCHAPv2 ebben az esetben az authentikációs adatbázisban nyíltan kell tárolni a jelszavakat.
PEAP konfiguráció
Az eap.conf fájlba a következőket kell beírni:
eap {
default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
tls {
private_key_file = <path to a private key for your Radius server>
certificate_file = <path to the corresponding certificate file for the Radius server>
CA_file = <path to the file containing the certificate of the Certificate Authority>
dh_file = ${raddbdir}/certs/dh
random_file = /dev/urandom
fragment_size = 1024
include_length = yes
copy_request_to_tunnel = no
use_tunneled_reply = no
}
# The PEAP module needs the TLS module to be installed
# and configured, in order to use the TLS tunnel
# inside of the EAP packet. You will still need to
# configure the TLS module, even if you do not want
# to deploy EAP-TLS in your network. Users will not
# be able to request EAP-TLS, as it requires them to
# have a client certificate. EAP-PEAP does not
# require a client certificate.
#
peap {
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
default_eap_type = mschapv2
}
}Tanusítványt ugyanúgy lehet szerezni pl. az NIIF CA-tól mint EAP/TTLS esetében. Az, hogy az NIIF CA-tól legyen tanusítvány nem követelmény, mivel ezt a tanusítványt csak helyi felhasználók authentikációjakor fogja a rendszer használni a TLS tunnnel kiépítésekor. NIIF CA-tól beszerzett tanusítvány ajánlott, mert az együttmüködési tesztek könnyebben mennek és a felhasználóknak csak 1 gyökér tanusítványt kell telpíteniük.
Az TLS szekció pontos kitöltése nagyon fontos, különben nem fog müködni az authentikáció, mivel a PEAP a TLS helyes müködésére épít.
A Tunnelen belül MSCHAPv2 authentikációt alkalmazzunk, mert így a Windows XP felhassználóknak nem kell újabb supplicant-et telpíteniük. MSCHAPv2 esetében az authentikációs adatbázisban nyíltan kell tárolni a jelszavakat.
Proxy konfiguráció
A proxy.conf fájlba a következöket kell beírni:
realm UP {
type = radius
authhost = radius1.eduroam.hu:1812
accthost = radius1.eduroam.hu:1813
secret = <shared secret with HU radius server>
nostrip
}
realm UP {
type = radius
authhost = radius2.eduroam.hu:1812
accthost = radius2.eduroam.hu:1813
secret = <shared secret with HU radius server>
nostrip
}Illetve a clients.conf fájlba:
client 195.111.98.4 {
secret = <shared secret with HU radius server>
shortname = radius1.eduroam.hu
}
client 195.111.98.12 {
secret = <shared secret with HU radius server>
shortname = radius2.eduroam.hu
}
Freeradius modul és authentikáció konfiguráció
LDAP authentikációs adatbázis esetén
A radiusd.conf fájlban a következő modulok helyesen legyenek konfigurálva
modules {
...
ldap {
server = <"myldap.domain.hu">
identity = <"cn=admin,dc=domain,dc=hu">
password = <admin bind password>
basedn = <"ou=people,dc=domain, dc=hu”>
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
# If your LDAP server supports TLS you should use it
start_tls = yes
tls_cacertfile = <path to the certificate of the CA of your LDAP server certificate>
tls_randfile = /dev/urandom
# Itt szabályozható, hogy kinek van Eduroam hozzáférése
access_attr = "dialupAccess"
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
# Itt tároljuk a jelszavakat
password_attribute = userPassword
}
.....
$INCLUDE ${confdir}/eap.conf
.....
}
....
authorize {
preprocess
auth_log
eap
files
ldap
}
...
authenticate {
Auth-Type PAP {
pap
}
Auth-Type LDAP {
ldap
}
eap
}
password authentikációs adatbázis esetén
modules {
#
unix {
#
#
# Define the locations of the normal passwd, shadow, and
# group files.
# To force the module to use the system password functions,
# instead of reading the files, leave the following entries
# commented out.
#
# This is required for some systems.
#
# passwd = /etc/passwd
# shadow = /etc/shadow
# group = /etc/group
#
radwtmp = ${logdir}/radwtmp
}
passwd etc_group {
filename = /etc/group
format = "=Group-Name:::*,User-Name"
hashsize = 50
ignorenislike = yes
allowmultiplekeys = yes
delimiter = ":"
}
authenticate {
Auth-Type PAP {
pap
}
eap
}
mySQL authentikációs adatbázis esetén
modules {
...
$INCLUDE ${confdir}/sql.conf
...
}
....
authorize {
preprocess
auth_log
eap
sql
files
}
...
authenticate {
Auth-Type PAP {
pap
}
eap
}
...Az sql.conf fájlban, amennyiben a Postfilter csomagra és annak az autentikációs adatbázisára támaszkodunk, a következő beállításokat használjuk:
sql {
driver = "rlm_sql_mysql"
server = "mysql-server-host"
login = "sql-user"
password = "sql-user-password"
radius_db = "postfilter"
# vagy postfilter_replicated adatbázis replikált mySQL szerver esetében
...
authcheck_table = "user"
authreply_table = "user"
...
sql_user_name = "%{User-Name}"
...
authorize_check_query = "SELECT _userid, _address, \
'Password', _passwd, '==' \
FROM ${authcheck_table} \
WHERE _address = '%{SQL-User-Name}' \
AND _passwd != '' \
ORDER BY _userid"
authorize_reply_query = "SELECT _userid, _address, \
'foo', 'foo', '==' \
FROM ${authcheck_table} \
WHERE _address = '__never_ever_match__'"
authorize_group_check_query = "SELECT _userid, _address, \
'foo', 'foo', '==' \
FROM ${authcheck_table} \
WHERE _address = '__never_ever_match__'"
authorize_group_reply_query = "SELECT _userid, _address, \
'foo', 'foo', '==' \
FROM ${authcheck_table} \
WHERE _address = '__never_ever_match__'"
...
}
Azonosítók feldolgozása
A users fájlban kell feldolgozni a bejövő kéréskeket és a szétdobálni a megfelelő radius proxy-knak: Minden userre illeszkedő szabályokat DEFAULT szabályokkal lehet csinálni:
pl. ha a felhasználó benne van a noradius group-ban (passwordos authentikáció) akkor nem használhatja a radius authentikációt:
DEFAULT Group == "noradius", Auth-Type := Reject
Reply-Message = "Your account has been disabled."pl. minden ami nem illeszkedik a domain1.hu-ra vagy domain2.hu ra el kell küldeni a felsőbb szintű proxynak, és ne is probálkozzon tovább a defualt bejegyzésekkel:
DEFAULT User-Name =~ "@", User-Name !~ "[\@\.]domain1.hu$|[\@\.]domain2.hu$", Proxy-To-Realm:= UP
Fall-Through = NoDebughoz hozzunk létre egy felhasználót:
#teszt uesr for debugging
debug User-Password == "nagyon titkos jelszo"
Reply-Message = "Hello, %u, debug usage only!",
Fall-Through = noAz összes többi felhasználót helyileg authentikáljuk - suffix kezelést helyesen be kell állítani!!!:
DEFAULT Auth-Type = System
Fall-Through = 1
FreeRADIUS 2.x konfigurálás
FreeRADIUS telepítés
Installáljuk fel a kiszemelt gépre a FreeRADIUS csomagot.
Authentikáció konfigurálása
RADIUS kliensek felvétele
Feltételezve, hogy az eduroamhoz használt access point IP címe a.b.c.d, a clients.conf fájlba a következőket kell írni:
client a.b.c.d {
secret = <a secret password>
shortname = <a name for your wireless AP>
virtual_server = wlan
}A secret password beállításnak meg kell egyeznie a wireless access pointon konfigurált RADIUS jelszóval.
A virtual_server beállítás használata tisztábbá teszi a FreeRADIUS konfigurációt. Segítségével elkülönítve kezelhetjük a RADIUS szerverben az adott klienseket a RADIUS szerver többi kliensétől, azaz pl. a WLAN access pointoktól érkező és mondjuk egy webes alkalmazástól érkező RADIUS kérésekre vonatkozó beállítások külön adhatók meg. Egyik kliens csoport beállításainál sem kell felkészülni a másik csoporttól érkező kérésekre, mert azok a FreeRADIUS-on belül külön virtuális szerverre vagy site-ra érkeznek, így pl. külön users file használható mindegyik virtuális szerveren, amiben már nem kell a RADIUS kliens IP címe alapján dönteni a küldendő válaszról.
Több access point esetén, ha azok egy IP subnetben vannak, ugyanazt a RADIUS jelszót használják, és az adott IP subnetben nincs ennek a RADIUS szervernek más kliense, egyszerűsíthető a konfiguráció. Ilyenkor a fenti beállításokat nem kell access pointonként megismételni, hanem elegendő subnetenként, a subnet prefixet megadva:
client a.b.c.d/m {
secret = <a secret password>
shortname = <a name for your wireless AP group>
virtual_server = wlan
}Mivel az eduroamban RADIUS kliensként jelennek meg az autentikációs hierarchia fastruktúrájában velünk szomszédos RADIUS szerverek is, azokat is fel kell venni a kliensek közé. Az eduroam RADIUS szomszédoktól érkező kéréseket jellemzően másképp kezeljük, mint a saját WLAN access pointjainktól érkezőket. (Pl. a fa gyökere felől érkező kéréseket soha sem proxyzzuk vissza a fa gyökere felé, míg az access pointoktól érkezőket lehet, hogy a fa gyökere felé küldjük tovább.) Ezért praktikus a RADIUS szomszédokat egy külön virtuális szerverbe tenni.
A fenti példákat folytatva legyen tehát az access pointjaink virtuális szervere a wlan nevű, az eduroam RADIUS szomszédoké pedig az eduroam. Magyaroszági eduroam tagintézményként ezek a szomszédok a hu RADIUS szerverei lesznek:
client 195.111.98.4 {
secret = <shared secret with HU radius server>
shortname = hu1
virtual_server = eduroam
}
client 195.111.98.12 {
secret = <shared secret with HU radius server>
shortname = hu2
virtual_server = eduroam
}
EAP mód konfiguráció
Lásd fent, FreeRADIUS 1.x-nél.
Proxy konfiguráció
A proxy.conf fájlban csak a hierarchikus fastruktúrában lévő szomszéd csomópontokba tartozó RADIUS szervereket kell megadnunk, ill. az egyes csoportokon belüli szerverek kezelését. Azt, hogy az egyes RADIUS kérések továbbítása, proxyzása hova történjen, nem itt adjuk meg, hanem majd más beállításoknál hivatkozunk az itt definiált csoportokra.
Magyarországi eduroam tagintézmény esetén jellemzően egy szomszédja van a fában az intézménynek, ez pedig a hu csomópont, amibe a két fent említett RADIUS szerver tartozik. Ezt a szomszédot nevezzük el UP realmnek (a hierarchia teteje irányában lévő szomszédunk)!
A proxy.conf fájlba a következöket kell beírni:
proxy server {
default_fallback = no
}
home_server hu1 {
type = auth+acct
ipaddr = 195.111.98.4
port = 1812
secret = <shared secret with HU radius server>
status_check = none
}
home_server hu2 {
type = auth+acct
ipaddr = 195.111.98.12
port = 1812
secret = <shared secret with HU radius server>
status_check = none
}
home_server_pool eduroam_up_pool {
type = fail-over
home_server = hu1
home_server = hu2
}
realm UP {
pool = eduroam_up_pool
nostrip
}
realm LOCAL {
}
FreeRADIUS virtuális szerverek
Az egyszerűség kedvéért ebben a példában text file felhasználói adatbázist használunk. Először elkészítjük a valós felhasználóink adatbázisát, majd ebből a virtuális szerverek által használt felhasználói adatbázisokat, és végül magukat a virtuális szervereket.
A valós felhasználóinkat tartalmazó wlan-user-list nevű file:
user1@staff.egyetem.hu Cleartext-Password := "jelszo1"
Fall-Through = No
user2@staff.egyetem.hu Cleartext-Password := "jelszo2"
Fall-Through = No
user3@student.egyetem.hu Cleartext-Password := "jelszo3"
Fall-Through = NoA wlan nevű virtuális szerver (amit a saját access pointjaink használnak) felhasználói adatbázisa egyezzen meg a valós felhasználók adatbázisával! Ezt tegyük a users-wlan file-ba:
$INCLUDE /usr/local/etc/raddb/wlan-user-list
Az eduroam nevű virtuális szerver (amit a hierarchiában velünk szomszédos RADIUS szerverek használnak) felhasználói adatbázisába pedig szintén tegyük bele a saját felhasználóinkat, és egy teszt felhasználót, amivel a RADIUS kapcsolatot ellenőrizni lehet! Ez kerüljön a users-eduroam file-ba:
#teszt uesr for debugging
debug@egyetem.hu Cleartext-Password := "titkosjelszo"
Reply-Message = "Hello, %u, debug usage only!",
Fall-Through = no
$INCLUDE /usr/local/etc/raddb/wlan-user-listEzzel megvan a két szöveges RADIUS felhasználói adatbázisunk. A hagyományos users file helyett az eduroam virtuális szerver a users-eduroam, a wlan nevű virtuális szerver pedig a users-wlan nevű felhasználói adatbázist fogja használni. Hogy ezekre hivatkozni tudjunk a megfelelő virtuális szerverekben, fel kell vennünk őket a FreeRADIUS szöveges felhasználói adatbázisai közé, a modules/files nevű file-ba:
...
files {
...
usersfile = ${confdir}/users
...
}
...
files files-wlan {
usersfile = ${confdir}/users-wlan
acctusersfile = ${confdir}/acct_users
preproxy_usersfile = ${confdir}/preproxy_users
compat = no
}
files files-eduroam {
usersfile = ${confdir}/users-eduroam
acctusersfile = ${confdir}/acct_users
preproxy_usersfile = ${confdir}/preproxy_users
compat = no
}
...Ezáltal a files kulcsszó helyett alkalmazható lesz a konfigurációban a files-wlan ill. a files-eduroam, ami users file helyett a users-wlan ill. a users-eduroam szöveges adatbázist fogja használni.
Magát a virtuális szervert a raddb/sites-available könyvtárban a default file alapján hozhatunk létre. Készítsünk belőle itt egy másolatot a virtuális szerver nevén, és tegyük a teljes tartalmát server <név> alá! A használatba vételhez az új állományt a raddb/sites-enabled könyvtárba kell tenni, praktikusan egy szimbolikus link készítésével.
A wlan virtuális szerver a defaulttól két lényeges dologban tér el:
- a users-eduroam felhasználói adatbázist használja
- a más intézményhez tartozó felhasználók kéréseit a hierarchiában felfele továbbítja
Ez utóbbi, proxy funkció az authorize szakaszban nagyon egyszerűen megvalósítható egy unlang scripttel, ami a FreeRADIUS belső Proxy-To-Realm attribútumát teszi rá a kérésre, ezzel irányítva azt tovább a proxy.conf file-ban definiált UP realmhez.
A raddb/sites-available/wlan a fentieknek megfelelően így néz ki:
server wlan {
authorize {
...
if( User-Name =~ /\@/ ) {
if( User-Name !~ /[\@\.]egyetem.hu$/ ) {
update control {
Proxy-To-Realm := UP
}
}
}
files-wlan
...
}
authenticate {
...
}
preacct {
...
files-wlan
}
accounting {
...
}
session {
...
}
post-auth {
...
}
pre-proxy {
...
}
post-proxy {
...
}
}A raddb/sites-available/eduroam hasonló, de itt egyrészt nincs proxyzás (hiszen az intézményünk a fastruktúra levele, azaz nem jöhet szomszédos RADIUS szervertől olyan kérés, amit továbbítanunk kellene), másrészt a teszt felhasználót is tartalmazó users-eduroam felhasználói adatbázist kell használni:
server eduroam {
authorize {
...
files-eduroam
...
}
authenticate {
...
}
preacct {
...
files-eduroam
}
accounting {
...
}
session {
...
}
post-auth {
...
}
pre-proxy {
...
}
post-proxy {
...
}
}
Naplózás konfigurálása
Authentikáció egyszerű naplózása
Első lépésként a radiusd.conf-ban kell beállítani az authentikáció naplózását:
log {
destination = files
file = ${logdir}/radius.niif.log
stripped_names = no
auth = yes
auth_badpass = no
auth_goodpass = no
}
Sikeres bejelentkezések
Ez sikeres authentikációkor pl. EAP-TTLS/PAP használata esetén a következő naplóbejegyzéseket generálja:
<idő> : Auth: Login OK: [felhasznalo@egyetem.hu] (from client <client-short-name> port 0 via TLS tunnel) <idő> : Auth: Login OK: [anonymous@egyetem.hu] (from client <client-short-name> port 0 cli <client-MAC>) <idő> : Auth: Login OK: [felhasznalo@egyetem.hu] (from client <client-short-name> port 0 via TLS tunnel) <idő> : Auth: Login OK: [anonymous@niif.hu] (from client <client-short-name> port 0 cli <client-MAC>)
A fenti első két bejegyzés az intézmény felhasználójának otthoni hálózatában történő csatlakozásakor keletkezik, ezekben a <client-short-name> tehát a clients.conf-ban a helyi WLAN access pointnál megadott shortname. A második két bejegyzés az intézmény felhasználójának más intézményben történő sikeres bejelentkezése esetén keletkezik, ilyenkor a <client-short-name> a fenti példa beállításokat használva hu1 vagy hu2.
Vendég felhasználó sikeres bejelentkezésekor csak egy naplóbejegyzés készül, a külső azonosítóval, hiszen a belső azonosító a vendéglátó intézményben nem látszik.
<idő> : Auth: Login OK: [anonymous@masikintezmeny.hu] (from client <client-short-name> port 0 cli <client-MAC>)
Sikeres bejelentkezések
Sikertelen bejelentekzési kísérletkor több lehetőség van.
Ha az intézmény felhasználója a saját intézményében próbálkozik sikertelenül, akkor a sikereshez hasonlóan két naplóbejegyzés is keletkezhet, és a bejegyzés from client utáni azonosítójából látható, hogy helyben történt a próbálkozás:
<idő> : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [felhasznalo@egyetem.hu] (from client wlan-ap port 0 via TLS tunnel) <idő> : Auth: Login incorrect: [anonymous@egyetem.hu] (from client wlan-ap port 0 cli <client-MAC>)
Ha az intézmény felhasználója másik intézményben próbál bejelentkezni sikertelenül, de a külső azonosító megfelelő és az eduroam RADIUS proxyk jól működnek, akkor a fentihez hasonló bejegyzések keletkeznek (természetesen más from client résszel).
Ha az intézmény felhasználója másik intézményben sikertelenül próbál belépni, és a külső azonosító nem megfelelő, vagy a RADIUS proxy hierarchiában van probléma, akkor erről nem keletkezik naplóbejegyzés, hiszen az authentikációs kérés nem is jut el a saját intézményig.
Ha vendég felhasználó próbál sikertelenül bejelentkezni, és a kérést a saját intézménye (vagy út közben egy másik RADIUS) utasítja el, akkor az alábbi formájú naplóbejegyzés keletkezik:
<idő> : Auth: Login incorrect (Home Server says so): [anonymous@masikintezmeny.hu] (from client wlan-ap port 0 cli <client-MAC>)
Ha pedig a vendég felhasználó az otthoni RADIUS hibája, elérhetetlensége, vagy egy útba eső RADIUS proxy elérhetetlensége miatt nem tud bejelentkezni, akkor egy másik fajta hibaüzenet utal erre (az újraküldések miatt várhatóan néhány példányban, különböző azonosítókkal):
<idő> : Error: No response to status check <id> for home server <IP-address> port <UDP-port>
Authentikáció részletes naplózása
Az előző fejezetben leírtnál részletesebb naplózás a FreeRADIUS detail moduljával lehetséges. Ez a modul a RADIUS csomagok dekódolt formáját rögzíti ASCII állományokba. A standard FreeRADIUS beállítások közt szerepel az alap detail modul (modules/detail), ami a RADIUS accounting csomagok kiírására van beállítva. Az authentikációs csomagok rögzítésére a detail modul auth_log, pre_proxy_log, post_proxy_log, valamint reply_log példányai vannak beállítva (mind a modules/detail.log file-ban). Ez utóbbi négy detail példány használható az authentikáció naplózásához, a FreeRADIUS alapbeállításának koncepciója szerint mindegyik az authentikációs folyamat más-más pontján naplózza a RADIUS csomagokat, és mind külön file-okba.
A RADIUS serverünkhöz beérkező auth csomagot a kérdéses virtuális server authorize szekciójában meghívott auth_log példány naplózza. Ha ezt a csomagot továbbküldjük az eduroam RADIUS hierarchiában egy másik RADIUS servernek, akkor a kiküldött csomagot a pre-proxy szekciójába felvett pre_proxy_log példány hívása naplózza. A szomszéd RADIUS servertől érkező választ ezután a post-proxy szekció post_proxy_log hívása rögzíti. Végül a serverünk által az eredeti kérésre kimenő választ a post-auth szekció reply_log hívása rögzíti.
Tipikus intézményi RADIUS esetén
- a helyi WLAN access pointokat kiszolgáló virtuális serveren mind a négy detail példányt érdemes beállítani,
az inner-tunnel virtuális serveren a két ...-proxy példány nem szükséges (hiszen innen nincs továbbküldés), csak az első és az utolsó,
- a szomszédos RADIUS-ok kéréseit kiszolgáló virtuális serveren pedig szintén mind a négy példányt jó meghívni.
Az authentikációs kéréseket az auth_log és a pre-proxy naplózza, ezekben a csomagokban lehetnek jelszavak is, amit a naplókból ki kell hagyni a kérdéses példányokon a következő beállítással:
detail auth_log {
...
suppress {
User-Password
}
}
detail pre_proxy_log {
...
suppress {
User-Password
}
}Praktikus ezeken túl mind a négy detail példány suppress szekciójában megadni az EAP-Message mezőt is, hogy ez a hexadecimálisan megjelenített TLS-kódolású adatsor se szerepeljen feleslegesen a naplókban.