Lo scorso anno abbiamo utilizzato i finanziamenti PON RETI LAN/WLAN per aggiornare le reti Wireless delle nostre scuole. Oggi siamo alle prese con i nuovi bandi PNRR, che  ci chiedono, tra le altre cose, di avere in ogni aula  “dispositivi digitali per gli studenti con connessione wifi”, come chiaramente indicato nel PIANO SCUOLA 4.0. 

Come fare però a gestire tutti gli utenti wireless? password uguale per tutti? MAC? SAML? Captive Portal? Firewall?  E. se abbiamo più sedi? come facciamo ad usare le stesse credenziali tra un plesso e l’altro? fino a ieri ci bastava una password condivisa con i docenti – che poi tutti se la  “arrubbavano” – oggi si fa sul serio. 

Molte scuole utilizzano quotidianamente Google Classroom e registrano tutti i loro studenti su Google WorkSpace. La gestione utenti su Google è tutto sommato comoda, i protocolli di autenticazione sono aperti, sicuri e  – soprattutto – è possibile utilizzare un software open source per collegare la rete wireless della scuola agli stessi utenti che usano Classroom. Vediamo come…

Detto in modalità tecnica: utilizzeremo una autenticazione WPA2/3 ENTERPRISE, abbinata ad un server RADIUS, che gestirà gli utenti mediante il servizio LDAP di Google.

Niente paura! Sono solo sigle, ciò che conta è la soluzione scelta: una volta configurato il tutto, per accedere alla rete WiFi dell’Istituto si potranno usare le stesse credenziali che docenti e studenti hanno già assegnate per Google Classroom. Facile e veloce.

Questa soluzione ci consente di gestire gli utenti wireless direttamente dal pannello di gestione di Google WorkSpace e ci evita di dover utilizzare altri sistemi di autenticazione più complicati, come i Captive Portal, e meno sicuri, come il blocco degli indirizzi MAC. Sempre con Google, gli utenti saranno in grado di gestire le loro password con maggiore autonomia, senza richiedere il nostro intervento.

Lo schema di funzionamento è questo:

Fare clic sull’immagine per ingrandirla

Quando un nuovo client si collega alla rete Wireless, l’Access Point chiede nome utente e password, e le invia al nostro server RADIUS.
Il server RADIUS chiede al server LDAP di Google se l’utente è autorizzato e, solo in caso positivo, autorizza l’ingresso nella rete Wireless del nostro utente. 

Il tutto automaticamente e senza ulteriori procedure per la gestione degli utenti di rete. 

Vantaggi

• Single Sign On: tutti gli utenti usano le stesse credenziali per accedere ai diversi servizi;
• Unico punto di gestione: gli amministratori della scuola gestiscono gli utenti direttamente dalla console di amministrazione di Google Workspace che conoscono già e che può importare facilmente gli utenti da file di testo.
• Stessa gestione per tutti i plessi: il sistema di autenticazione è unico per tutti i plessi,  i docenti (e anche gli studenti) possono spostarsi da un plesso all’altro utilizzando le stesse credenziali. 
• Minor tempo da dedicare alle credenziali e alle configurazioni e pertanto più tempo per la didattica.
• Gratuito: per le scuole  i servizi Google Workspace for Education e Classroom sono inizialmente gratuiti pur con dei limiti.
• Già utilizzato e conosciuto da moltissime scuole: molti istituti sono già registrati su Google Workspace for Education e quindi usano con successo e quotidianamente questi servizi per la DDI (Didattica Digitale Integrata).
• Sicurezza: Il protocollo WPA Enterprise offre una sicurezza molto maggiore rispetto al WPA personal (adatto all’uso personale e domestico). 
• Migliore controllo degli accessi: non è possibile autenticare utenti generici,  ma soltanto quelli registrati nel Workspace del nostro Istituto.
• Tecnologia aperta: i sistemi utilizzati sono standard sicuri e aperti, utilizzabili quindi anche per altre applicazioni di Single Sign On.

