NPS (Network Policy Server)

Introduzione

Network Policy Server (NPS) è l'implementazione Microsoft di un server RADIUS e proxy. Un numero crescente di istituzioni utilizza Windows NPS come server RADIUS collegato all'infrastruttura eduroam.

Questa guida illustra nel dettaglio come configurare Windows NPS per integrarsi correttamente nella federazione eduroam gestita dal GARR.

Gli esempi riportati sono basati su Windows Server 2012 R2 e Windows Server 2008 R2. Le schermate di configurazione possono differire leggermente tra le due versioni, ma le voci di configurazione sono molto simili.

Attenzione

Questa documentazione è basata sul Best Practice Document CBP-13 "Using Windows NPS as RADIUS in eduroam" di GÉANT/UNINETT e rappresenta solo delle linee guida per la configurazione di NPS. Non va intesa come sostitutiva delle attuali configurazioni in essere presso gli enti.

Prerequisiti

La configurazione presuppone un ambiente con Active Directory già funzionante. Le istruzioni assumono una configurazione base di AD.

Prima di procedere è necessario prendere nota dei seguenti valori che andranno opportunamente sostituiti nella configurazione:

Operator-Name

rappresenta un valore univoco che identifica l'ente che invia le richieste di autenticazione alla federazione eduroam in qualità di Resource Provider. Si prende come riferimento il dominio principale dell'ente preceduto dalla stringa 1 (es. 1uniroma1.it). Nella configurazione verrà indicato come ###OPERATOR_NAME###

Shared Secret

è il segreto condiviso scambiato con gli operatori della federazione nazionale. Nella configurazione verrà indicato come ###SHARED_SECRET###

Realm

è il dominio che identifica l'ente nella federazione eduroam (es. uniroma1.it). Nella configurazione verrà indicato come ###REALM###

Per gli Identity Provider, è necessario procurarsi un certificato server come descritto nella sezione Certificati.

Limitazioni

Il Network Policy Server presenta alcune limitazioni rispetto a soluzioni come FreeRADIUS:

Limitazioni da tenere in considerazione

• Non è possibile rimuovere attributi: non si possono eliminare attributi (ad es. attributi VLAN assegnati da altri Identity Provider), ma è possibile impostare esplicitamente valori applicabili al proprio ambiente.
• Non è possibile aggiungere attributi nelle richieste in uscita: l'aggiunta dell'attributo Operator-Name per indicare dove un utente si connette non è possibile e deve essere impostata dal National Roaming Operator (GARR).
• NPS non risponde alle richieste Status-Server: è best practice che i server proxy eduroam verifichino la disponibilità dei server con tali richieste. Informare il GARR che si utilizza NPS.
• Identità esterne anonime: l'uso di identità esterne anonime (anonymous outer identities) non è possibile a meno che non sia abilitato "Override network policy authentication settings" nelle Connection Request Policies.
• Username interno non riscrivibile: mentre lo username esterno (tramite la Connection Request Policy) può essere riscritto, lo username interno gestito dalla Network Policy non può esserlo. Gli utenti devono utilizzare il UPN (User Principal Name) registrato.
• Logging limitato: il logging nell'Event Viewer è piuttosto scarno rispetto a FreeRADIUS, rendendo il debug più difficile.

Problema del 'Dead Realm' e Utenti Inesistenti

È fondamentale che NPS risponda sempre alle richieste pervenute dalla federazione, anche per utenti inesistenti (es. non presenti in Active Directory) o con password errata, inviando un esplicito Access-Reject.

Se NPS è configurato per ignorare (drop) le richieste di utenti sconosciuti invece di rifiutarle, i server proxy GARR non riceveranno risposta e supporranno che il vostro server sia offline. A causa di questo comportamento, dopo i tentativi previsti (timeout di 8 secondi), il server della federazione inserirà in blacklist l'intero dominio (Dead Realm) per 120 secondi. Durante questo periodo, tutti gli utenti dell'istituzione (anche quelli con credenziali corrette) non potranno autenticarsi!

Comunicazione con il GARR

