Dokumentace k jednotlivým parametrům voleb z hostfailů pro roli ansible-freeradius, podívejte se na příklady je to snad celkem samovysvětlující.
Sekce je nutná pouze pokud je FR v roli IdP.
Adresa adresářového serveru školy ve formátu LDAP URL, pokud by škola měla více serverů tak je možné jejich použití, ale vyžádá si to změny playbooku. FreeRADIUS by to měl umět, netestováno.
Playbook nepočítá s tím že LDAP nepoužívá šifrování (LDAPS).
Obsahuje název souboru ve kterém je umístěn certifikát CA, která
vydala certifikát pro LDAP server. Je nutné aby tam byla celá cesta až
ke kořeni. V případě že LDAP používá self-sign certifikát, tak se
tento asi umístí do souboru odkazovaného ldap.CAChain
-
netestováno. Playbook nepočítá s tím že by certifikát serveru
vyexpiroval.
DN a heslo LDAP uživatele který bude používán k připojení LDAPu. Dotyčný uživatel musí mít právo číst eduroam heslo uživatelů. Aby fungoval PEAP-MSCHAPv2 tak to heslo musí být v čitelné podobě.
DN od kterého se začínají hledat uživatelé. Používá se hledání
scope: one
.
Atribut pomocí kterého se hledá uživatel, na LDAP serverech OpenLDAP,
389 DS, .. je to uid
na MS AD se používá sAMAccountName
.
Atribut ve kterém je uloženo heslo které uživatel používá k přihlašování k eduroamu. Předpokládá se že se jedná o jiné heslo než je použito pro většinu ostatních služeb na škole. Aby mohlo fungovat přihlašování pomocí PEAP-MSCHAPv2 musí toto heslo být uloženo v nešifrované podobě a uživatel kterého RADIUS server má k dispozici ''ldap.eduroam.bindDN'' musí mít oprávnění toto heslo přečíst.
Poznámky (neimplementováno v roli):
Alternatovou by bylo použít třeba TTLS-PAP kdy lze ověřovat klasickým LDAP bindem. Odpadne nutnost jiného hesla. Je to ale velmi náchylné ke krádežím identit uživatelů pokud uživatel nekontroluje certifikát tak útočník dostane heslo ihned, po sestavení tunelu jde nešifrovaně.
Ověřování pomocí NTLMv1 je možné ale je to starý a dost děravý protokol, mám dojem že něco takového bychom neměli doporučovat.
Popisuje parametry FR v rámci eduroamu
Režim zapojení serveru, možnosti jsou: proxy
, SP
, IdPSP
.
Realmy které instituce používá. Velmi doporučuji aby to byl realm jediný. Musí se jednat o doménu registrovanou ve veřejném DNS systému a měla by patřit instituci.
V případě více realmů a pokud libovolný uživatel může používat oba realmy je nezbytné zajistit že v obou případech dostane stejné CUI. FIXME - Vašek to vyzkoumal, jen zanést do role.
Pokud se jedná o doménu mimo CZ TLD, tak je třeba definovat NAPTR záznam jinak nebude fungovat roaming uživatelů mimo CZ. Problém jsou veřejní registrátoři, Active24 ani DomainMaster to nepodporují - nevím jak jsou na tom ostatní.
Parametry nadřazeného RADIUS serveru většinou tedy národního RADIUSu. Detailněji viz některý z příkladů, je to celkem samovysvětlující.
Certifikát pro RadSec spojení a certifikát pro EAP. Může odkazovat na ty samé soubory. Privátní klíče musí být zašifrovány.
Pokud by nebyl uveden ani jeden ze slovníků eduroam.radsec a eduroam.EAP tak role bude očekávat existenci certifikátu v souboru ''.pkcs12'', nedoporučuji to využívat je to pro ty situace kdy se role freeradius využívá na tom samém serveru jako role pro shibboleth. Tj. ten samý host slouží krom eduroam IdP i jako eduID.cz IdP.
Definice parametrů WLC nebo obyčejných APček. Na názvech klíčů NAS1/2/... nezáleží musí být jen unikátní. Sekce je volitelná, v režimu proxy RADIUSu může být zbytečná.
Sekce má smysl jen když je FR v roli proxy
, detailní příklad viz semik-dev.cesnet.cz-proxy.yml
Heslo k certifikátu v PKCS#12 formátu, pokud je použito musí být
certifikát uložen v files/hostname
.pkcs12 pak je použit pro EAP i
RadSec. Tohle nemá moc smysl používat, má smysl jen když spravujeme
současně eduroam a eduID.cz IdP.