Svantaggi

• Canoni di abbonamento: Google Workspace for Education è totalmente gratuito solo nella versione Fundamentals (base,) che ha un limite di 100 utenti simultanei per le riunioni con Meet, il limite non ci impedisce certo di registrare migliaia di  studenti su Classroom; ma negli Istituti più grandi questo blocco sulle videoconferenze potrebbe risultare fortemente limitante e quindi portare a costi di abbonamento, che sono da verificare attentamente. 
• Sempre Google, ovunque Google: Classroom funziona bene ma, negli ultimi tempi, la diffidenza verso Google è aumentata, i problemi di privacy, di ubicazione dei server e di rispetto delle norme europee vanno attentamente valutati,  soprattutto se non avete ancora adottato Google Workspace for Education nella vostra scuola. 

Prerequisiti

Cosa dobbiamo già avere:

• Un abbonamento (gratuito) a Google Workspace for Education;
• L’accesso alla console amministrativa di Google Workspace for Education
• Una rete Wireless su ogni plesso dotata di un sistema centralizzato di management (tipo Omada, Unifi o equivalenti);
• Una connessione Internet a larga banda;
• Un minimo di abilità con gli indirizzi di rete, la riga di comando e il blocco note. Se non vi sentite sicuri chiedete a qualche collega e lavorate in team.

Cosa dobbiamo aggiungere:

• Un server con caratteristiche minime (2 o 4gb di RAM, 2+ core) anche virtuale
• Sistema operativo Ubuntu Server https://ubuntu.com/download/server o un sistema equivalente
• Software Freeradius https://freeradius.org/

In commercio si trovano molti server amd o atom a basso costo, dotati di un case rack mount dalle dimensioni equivalenti a uno switch; in alternativa potremmo usare una macchina virtuale o perfino un Raspberry Pi4.

Se abbiamo più plessi. ci sono tre alternative

• Un server (anche Raspberry) per ogni plesso, con la medesima configurazione. 
• Un unico server nel plesso principale raggiungibile dagli altri plessi mediante IP statico e interventi sul router/firewall. In caso di interruzione della sede centrale il wireless smetterà ovviamente di funzionare in tutti i plessi.
• Un unico server virtuale ospitato sul Cloud. Questa è probabilmente la soluzione più razionale ed affidabile; ma l’abbonamento al servizio può costarci 8-15€ al mese.

Configurazione

La configurazione si fa una volta sola, non fatevi spaventare dai passaggi, una volta completata la procedura il sistema funziona da solo e non richiede ulteriori interventi.

Per completare le configurazioni useremo un PC desktop/notebook per accedere in remoto al nostro server. Scaricate e installate su questo PC i seguenti software:

• PuTTY www.putty.org
• WinSCP winscp.net/eng/download.php

Creiamo sul PC un documento di registro della nostra installazione, dove annotare tutti i passaggi: ci servirà per  per tenere traccia di modifiche, indirizzi e credenziali varie e ci tornerà utile per ogni attività di manutenzione o installazione futura. Se facciamo fare ad un tecnico le operazioni chiediamo lo stesso un report completo della configurazione.

1. UBUNTU SERVER 

Iniziamo con installare sul nostro server o sulla macchina virtuale la versione Server di Ubuntu https://ubuntu.com/download/server 

Durante le fasi dell’installazione prestiamo attenzione a questi passaggi:

• Autorizziamo i driver di terze parti 
• Inseriamo credenziali amministrative con nome utente non banale e password lunga e sicura
• Se abbiamo un server locale, impostiamo l’indirizzo IP statico in modo che sia raggiungibile da tutte le sottoreti  del nostro istituto.
  Esempio di configurazione con IP statico e indirizzamento CIDR 192.168.0.0/16
