Ti chiedi se sia possibile gestire Multi‑Pre‑Shared Key (MPSK) con Windows Server 2022 NPS? La risposta breve è no: NPS non offre MPSK nativo. In questo articolo trovi motivi tecnici, alternative praticabili e una guida operativa per ottenere lo stesso risultato in modo solido e sicuro.
Che cos’è MPSK e perché interessa alle reti Wi‑Fi aziendali
MPSK (Multi‑Pre‑Shared Key), noto anche come PPSK (Private PSK) o iPSK a seconda del vendor, consente di associare più chiavi pre‑condivise allo stesso SSID. Ogni chiave può essere legata a un gruppo (es. foresteria, ospiti, IoT) o a un singolo dispositivo. L’obiettivo è ridurre l’impatto del key sharing tra utenti e semplificare la revoca/rotazione delle credenziali senza cambiare SSID.
Rispetto a un SSID con un’unica PSK, l’MPSK permette di isolare meglio gli incidenti (una chiave compromessa non espone tutti), tracciare accountability per gruppo/dispositivo e applicare policy diverse (VLAN, ACL, rate limit) in funzione della chiave usata.
Perché Windows Server 2022 NPS non gestisce MPSK
NPS (Network Policy Server) è un server RADIUS classico. RADIUS entra in gioco quando si usa WPA‑Enterprise/802.1X, cioè quando l’access point delega a un server esterno l’autenticazione dell’utente o del dispositivo tramite EAP (EAP‑TLS, PEAP‑MSCHAPv2, ecc.).
Nei profili WPA/WPA2‑PSK, invece, non c’è RADIUS: l’autenticazione è locale all’AP/Controller, basata sulla chiave condivisa e sulla 4‑way handshake. L’idea di avere più PSK sullo stesso SSID è dunque una funzione del sistema Wi‑Fi (controller/cloud), non del server RADIUS.
- Shared secret RADIUS ≠ PSK Wi‑Fi: NPS consente una sola shared secret RADIUS per ogni RADIUS client (AP/controller, VPN). Questa non è la PSK Wi‑Fi dell’SSID, bensì la chiave che protegge il dialogo RADIUS tra AP e NPS.
- MPSK richiede logica applicativa sul Wi‑Fi: è l’infrastruttura wireless che deve riconoscere più PSK e mapparle a profili/VLAN differenti. NPS non riceve né valida la PSK Wi‑Fi.
- Estensioni “iPSK con RADIUS” sono proprietarie: alcuni vendor implementano flussi speciali in cui l’AP interroga un RADIUS per “verificare” una PSK. NPS non espone un archivio di PSK né un motore nativo per validarli con quel modello; opera su identità utente/dispositivo e criteri, non su dizionari di PSK.
| Punto chiave | Dettagli |
|---|---|
| Supporto nativo | NPS in Windows Server 2022 non implementa MPSK: ogni RADIUS client ha una sola shared secret RADIUS; le PSK Wi‑Fi non transitano in RADIUS. |
| Motivo tecnico | NPS è un server RADIUS per 802.1X/EAP; la gestione fine‑grained è su identità e policy (gruppi AD, certificati, attributi RADIUS), non su più PSK per SSID o gruppi. |
Alternative per ottenere funzionalità equivalenti
Se vuoi il vantaggio operativo di MPSK, ecco le strade più efficaci.
Estensioni proprietarie del vendor Wi‑Fi
Diversi vendor (controller on‑prem o cloud) offrono MPSK/PPSK nativo. In questi casi:
- La convalida della PSK avviene direttamente sul controller/cloud.
- Spesso puoi associare a ogni PSK profili (VLAN, QoS, ACL) e scadenze.
- NPS può rimanere in uso per 802.1X sulle reti aziendali e per accounting o syslog della rete MPSK, se il vendor lo consente.
- Valuta licenze/firmware: l’MPSK è talvolta un feature pack.
Server RADIUS di terze parti
Soluzioni come FreeRADIUS, Cisco ISE, Aruba ClearPass o Radiator includono meccanismi per gestire MPSK/PPSK, spesso con binding per gruppo o MAC address, scadenze e API. Puoi:
- Sostituire NPS per i casi in cui serve MPSK.
- Affiancare NPS: usare NPS per 802.1X dei client gestiti e un RADIUS terzo per l’SSID MPSK di ospiti/IoT.
Segmentazione SSID/VLAN con PSK dedicate
Se non puoi adottare MPSK lato vendor o un RADIUS terzo, la soluzione classica è creare più SSID (o VLAN) con PSK distinte. È semplice ma introduce overhead radio e maggiore gestione. Mantieni poche reti ben definite (es. Ospiti, IoT, BYOD).
Migrare a 802.1X con certificati su NPS
Se i client lo supportano, la via maestra è eliminare le PSK e passare a 802.1X/EAP‑TLS con NPS e Active Directory Certificate Services: ottieni identità forti, policy granulari, VLAN dinamiche e revoca immediata senza cambiare chiavi.
Confronto sintetico delle opzioni
| Opzione | Pro | Contro | Quando sceglierla |
|---|---|---|---|
| MPSK lato vendor Wi‑Fi | Nessuna modifica a NPS; mappatura PSK→VLAN/ACL; rotazione chiavi per gruppo/dispositivo | Licenze/lock‑in; gestione PSK nel controller; integrazione limitata con NPS | Hai un’infrastruttura Wi‑Fi moderna con supporto PPSK/iPSK |
| RADIUS di terze parti | MPSK/PPSK nativo; API; policy avanzate; auditing | Nuovo stack da gestire; costi/licenze; complessità | Richiedi MPSK ricco e integrazione con flussi IT |
| Più SSID/VLAN con PSK | Implementazione rapida; nessun software aggiuntivo | Più beaconing e roaming peggiore; gestione PSK più onerosa | Piccole reti; temporaneo in attesa di soluzione migliore |
| 802.1X/EAP‑TLS con NPS | Identità forti; VLAN dinamiche; revoca immediata; niente PSK | Richiede PKI; distribuzione certificati; supplicant lato client | Ambienti gestiti (AD/MDM) o clienti moderni |
Come funziona davvero: il flusso di autenticazione
Confronto semplificato dei flussi
WPA2-PSK/MPSK (senza RADIUS)
Client ──(4-way handshake con PSK)── AP/Controller
[Nessun contatto RADIUS/NPS]
WPA2/WPA3-Enterprise 802.1X (con RADIUS/NPS)
Client ──EAP over 802.1X── AP/Controller ──RADIUS── NPS
Con PSK o MPSK, l’AP non interroga NPS. Con 802.1X, invece, l’AP inoltra via RADIUS i messaggi EAP al server (NPS) che valida l’identità e applica le policy.
Guida pratica: implementare un’alternativa solida con NPS
Obiettivo consigliato: 802.1X/EAP‑TLS con VLAN dinamiche
Di seguito una traccia di implementazione end‑to‑end per sostituire PSK/MPSK con autenticazione a certificato su NPS, ottenendo lo stesso livello di segmentazione (e di più) senza gestire chiavi pre‑condivise.
Prerequisiti
- Active Directory funzionante (DNS/tempo corretti).
- NPS installato su Windows Server 2022 e registrato in AD.
- CA interna (AD CS) o PKI equivalente per EAP‑TLS.
- Controller/AP compatibili 802.1X in WPA2‑Enterprise/WPA3‑Enterprise.
- Gruppi AD per la conformità (es. WiFi‑Staff, WiFi‑IoT, WiFi‑Guest).
Distribuzione certificati
- In AD CS, crea i template Computer Authentication e/o User Authentication (EAP‑TLS).
- Abilita Autoenrollment via GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies.
- Distribuisci il certificato della Root CA (e intermedie) nella Trusted Root Certification Authorities.
Configurazione NPS
- Registra NPS in AD (menu NPS → tasto destro → Register server in Active Directory).
- Aggiungi i RADIUS clients (controller/AP) con Friendly name, IP e shared secret RADIUS (una per client).
- Crea una Connection Request Policy per richieste wireless (NAS‑Port‑Type: Wireless – IEEE 802.11).
- Crea una Network Policy per ogni gruppo AD (es. WiFi‑Staff):
- Conditions: Windows Groups = WiFi‑Staff, NAS‑Port‑Type = Wireless
- Constraints: Authentication Methods → EAP‑TLS (rimuovi PEAP/MD5/CHAP non necessari)
- Settings → RADIUS Attributes:
- Standard: assegna VLAN dinamica con:
Tunnel‑Type = VLAN (13)Tunnel‑Medium‑Type = IEEE‑802 (6)Tunnel‑Private‑Group‑ID = 20(ID VLAN desiderato)
- Vendor‑Specific (opzionale): dACL o profili a seconda del vendor.
- Standard: assegna VLAN dinamica con:
- Replica la policy per gli altri gruppi (IoT, Guest) con VLAN/ACL differenti.
Configurazione Wi‑Fi
- Crea un SSID Enterprise (WPA2‑Enterprise/WPA3‑Enterprise) con autenticazione 802.1X su RADIUS (NPS).
- Verifica che i controller accettino i tre attributi Tunnel* per l’assegnazione VLAN dinamica.
- Carica nel controller la Root CA se richiesto per validare il certificato del server NPS (consigliato).
Verifica & diagnostica
- Event Viewer → Custom Views → Server Roles → Network Policy and Access Services per gli Event ID d’autenticazione.
- Abilita i log NPS in formato IAS per auditing e troubleshooting.
- Testa con un dispositivo membro del gruppo corretto; verifica VLAN e policy applicate.
Strategia alternativa: più SSID/VLAN con PSK dedicate
È la soluzione “senza MPSK” più semplice. Mantieni il numero di SSID al minimo per ridurre il beacon overhead e i tempi di roaming.
| Numero di SSID attivi | Impatto sul tempo d’aria | Indicazioni |
|---|---|---|
| 1‑3 | Basso | Target consigliato |
| 4‑6 | Medio | Accettabile con canali larghi/pochi client |
| >6 | Alto | Da evitare: peggiora roaming e throughput |
Consigli operativi:
- Nomina chiara (es. ACME‑Guest, ACME‑IoT), rotazione PSK periodica e isolamento client abilitato sugli SSID condivisi.
- Usa ACL/Firewall per limitare i segmenti PSK (es. IoT → solo server di telemetria, nessuna east‑west).
Quando serve davvero MPSK e quando no
Usa questo decision tree rapido:
- Client gestiti (PC aziendali, mobile MDM) → Passa a 802.1X/EAP‑TLS con NPS: più sicuro, zero PSK.
- IoT/Stampanti senza supplicant 802.1X → MPSK lato vendor o SSID PSK separati + ACL.
- Ospiti → Captive Portal del vendor o MPSK per gruppi temporanei; NPS resta per la rete corporate.
Domande frequenti
Posso “abilitare” MPSK in NPS creando utenti AD con password=PSK?
No. Anche se creassi account AD con stringhe casuali, l’AP in modalità PSK non manda alcuna richiesta RADIUS a NPS. MPSK è una funzione dell’infrastruttura Wi‑Fi, non del server RADIUS classico.
NPS supporta le implementazioni “iPSK con RADIUS” di alcuni vendor?
Non nativamente. Queste integrazioni usano flussi proprietari o archivi di chiavi che NPS non fornisce. In genere richiedono RADIUS con logica MPSK/PPSK dedicata o il controller stesso.
E per i dispositivi IoT che non supportano 802.1X?
Usa MPSK lato vendor, oppure SSID PSK dedicati con isolamento, ACL restrittive e VLAN separate. Valuta certificati o EAP‑TLS solo se il dispositivo lo supporta.
Il MAC Authentication Bypass (MAB) è una buona alternativa?
È comodo ma debole: l’indirizzo MAC si falsifica facilmente. Usalo solo per casi residuali, associandolo a VLAN altamente limitate e con monitoraggio.
Posso avere policy diverse in base alla PSK, come con MPSK?
Sì, se la tua piattaforma Wi‑Fi lo supporta nativamente (PPSK/iPSK) o tramite RADIUS avanzato. Con NPS e 802.1X ottieni lo stesso risultato (e oltre) basandoti su identità e gruppi AD.
Checklist di adozione
- Definisci i domini d’uso: Corporate, BYOD, Guest, IoT.
- Verifica hardware: supporto 802.1X, VLAN dinamiche, eventuale MPSK del vendor.
- Scegli la strategia: 802.1X con NPS (preferita) o MPSK lato vendor / RADIUS terzo.
- Segmenta: VLAN, ACL, routing; servizio DNS/DHCP per ogni segmento.
- Automatizza: GPO/MDM per profili Wi‑Fi e certificati.
- Monitora: log NPS, syslog del controller, metriche di roaming e retry.
- Piano di rotazione: PSK (se rimaste), certificati, segreti RADIUS.
Piano di migrazione consigliato
- Fase 1 – Assessment: inventaria SSID, client, driver, supporto 802.1X, requisiti IoT/Guest.
- Fase 2 – PKI & NPS: allestisci CA, autoenrollment, registra NPS, crea policy EAP‑TLS per gruppi AD.
- Fase 3 – Pilota: SSID Enterprise per IT e un reparto pilota. Misura roaming e tasso di successo.
- Fase 4 – Rollout: estendi a tutto il parco gestito; mantieni temporaneamente SSID PSK per BYOD/IoT.
- Fase 5 – Consolidamento: spegni SSID PSK superflui; se serve MPSK, abilitalo lato vendor o integra un RADIUS terzo per IoT/Guest.
Attributi RADIUS utili in NPS
Per ottenere segmentazione dinamica con 802.1X, in NPS usa i seguenti attributi standard:
| Attributo | Valore | Descrizione |
|---|---|---|
| Tunnel‑Type | VLAN (13) | Indica che si tratta di una VLAN |
| Tunnel‑Medium‑Type | IEEE‑802 (6) | Specificazione del mezzo |
| Tunnel‑Private‑Group‑ID | ID VLAN (es. 20) | VLAN da assegnare al client autenticato |
Molti vendor supportano anche VSA (Vendor Specific Attributes) per ACL scaricabili, profili QoS o role‑based access.
Errori comuni da evitare
- Confondere la shared secret RADIUS (NPS↔AP) con la PSK Wi‑Fi dell’SSID.
- Lasciare più metodi EAP abilitati in NPS senza necessità (aumenta superficie d’attacco).
- Dimenticare la registrazione di NPS in AD o i certificati server/client per EAP‑TLS.
- Attivare troppi SSID con PSK, degradando airtime e roaming.
- Affidarsi a MAB per dispositivi sensibili senza controlli compensativi.
Sicurezza: PSK/MPSK vs 802.1X a certificato
| Criterio | PSK singola | MPSK | 802.1X/EAP‑TLS |
|---|---|---|---|
| Isolamento incidenti | Basso | Medio/Alto (per chiave) | Alto (per identità) |
| Revoca mirata | No | Sì (per chiave) | Sì (per utente/dispositivo) |
| Scalabilità | Buona ma fragile | Buona con gestione accurata | Ottima con PKI/MDM |
| Granularità policy | Bassa | Media (PSK→profilo) | Alta (gruppi AD, posture, dACL) |
| Dipendenza dal vendor | Bassa | Media/Alta | Bassa/Media (standard RADIUS/EAP) |
Riepilogo operativo
Fatto: Windows Server 2022 NPS non offre MPSK. L’MPSK è una funzione del sistema Wi‑Fi oppure di RADIUS avanzati. Per ottenere lo stesso risultato:
- Usa MPSK nativo della tua infrastruttura Wi‑Fi (se disponibile) oppure un RADIUS di terze parti che lo supporti.
- In alternativa, segmenta con SSID/VLAN a PSK dedicate, in modo parsimonioso.
- Per reti corporate gestite, migra a 802.1X/EAP‑TLS con NPS: più sicurezza, gestione semplificata e policy granulari senza PSK.
Modello di tabella decisionale pronta all’uso
| Esigenza | Soluzione | Note implementative |
|---|---|---|
| Ospiti temporanei | MPSK lato vendor o SSID Guest isolato | Abilita client isolation, rate‑limit e captive portal se presente |
| IoT legacy | SSID PSK dedicato o MPSK per dispositivo/gruppo | ACL in uscita; blocca traffico laterale; DNS/DHCP separati |
| Client aziendali | 802.1X/EAP‑TLS con NPS | Autoenrollment certificati, VLAN dinamiche, dACL (se supportate) |
| BYOD | SSID separato con PSK o onboarding 802.1X | Se possibile, portale di onboarding con profilo EAP/eduroam‑like |
Conclusioni
L’assenza di MPSK in NPS non è un limite blocca‑progetto: dipende dalla natura di RADIUS e di come funzionano le PSK nel Wi‑Fi. Se il tuo obiettivo è ridurre il rischio di condivisione delle chiavi e assegnare policy diverse a gruppi o dispositivi, puoi farlo oggi scegliendo una di queste tre strade:
- MPSK lato vendor per ambienti con infrastruttura wireless moderna.
- RADIUS terzo per MPSK/PPSK avanzato con workflow e API.
- 802.1X/EAP‑TLS con NPS per identità forti, controllo granulare e gestione scalabile, eliminando del tutto le PSK.
Con un progetto ben pianificato (segmentazione, PKI, policy e monitoraggio) ottieni sicurezza superiore, minori operazioni manuali e un’esperienza migliore per utenti e dispositivi.