#acl All:read <> == Freeradius 1.x konfigurálás == === FreeRadius installáció === Installáljuk fel a kiszemelt Radius gépre a [[http://www.freeradius.org/|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 = shortname = } }}} 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 = certificate_file = CA_file = 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 = certificate_file = CA_file = 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 = nostrip } realm UP { type = radius authhost = radius2.eduroam.hu:1812 accthost = radius2.eduroam.hu:1813 secret = nostrip } }}} Illetve a {{{clients.conf}}} fájlba: {{{ client 195.111.98.4 { secret = shortname = radius1.eduroam.hu } client 195.111.98.12 { secret = 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 = 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 = 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 [[http://www.kfki.hu/cnc/projekt/postfilter/|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 = No }}} Debughoz 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 = no }}} Az ö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 [[http://freeradius.org/|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 = shortname = 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 = shortname = 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 = shortname = hu1 virtual_server = eduroam } client 195.111.98.12 { secret = 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 = status_check = none } home_server hu2 { type = auth+acct ipaddr = 195.111.98.12 port = 1812 secret = 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 = No }}} A 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-list }}} Ezzel 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 }}} 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: {{{ : Auth: Login OK: [felhasznalo@egyetem.hu] (from client port 0 via TLS tunnel) : Auth: Login OK: [anonymous@egyetem.hu] (from client port 0 cli ) : Auth: Login OK: [felhasznalo@egyetem.hu] (from client port 0 via TLS tunnel) : Auth: Login OK: [anonymous@niif.hu] (from client port 0 cli ) }}} 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 {{{}}} 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 {{{}}} 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. {{{ : Auth: Login OK: [anonymous@masikintezmeny.hu] (from client port 0 cli ) }}} ==== 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: {{{ : Auth: Login incorrect (rlm_pap: CLEAR TEXT password check failed): [felhasznalo@egyetem.hu] (from client wlan-ap port 0 via TLS tunnel) : Auth: Login incorrect: [anonymous@egyetem.hu] (from client wlan-ap port 0 cli ) }}} 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: {{{ : Auth: Login incorrect (Home Server says so): [anonymous@masikintezmeny.hu] (from client wlan-ap port 0 cli ) }}} 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): {{{ : Error: No response to status check for home server 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.