• Se stiamo usando un server cloud l’indirizzo IP non va ovviamente cambiato e ci serve per accedere in remoto al nostro server.
• SSH Setup: installiamo OpenSSH Server, ci servirà per l’accesso da remoto
• Non aggiungiamo altri servizi, non ci servono

Sul registro installazione annotiamo i passaggi dell’installazione,  le credenziali  amministrative del nostro server e l’indirizzo IP.

Se durante l’installazione ci fermiamo e/o lasciamo passare troppo tempo è possibile che l’installer si blocchi per motivi di sicurezza. In questo caso ripartiamo da capo con l’installazione.

Se abbiamo un server reale durante il riavvio approfittiamone per entrare nel BIOS di sistema e cambiare due impostazioni strategiche:

• Power Loss: Alwarys Restart o equivalente (in caso di mancata alimentazione il sever si deve sempre riaccendere da solo)
• Disattivare gli errori di Boot per tastiera assente (alcuni PC non si avviano se manca la tastiera, con questa opzione il server si avvierà anche senza tastiera e moitor e lo potremo amministrare da remoto)

Ora avviate PuTTY sul PC di lavoro, inserite l’indirizzo del server e collegatevi: vi verranno chiesti username e password. Se qualcosa non funziona controllate la rete e rifate l’installazione. Se il server cloud non è raggiungibile controllate le impostazioni sul firewall. Vi sarete accorti che il server non ha l’interfaccia grafica e si usa solo la console (terminale, riga di comando). D’ora in poi tutte le operazioni da terminale le possiamo fare direttamente con PuTTY.

2. PANNELLO AMMINISTRAZIONE DI GOOGLE

https://admin.google.com 

Accedete con il ruolo Super Amministratore

Dal Menu Applicazioni / LDAP, Aggiungi client LDAP
Inserire nome, descrizione (es Wireless Campus Scuola XXYY), abilitiamo permessi e scarichiamo il file con le chiavi di accesso del certificato di sicurezza.

Configurare le autorizzazioni di accesso: intero dominio per credenziali e informazioni utente, attributi di sistema, lettura informazioni gruppi
Attivare il servizio LDAP e impostare un nome tipo:
Wireless Campus ScuolaXY

Nella finestra di autenticazione attiviamo Genera le credenziali di accesso, copiamo le credenziali e e inseriamole nel nostro documento di registro dell’ installazione. Attenzione che la password non verrà mai più visualizzata da Google: se la perdiamo bisognerà rigenerarla.

Successivamente, sempre da queste impostazioni, si potranno gestire le unità organizzative ed i gruppi abilitati al Wi-Fi. Ma solo dopo aver concluso le installazioni e un primo periodo di test.

3. SERVER RADIUS

Accediamo al server con PuTTY, inseriamo le credenziali di root o di un utente amministrativo (è importante avere una password molto sicura)

Installiamo quindi Free Radius da terminale:

sudo -s
apt update && apt upgrade
apt -y install freeradius freeradius-ldap freeradius-utils
apt install ldap-utils
reboot

ora verifichiamo la versione che è stata installata:

cd /etc/freeradius/
ls

Dovremmo vedere una cartella con il numero della versione es 3.0 o 3.2, in queste istruzioni useremo la versione 3.0, quindi tutti i nostri path inizieranno con questo percorso: /etc/freeradius/3.0/ in caso di una versione diversa bisognerà correggere i path di queste istruzioni con la versione esatta es: /etc/freeradius/3.2/

Nel momento in cui scriviamo l’installazione standard offre la versione 3.0, mentre sul sito ufficiale https://freeradius.org/releases/ si trova già la 3.2 che ha una compatibilità migliore con Windows 11. 

Voglio la 3.2!

Per installare l’ultima versione del momento senza dover scaricare e compilare tutto freeradius, si può fare riferimento ai pacchetti di installazione disponibili su https://networkradius.com/packages/ qui con pochi comandi installerete la 3.2 ma ricordatevi di installare anche il resto:

apt -y install freeradius-ldap freeradius-utils 
apt install ldap-utils
reboot

Attenzione! con questa procedura il path di freeradius è ora /etc/freeradius/ senza la sottocartella 3.0 o 3.2, quindi correggete sempre i path di queste istruzioni con la versione esatta che viene installata, in questo caso: /etc/freeradius/

Colleghiamoci con WinSCP

Avviamo WinSCP sul nostro PC e, nelle impostazioni su trasferimento/predefinito/modifica spuntiamo ignora errori sui permessi.

Colleghiamoci al nostro server sempre con WinSCP inserendo l’indirizzo e le credenziali amministrative e accediamo alla cartella /etc/freeradius/3.0/certs/ 

Se non riusciamo ad accedere alla cartella, probabilmente non stiamo usando l’utente root e quindi bisogna impostare i permessi alla cartella mediante il terminale di PuTTY:

sudo apt install acl
sudo setfacl -R -m u:radadmin:rwx /etc/freeradius

sostituite radadmin con il vostro username amministrativo e con questi permessi la copia dei file con WinSCP funzionerà correttamente.

Copiamo i certificati di Google

Ora copiamo i certificati scaricati dal pannello di amministrazione di Google Workspace nella cartella /etc/freeradius/3.0/certs/  
rinominandoli in ldap-client.crt e ldap-client.key

4. VERIFICA CONNESSIONE LDAP GOOGLE

Verifichiamo da terminale se il nostro server riesce a parlare con LDAP di Google con questa lunga riga di comando:

LDAPTLS_CERT=/etc/freeradius/3.0/certs/ldap-client.crt LDAPTLS_KEY=/etc/freeradius/3.0/certs/ldap-client.key ldapsearch -H ldaps://ldap.google.com:636 -b dc=dominioscuolagoogle,dc=it '(mail=utentex@dominoscuolagoogle.it)'

correggiamo le info in grassetto con il percorso esatto dei certificati, il nome del dominio e con un utente registrato sul nostro Google Workspace. Ad esempio se la nostra scuola ha un dominio registrato che si chiama scuolamanzoni.net avremo dc=scuolamanzoni,dc=net

Se il sistema ci risponde con informazioni tipo queste:

# search result
search: 3
result: 0 Success
# numResponses: 1

la comunicazione con Google è OK e possiamo proseguire. Se invece ci dice che non riesce a contattare il server LDAP controlliamo il firewall (aprire in uscita la porta 636) e i certificati.

5. Configurazione

modifichiamo il file /etc/freeradius/3.0/clients.conf aprendolo direttamente con WinSCP, o se preferite da terminale con

nano /etc/freeradius/3.0/clients.conf

In fondo al file abilitare gli IP a cui il server Radius può rispondere, inserite anche un codicesegreto alfanumerico (evitate caratteri speciali) e segnatevelo sul documento di registro installazione.

Esempio Server Locale – abilitiamo tutta la rete locale:

client unifi{
ipaddr = 192.168.0.0/16
secret = codicesegreto
}

Esempio Server Pubblico – abilitiamo gli IP pubblici di tutte le sedi:

client sede{
ipaddr = 80.5.10.22
secret = codicesegreto
}

client succursale{
ipaddr = 80.32.8.48
secret = codicesegreto
}

Esempio per le fasi di test – abilitiamo tutti gli indirizzi IP

client omada{
ipaddr = 0.0.0.0/0
secret = codicesegreto
}

ora modifichiamo questi due file:
/etc/freeradius/3.0/sites-enabled/default
/etc/freeradius/3.0/sites-enabled/inner-tunnel
direttamente con WinSCP o se preferite da terminale con

nano /etc/freeradius/3.0/sites-enabled/default
nano /etc/freeradius/3.0/sites-enabled/inner-tunnel 

Nella sezione authorize di ogni file, dopo pap, aggiungere:

if (User-Password) {
        update control {
               Auth-Type := ldap
        }
   }