A causa delle limitazioni sopra elencate, e per problematiche relative allo Status-Server, è importante informare il personale tecnico del GARR che si intende utilizzare NPS come server RADIUS.

Configurazione di NPS per prevenire il 'Dead Realm'

Per evitare che NPS ignori le richieste per utenti inesistenti e mandi in blacklist il dominio, è obbligatorio assicurarsi che venga inviato un Access-Reject:

1. Network Policy "Catch-All" (Deny Access): Creare una Network Policy in fondo all'elenco che catturi tutte le richieste non corrispondenti alle policy precedenti, impostando specificatamente Deny Access invece di lasciare che la richiesta venga semplicemente scartata.
2. Chiave di Registro Ping User-Name (Opzionale): Microsoft NPS potrebbe comunque scartare i pacchetti se l'utente non esiste in AD prima ancora di valutare le Network Policies. Controllare i log: se si verificano mancate risposte, consultare la documentazione Microsoft per evitare questo comportamento o valutare l'uso di workaround se le policy non risultano sufficienti.

Installazione di NPS

Aprire Server Manager sul proprio Windows Server.

Windows Server 2012: Fare clic su Add roles and features.

Windows Server 2008: Fare clic con il tasto destro su Roles e selezionare Add Roles.

Il wizard Add Roles and Features si aprirà. Leggere le informazioni e procedere cliccando Next nelle prime schermate:

Selezionare Role-based or feature-based installation e cliccare Next:

Selezionare il server di destinazione e cliccare Next:

Nella schermata Select server roles, selezionare Network Policy and Access Services e cliccare Next:

Accettare le impostazioni predefinite nelle schermate successive:

Procedere con l'installazione cliccando Install:

Attendere il completamento dell'installazione e cliccare Close:

Certificato server per NPS

Solo per Identity Provider

È necessario un certificato server per utilizzare l'autenticazione PEAP con eduroam. PEAP (Protected Extensible Authentication Protocol) stabilisce un tunnel sicuro (analogamente a quanto fa HTTPS per i siti web) al fine di proteggere le credenziali, ed è una parte importante dell'autenticazione reciproca.

Il server RADIUS (NPS in questo caso) invierà il proprio certificato al client prima che avvenga l'autenticazione dell'utente. Il client deve aver precedentemente installato il certificato pubblico della Certification Authority (CA) che ha emesso e firmato il certificato del server NPS.

Nota

Senza un certificato (self-signed o meno) non è possibile effettuare l'autenticazione locale, ma NPS può comunque essere utilizzato come proxy per ricevere richieste dagli Access Point, registrarle, filtrarle e inoltrarle all'infrastruttura eduroam.

Per i requisiti dettagliati del certificato, fare riferimento alla sezione Certificati della pagina Identity Provider. In sintesi, il certificato deve:

• Essere X.509v3
• Avere un CN come FQDN (senza wildcard, senza spazi)
• Avere il SubjectAltName:DNS sincronizzato con il CN
• Essere firmato con almeno SHA-256
• Avere una chiave pubblica di almeno 2048 bit
• Contenere l'estensione TLS Web Server Authentication (OID: 1.3.6.1.5.5.7.3.1)
• Avere l'estensione Basic Constraints con valore CA:FALSE

Distribuzione del certificato CA

Il certificato della Root CA deve essere presente come Trusted Root Certification Authority su tutti i client eduroam. Il modo raccomandato è distribuire il certificato CA tramite eduroam CAT.

Configurazione di NPS

Aprire la console NPS (snap-in):

• Windows Server 2012: Server Manager > Tools > Network Policy Server
• Windows Server 2008: Start > Administrative Tools > Network Policy Server

Nota

È disponibile un Wizard per la configurazione delle connessioni wireless o wired 802.1X. Tuttavia, il wizard non fornisce tutte le impostazioni necessarie (come il pattern-matching dei realm/username), quindi sarà necessario apportare modifiche alle policy create. In questa guida, RADIUS clients e server, Connection Request e Network Policies verranno creati separatamente.