Nella sezione authenticate correggere così:

authenticate {
       Auth-Type PAP {
              ldap
       }

togliere commento a ldap:

# Auth-Type LDAP {
     ldap
# }

salviamo e ricordiamoci di ripetere le modifiche anche sul secondo file, il simbolo  # corrisponde ad un commento, mentre modifichiamo i file controlliamo sempre che non rimanga commentata una linea che non deve esserlo.

da terminale lanciamo due comandi:

cd /etc/freeradius/3.0/mods-enabled
ln -s ../mods-available/ldap ldap

modifichiamo questo file /etc/freeradius/3.0/mods-enabled/ldap aprendolo con WinSCP, o se preferite da terminale con

nano /etc/freeradius/3.0/mods-enabled/ldap

Nel file aggiorniamo queste informazioni:

server = 'ldaps://ldap.google.com'
port = 636

identity = 'credenzialegoogle'
password = passwordfornitadagoogle

base_dn = 'dc=dominioscuola,dc=it’

Per identity e password inseriamo quelle generate al punto 2 del tutorial, sostituiamo le info in grassetto con il nome del dominio registrato su Google Workspace. Ad esempio se la nostra scuola ha un dominio  che si chiama scuolamanzoni.net avremo dc=scuolamanzoni,dc=net

nella sezione TLS:

start_tls = no

certificate_file = /etc/freeradius/3.0/certs/ldap-client.crt
private_key_file = /etc/freeradius/3.0/certs/ldap-client.key

require_cert = 'allow'

modifichiamo /etc/freeradius/3.0/mods-enabled/eap

Nella sezione eap:

default_eap_type = ttls

Nella sezione ttls:

default_eap_type = gtc

infine modifichiamo /etc/freeradius/3.0/proxy.conf

max_connections = 0 

per non avere limiti alle connessioni,

alla fine del file aggiungere:

realm dominioscuola.it {
}

Sostituiamo le info in grassetto con il nome del dominio registrato su Google Workspace, ad esempio scuolamanzoni.net 

ora riavviamo e vediamo se riparte:

sudo systemctl restart freeradius.service

se non si lamenta e segnala errori dovrebbe essere tutto ok, altrimenti bisogna ricontrollare tutti i passaggi e tutte le modifiche ai file di configurazione

per controllare eventuali errori:

journalctl -xe

controlliamo se il nostro radius funziona:

radtest utente@miascuola.it fakepwd ipdelserver 1645 codicesegreto

sostituiamo le parti in grassetto con un utente di prova, con l’indirizzo del nostro server e con il codicesegreto scelto da noi. Se risponde qualcosa tipo Expected Access-Accept got Access-Reject vuol dire che sta funzionando, il rifiuto deriva dal fatto che la password fakepwd è volutamente sbagliata e comunque non crittografata.

Se il nostro server è sul cloud ricordiamoci di abilitare in uscita dalla nostra scuola la porta 1645 sul firewall, altrimenti l’autenticazione non sarà raggiungibile. Le porte standard usate da Radius sono 1812, 1813, 1645 e 1646.

6. Certificati

L’accesso sicuro alla rete necessita dei soliti certificati di sicurezza, è possibile  acquistare certificati di sicurezza ufficiali oppure generare dei certificati self-signed utilizzabili solo internamente nella nostra rete. 

modifichiamo il file /etc/freeradius/3.0/certs/ca.cnf
Nella sezione CA_default incrementare il numero di giorni prima della scadenza, es 10 anni:

default_days = 3650

Nella sezione req section cambiamo input_password e output_password  con una password interna:

input_password = whatheverwifi
output_password = whatheverwifi

Nella sezione certificate_authority section mettere le info della scuola:

countryName = IT
stateOrProvinceName = TO
localityName = Grugliasco
organizationName = IIS Scuola
emailAddress = wireless.campus@dominioscuola.it
commonName = "Scuola WiFi Certificate"

Ora modifichiamo anche il file server con la stessa procedura:  /etc/freeradius/3.0/certs/server.cnf

default_days = 3650

input_password = whatheverwifi
output_password = whatheverwifi

[server]
countryName = IT
stateOrProvinceName = TO
localityName = Grugliasco
organizationName = IIS Scuola
emailAddress = wireless.campus@dominioscuola.it
commonName = "Scuola WiFi Certificate"

Come indirizzo email inserite l’indirizzo dell’amministratore,  del webmaster o di un tecnico di riferimento.

Generiamo i certificati:

sudo -s
cd /etc/freeradius/3.0/certs/
make ca.pem
make ca.der
make server.pem
chown freerad:freerad /etc/freeradius/3.0/certs/*

Aggiungiamo i certificati nel file di configurazione: /etc/freeradius/3.0/mods-enabled/eap

private_key_password = whateverwifi
private_key_file = /etc/freeradius/3.0/certs/server.pem
certificate_file = /etc/freeradius/3.0/certs/server.pem
ca_file = /etc/freeradius/3.0/certs/ca.pem

Riavviamo il server radius

systemctl restart freeradius

Questi certificati fatti in casa funzionano benissimo ma non possono essere validati online (ricordatevi  non validare il certificato nelle opzioni di connessione degli smartphone). Volendo si possono installare certificati ufficiali e gratuiti con Lets’Encrypt, qui trovate le istruzioni: https://framebyframewifi.net/2017/01/29/use-lets-encrypt-certificates-with-freeradius/

7 Wireless Manager

Colleghiamoci al wireless manager, nella sezione impostazioni o profili cerchiamo i profili Radius

Aggiungiamo un profilo radius e lo chiamiamo FreeRadiusClassroom

Server: inserire indirizzo del server (IP locale o IP pubblico per server cloud)
Porta: 1812
Segreto:  codicesegreto

il codicesegreto sarà lo stesso che abbiamo inserito nei file di configurazione di Freeradius al punto 5 del tutorial;

Ora andiamo nella sezione reti, creiamo una uova rete
SSID: Wireless Campus
Autenticazione: WPA Enterprise 
Profilo Radius: FreeRadiusClassroom

Finito! provate subito se funziona!

Debug

Possiamo avviare freeradius in modalità debug per vedere cosa succede durante il processo di autenticazione:

systemctl stop freeradius.service
freeradius -X

Ricordiamoci, una volta finiti i test, di riavviare freeradius nella modalità normale:

systemctl start freeradius.service

Connessione Android

Autenticazione metodo eap TTLS
Autenticazione fase 2 GTC
Non validare certificato

Connessione Windows 11 22H2

La versione  22H2 forza la sicurezza TLS alla versione 1.3 che è disponibile solo con Freeradius 3.2, in attesa di un fix da parte di Microsoft possiamo sbloccare il limite con una chiave di registro (regedit) e un riavvio

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13
Create DWORD key TlsVersion value FC0

Usare un Raspberry Come Server

Le stesse istruzioni dovrebbero funzionare senza modifiche su un Raspberry Pi

Copiatevi i file di configurazione!

Con WinSCP fatevi una copia locale di tutti i file modificati e dei certificati, vi torneranno utili in caso di nuove installazioni o di ripristino di un server. I certificati potranno anche essere installati a mano nei PC obsoleti che non sono in grado di scaricarseli autonomamente.

Credits

FreeRADIUS with Google G Suite/Workspace Secure LDAP for WPA2 Enterprise WiFi

Networkradius FreeRADIUS Packages

Per configurare insieme l’autenticazione Wireless con Google Classroom abbiamo organizzato un workshop in presenza:

9 marzo 2023 presso Laboratorio di Sistemi e Reti – ITI Majorana di Grugliasco (TO) ore 14.30 è richiesta l’iscrizione online su:

https://www.associazionedschola.it/blog/geek-dschola-2023/