RADIUS Clients

Per Identity Provider e Resource Provider

Prima di applicare qualsiasi policy alle richieste di autenticazione, è necessario creare i RADIUS clients. Essi rappresentano gli apparati che inviano richieste al server NPS.

Per Resource Provider: - I client configurati saranno unicamente gli apparati di rete dell'ente (es. Access Point, Wireless LAN Controller).

Per Identity Provider: - Oltre agli eventuali apparati di rete locali, i client da configurare includono i server proxy nazionali del GARR (radius.garr.net e radius2.garr.net) da cui proverranno le richieste di autenticazione dei propri utenti in roaming.

Template per Shared Secret

Se si hanno diversi controller o Access Point da definire come client, è consigliabile definire prima un template per il shared secret (si riutilizzerà lo stesso secret per tutti) e poi applicarlo a ciascun client, evitando errori di digitazione.

Per creare un template: espandere Templates Management > Shared Secrets nel pannello sinistro della console NPS e creare un nuovo template.

È possibile creare template separati per i controller e per i server proxy nazionali.

Creazione dei RADIUS Clients

Fare clic con il tasto destro su RADIUS Clients e selezionare New.

Inserire un Friendly name (può essere usato successivamente nel pattern matching), l'indirizzo IP o il nome DNS e il shared secret (utilizzare il template se è stato creato).

Ripetere l'operazione per tutti i client necessari. Come minimo devono essere configurati:

Per Resource Provider:

• I propri apparati locali (Wireless LAN Controller o Access Point)

Per Identity Provider:

• I propri apparati locali (se fungono anche da RP)
• I server proxy nazionali come client:

Friendly Name	Indirizzo	Shared Secret
radius.garr.net	radius.garr.net	###SHARED_SECRET###
radius2.garr.net	radius2.garr.net	###SHARED_SECRET###

Nota

I dettagli per i server proxy nazionali (indirizzo IP e shared secret) devono essere concordati con il personale tecnico del GARR secondo la procedura.

Remote RADIUS Server Groups

Solo per Resource Provider

Creare un gruppo di server remoti per i proxy nazionali. Questo gruppo verrà utilizzato per inoltrare le richieste di autenticazione dei visitatori eduroam verso la federazione. Questa configurazione è pertanto necessaria solo per i Resource Provider.

Fare clic con il tasto destro su Remote RADIUS Server Groups e selezionare New. Inserire un nome per il gruppo, ad esempio eduroam-GARR-proxies, poi cliccare Add:

Inserire il nome del primo server (radius.garr.net) e procedere alla scheda Authentication/Accounting per inserire il shared secret:

Configurare i seguenti parametri:

Parametro	Valore
Authentication port	1812
Accounting port	1813
Shared secret	###SHARED_SECRET###

Load Balancing per il server secondario

Per il server secondario (radius2.garr.net), nella scheda Load Balancing, impostare una priorità inferiore rispetto al server primario. È raccomandato non bilanciare le singole sessioni EAP su server multipli. Impostare il server secondario come failover.

Alla fine, il gruppo dovrebbe contenere entrambi i server GARR:

RADIUS Server	Priority	Weight
radius.garr.net	1	50
radius2.garr.net	2	50

Confermare cliccando OK due volte.

Connection Request Policies

Per Identity Provider e Resource Provider

Le Connection Request Policies decidono cosa fare con una richiesta di autenticazione: se autenticarla localmente o inoltrarla ai server proxy nazionali. La decisione è basata su condizioni impostate nella policy.

Per eduroam sono necessarie due Connection Request Policies, in questo ordine:

1. Autenticazione dei propri realm (###REALM###) localmente
2. Inoltro dei visitatori eduroam ai server proxy GARR

Policy 1: Autenticazione locale dei propri realm

Solo per Identity Provider

Fare clic con il tasto destro su Connection Request Policies e selezionare New.

Inserire un nome per la policy, ad esempio own realms:

Cliccare Next, poi Add per inserire una condizione. Selezionare User Name e cliccare Add.

Inserire il pattern per lo username che identifica i propri utenti. Ad esempio, per il realm uniroma1.it:

.*@uniroma1\.it$

Pattern matching

Il pattern .*@###REALM###$ corrisponde a qualsiasi username che termina con @###REALM###. Questo include anche eventuali sotto-realm come studenti.uniroma1.it.

Per la sintassi completa del pattern matching, consultare la documentazione Microsoft.

Cliccare Next. Nella schermata successiva, selezionare Authenticate requests on this server e cliccare Next.

Nella schermata Authentication Methods, selezionare "Override network policy authentication settings" e aggiungere PEAP come tipo EAP:

• Cliccare Add e selezionare Microsoft: Protected EAP (PEAP)
• Selezionare la voce appena aggiunta e cliccare Edit...
• Selezionare il certificato server precedentemente installato
• Deselezionare "Enforce Network Access Protection"

Deselezionare tutti i "Less secure authentication methods" in basso.

Cliccare OK, poi Next due volte e infine Finish.

Policy 2: Inoltro visitatori eduroam ai proxy GARR

Solo per Resource Provider

Creare una nuova Connection Request Policy come sopra, con le seguenti impostazioni:

• Policy name: eduroam visitors
• Condizione User Name: @.+\..+$

Pattern matching per visitatori

Il pattern @.+\..+$ corrisponde a qualsiasi realm nella forma @qualcosa.qualcosa. Un'alternativa più restrittiva è @.+\.[a-z]{2,6}$ che corrisponde solo a realm che terminano con un TLD di 2-6 lettere.

• Forwarding: selezionare "Forward requests to the following remote RADIUS server group" e selezionare il gruppo eduroam-GARR-proxies creato in precedenza.

È possibile assegnare attributi VLAN ai visitatori eduroam nella scheda Settings della policy (attributi Tunnel-Medium-Type, Tunnel-Type e Tunnel-Pvt-Group-ID). Questo è opzionale se si preferisce utilizzare la VLAN predefinita configurata sull'SSID eduroam del proprio controller wireless.

Ordine delle Connection Request Policies

Assicurarsi che le Connection Request Policies siano elaborate nell'ordine corretto:

#	Policy Name	Status
1	own realms	Enabled
2	eduroam visitors	Enabled
3	Use Windows authentication for all users	Disabled

Importante

La policy predefinita "Use Windows authentication for all users" deve essere disabilitata o eliminata. Se lasciata attiva, intercetterebbe gli utenti senza realm nello username e non funzionerebbe per tali utenti in altre sedi eduroam.

A questo punto i visitatori eduroam dovrebbero potersi collegare dalla propria sede. Verificare se possibile come guest presso la propria istituzione.

Network Policies

Solo per Identity Provider

Le Network Policies vengono applicate alle richieste che devono essere autenticate localmente (come stabilito nelle Connection Request Policies).

Policy base per gli utenti eduroam locali

Creare una nuova Network Policy con le seguenti impostazioni:

• Policy name: ad esempio default for own eduroam users

Cliccare Next, poi Add per specificare le condizioni di matching.

Selezionare User Groups e cliccare Add per specificare il gruppo Active Directory degli utenti autorizzati ad autenticarsi. Ad esempio, selezionare Domain Users o un gruppo specifico creato per eduroam.

Cliccare OK e poi Next.

Nella schermata successiva, verificare che sia selezionato Grant access e cliccare Next.

Nella schermata Configure Authentication Methods:

• Deselezionare tutti i "Less secure authentication methods"
• Aggiungere Microsoft: Protected EAP (PEAP) come per la Connection Request Policy

Nota

Poiché PEAP (e il certificato da usare) è stato configurato nella Connection Request Policy con l'opzione "Override Network Policies", questa impostazione non dovrebbe essere mai utilizzata direttamente. Tuttavia, poiché un metodo di autenticazione deve essere impostato, si seleziona il più sicuro.

Cliccare Next nelle schermate successive (Constraints e Settings) mantenendo i valori predefiniti, poi Finish.

Policy per assegnazione VLAN (opzionale)

Per assegnare VLAN specifiche ad alcuni gruppi di utenti (ad es. dipendenti vs studenti), è possibile duplicare la Network Policy base e modificarla:

1. Fare clic con il tasto destro sulla policy base e selezionare Duplicate
2. Fare doppio clic sulla copia per modificarla
3. Assegnare un nuovo nome, ad esempio eduroam employees at own institution
4. Abilitare la policy selezionando Policy enabled

Nella scheda Conditions, aggiungere le condizioni specifiche. Ad esempio:

• User Groups: selezionare il gruppo specifico (es. Domain Admins)
• Client Friendly Name: specificare il pattern dei controller locali (es. Controller.+)

Nella scheda Settings, aggiungere gli attributi RADIUS per l'assegnazione VLAN:

Attributo	Valore
Tunnel-Medium-Type	802 (includes all 802 media plus Ethernet canonical format)
Tunnel-Type	Virtual LANs (VLAN)
Tunnel-Pvt-Group-ID	Il numero della VLAN desiderata

Attenzione

Non impostare attributi VLAN nella Network Policy base utilizzata per tutti gli utenti locali. Gli attributi VLAN devono essere assegnati solo per l'uso locale e non devono essere inviati quando i propri utenti si autenticano in roaming presso altre sedi.

Ordine delle Network Policies

L'ordine delle Network Policies è importante. Fare clic con il tasto destro su una policy per spostarla su o giù:

#	Policy Name	Uso
1	eduroam employees at own institution	VLAN specifica per dipendenti
2	default for own eduroam users	Policy base per tutti gli utenti

Suggerimento

È possibile aggiungere ulteriori Network Policies per altri gruppi di utenti, Machine Groups o combinazioni di questi.

Logging e Accounting

Per Identity Provider e Resource Provider

Per visualizzare gli eventi NPS, aprire Event Viewer:

• Windows Server 2012: Server Manager > Tools > Event Viewer
• Windows Server 2008: Start > Administrative Tools > Event Viewer

I log NPS si trovano sotto Custom Views > ServerRoles > Network Policy and Access Services.

File di log

Di default, l'accounting è abilitato con registrazione su file.

Per configurare il logging su file, accedere alla sezione Accounting nella console NPS e cliccare su Change Log File Properties.

Impostazioni consigliate:

• Verificare che "If logging fails, discard connection requests" sia deselezionato (per evitare interruzioni del servizio in caso di problemi di logging)
• Nella scheda Log File, decidere la frequenza di creazione dei nuovi file di log (un file mensile può produrre una grande quantità di dati)

Troubleshooting

Alcuni suggerimenti per il troubleshooting:

• Wireshark: installare Wireshark sul server NPS per visualizzare tutto il traffico RADIUS

• eapol_test / rad_eap_test: configurare una macchina Linux come RADIUS client e installare wpa_supplicant che include eapol_test (un programma che comunica direttamente con il server RADIUS) e rad_eap_test (uno script che utilizza eapol_test). Esempio di comando:

  ./rad_eap_test -c -H <IP_NPS_SERVER> -P 1812 \
    -S <shared_secret> -M 22:44:66:33:22:55 \
    -u user@###REALM### -p password \
    -e PEAP -m WPA-EAP | grep 'RADIUS message:'
  

• eduroam CAT: utilizzare lo strumento CAT per configurare i client nel proprio realm/istituzione. Lo strumento include anche la possibilità di verificare il proprio realm da un sito remoto.

• Event Viewer: controllare gli eventi NPS nell'Event Viewer, sebbene il dettaglio sia limitato rispetto ai log di FreeRADIUS.

Verifica del servizio

Prima di comunicare al GARR che il servizio è pronto, utilizzare gli strumenti sopra indicati per verificare che:

• L'autenticazione locale dei propri utenti funzioni correttamente
• L'inoltro delle richieste dei visitatori eduroam ai server proxy GARR funzioni correttamente
• I log registrino correttamente le operazioni

Per maggiori dettagli sulle verifiche, consultare la pagina Verifiche.