Obiettivo: impedire che gli utenti Active Directory si connettano all’SSID sbagliato mantenendo l’autenticazione centralizzata via RADIUS/NPS su Windows Server 2022. In questa guida trovi architettura, passaggi operativi, esempi e troubleshooting.
Scenario e obiettivo
In un’infrastruttura aziendale coesistono due reti Wi‑Fi protette con WPA2‑Enterprise (802.1X/EAP), identificate dagli SSID “Alpha” e “Beeta”. L’amministratore utilizza Network Policy Server (NPS) su Windows Server 2022 come server RADIUS e Active Directory come archivio identità. L’esigenza è vincolare gli utenti del gruppo Alpha all’SSID Alpha (e allo stesso modo per Beeta), evitando autenticazioni incrociate.
Soluzione in breve
- Creare gruppi di sicurezza AD corrispondenti agli SSID (es.
WiFi‑AlphaeWiFi‑Beeta), assegnando ogni utente esclusivamente al gruppo previsto. - Definire policy distinte in NPS per ciascun SSID, con doppio filtro:
- Windows Groups – il gruppo AD autorizzato;
- NAS Identifier oppure Called‑Station‑ID – l’identificativo dell’SSID1.
- Ordinare correttamente le policy (top‑down): NPS usa la prima che soddisfa tutte le condizioni.
- Testare e verificare: da Alpha credenziali di un utente Alpha si autenticano; le stesse su Beeta devono essere rifiutate (Access‑Reject).
Architettura e flusso
- Il client si associa a un SSID (Alpha/Beeta) e avvia 802.1X/EAP.
- L’AP/WLC invia richiesta RADIUS all’NPS, includendo attributi come Called‑Station‑ID (spesso
<MAC_AP>:SSID) o NAS‑ID impostato per SSID. - NPS interroga AD, valuta le Network Policy in ordine e decide Access‑Accept o Access‑Reject.
- Facoltativo: NPS invia attributi VLAN (tunneling) per isolamento di rete.
Prerequisiti
- Windows Server 2022 con ruolo Network Policy and Access Services (NPS) installato e registrato in AD.
- Access point o controller configurati come RADIUS clients verso NPS (indirizzo IP e shared secret coerenti).
- Metodo EAP concordato (PEAP‑MSCHAPv2, EAP‑TLS, PEAP‑TLS, ecc.).
- Sincronizzazione oraria affidabile (NTP) per evitare errori TLS/EAP.
Passaggi operativi dettagliati
Creare i gruppi AD corrispondenti agli SSID
- In Active Directory Users and Computers, crea due Security Group di tipo Global:
WiFi‑AlphaWiFi‑Beeta
- Aggiungi ogni utente solo al gruppo corrispondente all’SSID autorizzato.
Suggerimenti pratici:
- Se usi autenticazione computer‑based (EAP‑TLS macchina), valuta gruppi distinti per computer accounts e filtri NPS su Machine Groups.
- Evita che lo stesso utente finisca in entrambi i gruppi: annullerebbe l’isolamento logico fra SSID.
Esempio PowerShell (facoltativo):
# Creazione gruppi
New-ADGroup -Name "WiFi-Alpha" -GroupScope Global -GroupCategory Security
New-ADGroup -Name "WiFi-Beeta" -GroupScope Global -GroupCategory Security
Aggiunta utenti (esempio)
Add-ADGroupMember -Identity "WiFi-Alpha" -Members mario.rossi
Add-ADGroupMember -Identity "WiFi-Beeta" -Members anna.bianchi Verifica NPS e registrazione in AD
- Apri Network Policy Server → clic destro su NPS (Local) → Register server in Active Directory.
- Definisci i RADIUS Clients (AP o controller):
- Friendly name, Address (IP or DNS), Shared secret coerente con quello sugli AP.
- Se il vendor lo consente, imposta un NAS‑ID diverso per SSID e usa questo valore nelle policy.
Creare la Network Policy per l’SSID “Alpha”
In NPS → Policies → Network Policies → New:
| Sezione NPS | Configurazione chiave |
|---|---|
| Conditions | Windows Groups: seleziona WiFi‑Alpha. NAS Identifier oppure Called‑Station‑ID: inserisci la stringa che identifica l’SSID Alpha.Se il controller invia <MAC_AP>:Alpha, puoi usare Ends with “:Alpha”; se invia un NAS‑ID per SSID, usa Equals al relativo valore. |
| Constraints | Authentication Methods: seleziona il metodo EAP usato dai client (PEAP, EAP‑TLS, ecc.). (Opzionale) Idle timeout, Session timeout. |
| Settings | Access granted. (Opzionale) Attributi VLAN: Tunnel‑Type=VLAN, Tunnel‑Medium‑Type=802, Tunnel‑Private‑Group‑ID=ID VLAN. |
Duplicare la policy per l’SSID “Beeta”
- Clona la policy “Alpha” e rinominala, ad es. WiFi‑Beeta.
- In Conditions, cambia:
- Windows Groups →
WiFi‑Beeta. - NAS Identifier/Called‑Station‑ID → stringa che identifica “Beeta”.
- Windows Groups →
- Conserva lo stesso metodo EAP nei Constraints, salvo esigenze diverse.
Ordinare le policy
In Network Policies, trascina per posizionare WiFi‑Alpha e WiFi‑Beeta in cima. NPS valuta le policy in sequenza e applica la prima che soddisfa tutte le condizioni. Se nessuna corrisponde, l’accesso viene negato.
Test e verifica
- Test 1 (positivo): da SSID Alpha, usa credenziali di un utente in
WiFi‑Alpha→ autenticazione riuscita. - Test 2 (negativo): da SSID Beeta, riusa le stesse credenziali → l’NPS deve inviare Access‑Reject.
- Log: verifica Event Viewer → Custom Views → Server Roles → Network Policy and Access Services o i file di accounting RADIUS di NPS.
Come funziona il filtro per SSID
L’attributo RADIUS Called‑Station‑ID normalmente contiene l’indirizzo MAC dell’AP e il nome SSID, con formati tipici come 00-11-22-33-44-55:Alpha o 001122334455:Alpha. L’attributo NAS Identifier (NAS‑ID) può essere configurato lato controller/AP in modo univoco per SSID. Nelle Conditions della policy NPS puoi quindi:
- Usare Equals sul NAS‑ID (se definito univocamente per SSID);
- Usare Ends with o il valore esatto del SSID su Called‑Station‑ID, coerente al formato inviato dal vendor.
Risultato: il server RADIUS concede l’accesso solo quando entrambe le condizioni sono vere: utente nel gruppo corretto e richiesta proveniente dall’SSID corretto.
Gestione client: distribuire profili Wi‑Fi con GPO
Per ridurre errori e connessioni “al SSID sbagliato”, distribuisci i profili Wi‑Fi tramite Criteri di Gruppo:
- GPO Wireless (IEEE 802.11):
- Computer Configuration → Policies → Windows Settings → Security Settings → Wireless Network (IEEE 802.11) Policies.
- Crea un profilo per Alpha con le impostazioni EAP corrette e contrassegnalo come “Connetti automaticamente”.
- Security Filtering della GPO: applica il profilo “Alpha” solo al gruppo
WiFi‑Alpha(e analogamente per “Beeta”). - Convalida certificato server (se PEAP/EAP‑TLS): seleziona l’Autorità di certificazione attendibile e il nome del server (o pattern).
Tabella di riferimento rapido (NPS per SSID)
| Elemento | Alpha | Beeta |
|---|---|---|
| Windows Group | WiFi‑Alpha | WiFi‑Beeta |
| Filtro SSID | NAS‑ID=Alpha oppure Called‑Station‑ID ends with “:Alpha” | NAS‑ID=Beeta oppure Called‑Station‑ID ends with “:Beeta” |
| Metodo EAP | Uguale su entrambe (es. PEAP/EAP‑TLS), salvo esigenze specifiche | |
| Esito | Access granted | Access granted |
Approfondimenti e buone pratiche
| Tema | Indicazioni |
|---|---|
| Separazione di rete (VLAN) | Se gli access point supportano VLAN dinamiche, NPS può inviare Tunnel‑Private‑Group‑ID per assegnare automaticamente i client alla VLAN del gruppo, migliorando isolamento e sicurezza. |
| Certificati anziché password | Con EAP‑TLS o PEAP‑EAP‑TLS l’uso di certificati macchina/utente riduce il rischio di furto credenziali e semplifica la rotazione. Abilita auto‑enrollment in AD CS e verifica CRL/OCSP raggiungibili dai client. |
| Logging e auditing | Attiva il logging RADIUS su file o SQL. Correlando Access‑Accept/Reject con eventi NPS in Event Viewer individui rapidamente tentativi non autorizzati. |
| Ridondanza | Prevedi almeno due NPS per alta affidabilità. Sugli AP configura entrambi i server RADIUS (primary/secondary). Monitora latenza e scarti di pacchetti. |
| Allineamento orario | Kerberos, TLS ed EAP richiedono orologi coerenti: usa NTP per domain controller, NPS, controller Wi‑Fi e client. |
| Hardening NPS | Usa secret complessi per RADIUS clients, limita l’accesso di management per IP, disattiva cifre TLS deboli, applica patch regolarmente. |
| Controllo accesso per dispositivi | Separa policy user‑based e machine‑based (es. dispositivi aziendali con EAP‑TLS macchina). Filtra con Machine Groups o NAS‑Port‑Type quando necessario. |
Varianti di implementazione del filtro SSID
- NAS‑ID per SSID: molti controller permettono un NAS‑ID diverso per ogni SSID. È il metodo più pulito perché consente un confronto Equals in NPS.
- Called‑Station‑ID: quando non puoi configurare NAS‑ID per SSID, utilizza il suffisso “
:SSID”. Verifica il formato esatto inviato dal vendor (trattini/ due punti/ maiuscole). - RADIUS client per SSID: in ambienti complessi puoi definire client RADIUS distinti (IP/loopback diversi) per ogni SSID e filtrare su Client IPv4 Address. Richiede supporto sul controller.
Controlli di qualità prima del rilascio
- Iscrizione gruppi: report degli utenti e relative membership (
WiFi‑AlphavsWiFi‑Beeta). - Formato attributi: cattura pacchetti RADIUS (se possibile) o log vendor per confermare Called‑Station‑ID/NAS‑ID.
- Ordine policy: le policy Wi‑Fi vanno poste prima di altre generiche (es. policy VPN o wired 802.1X).
- Accounting: verifica che ogni sessione generi record (start/stop/interim) utili al troubleshooting.
Esempi di configurazione: attributi VLAN (opzionale)
Per assegnare dinamicamente i client alle VLAN in base al gruppo, aggiungi in Settings della Network Policy:
- Tunnel‑Type: VLAN (13)
- Tunnel‑Medium‑Type: 802 (6)
- Tunnel‑Private‑Group‑ID: <ID VLAN> (es.
20per Alpha,30per Beeta)
Assicurati che il controller/AP accetti questi attributi e li applichi all’SSID richiesto.
Troubleshooting
Autenticazione rifiutata da SSID “sbagliato”
- Controlla che l’utente appartenga solo al gruppo dell’SSID corretto.
- Verifica che Called‑Station‑ID o NAS‑ID inviati dall’AP coincidano con la condizione della policy (attenzione a maiuscole e formattazione).
- Esamina l’ordine delle policy: una policy generica “permetti tutti” posta più in alto può intercettare la richiesta.
Loop di credenziali o richiesta password continua
- Con PEAP‑MSCHAPv2, abilita la convalida del certificato server e assicurati che il client si fidi della CA.
- Con EAP‑TLS, controlla i certificati (valore EKU, scadenza, CRL/OCSP raggiungibile).
Lentezza o timeout
- Controlla RTT fra AP e NPS, congestione o perdita pacchetti UDP 1812/1813 (o 1645/1646 se legacy).
- Assicurati che i firewall non ispezionino/alterino i pacchetti RADIUS.
Voci log utili
- Eventi NPS: esiti Access‑Accept/Reject, policy corrispondente, motivo del rifiuto.
- Accounting: start/stop sessioni, durata, SSID, indirizzi IP assegnati.
FAQ operative
Posso saltare il filtro per SSID e basarmi solo sui gruppi AD?
Tecnica possibile ma non sicura: senza il filtro SSID un utente di WiFi‑Alpha potrebbe autenticarsi anche su Beeta. Il filtro sull’SSID è quindi fortemente consigliato.
Qual è il metodo di matching migliore?
Se disponibile, NAS‑ID per SSID è preferibile (confronto diretto). In alternativa usa Called‑Station‑ID con Ends with “:SSID”.
Come gestire i dispositivi BYOD?
Valuta SSID dedicati o NAC/MAB per BYOD, lasciando gli SSID aziendali vincolati a EAP‑TLS e ai gruppi AD dell’organizzazione.
Checklist finale
- Gruppi AD
WiFi‑Alpha/WiFi‑Beetacreati e popolati correttamente. - NPS registrato in AD; RADIUS clients definiti con shared secret coerenti.
- Due Network Policy, una per SSID, con Windows Groups + NAS‑ID/Called‑Station‑ID.
- Ordine policy verificato (quelle per SSID in cima).
- Test positivi/negativi eseguiti e logging attivo.
Implementazione completa: guida passo‑passo sintetica
- AD: Crea
WiFi‑AlphaeWiFi‑Beeta. Assegna gli utenti. - NPS:
- Registra NPS in AD.
- Aggiungi AP/controller come RADIUS clients.
- Crea policy WiFi‑Alpha:
- Conditions: Windows Groups=
WiFi‑Alpha; NAS‑ID=Alpha oppure Called‑Station‑ID “:Alpha”. - Constraints: EAP coerente con i client.
- Settings: Access granted; opzionale VLAN.
- Conditions: Windows Groups=
- Clona per WiFi‑Beeta con valori “Beeta”.
- Ordina le policy (Alpha/Beeta in alto).
- GPO (consigliato): distribuisci profili Wi‑Fi per SSID, filtrando per i rispettivi gruppi.
- Test: verifica accettazione sull’SSID corretto e rifiuto sull’altro.
Esempi di log e interpretazione
Ecco una traccia tipica di successo e una di rifiuto (formato indicativo):
[SUCCESSO] Access-Accept
User-Name = "ALPHA\\mario.rossi"
Called-Station-ID = "00-11-22-33-44-55:Alpha"
NAS-Identifier = "Alpha"
Matched-Policy = "WiFi-Alpha"
Authentication-Type = "EAP-TLS"
[RIFIUTO] Access-Reject
User-Name = "ALPHA\mario.rossi"
Called-Station-ID = "00-11-22-33-44-55:Beeta"
NAS-Identifier = "Beeta"
Reason = "Nessuna Network Policy corrispondente (group/SSID)" Estensioni: controllo per ruolo e VLAN dinamiche
Se desideri introdurre livelli di accesso (es. “Staff”, “Guest”, “IoT”), impiega più gruppi AD e corrispondenti policy NPS. Abilitando gli attributi di tunneling assegni VLAN diverse con lo stesso SSID, oppure SSID separati per ruolo se preferisci una separazione più chiara lato utente. Ricorda di documentare mapping <gruppo, VLAN> e di mantenerlo allineato quando cambia l’organigramma.
Raccomandazioni di sicurezza
- Preferisci EAP‑TLS dove possibile: elimina la dipendenza da password e riduce il rischio di phishing delle credenziali 802.1X.
- Segmentazione: abbina il filtro SSID a firewall/ACL intra‑VLAN per evitare “lateral movement”.
- Segreti RADIUS: ruota periodicamente le shared secret e limita le ACL tra AP e NPS.
- Monitoraggio: allerta quando si verificano tentativi ripetuti di autenticazione su SSID non autorizzati da parte dello stesso utente.
1 NAS Identifier o Called‑Station‑ID devono essere supportati e trasmessi dagli access point. In molti controller Wi‑Fi si imposta un NAS‑ID diverso per ogni SSID. In assenza di questi attributi si possono creare due policy NPS separate filtrando solo per gruppo AD; tuttavia un utente del gruppo Alpha potrebbe autenticarsi anche su Beeta: il filtro sull’SSID è pertanto consigliato.
Conclusioni
Associare gruppi AD a SSID specifici e farli rispettare da NPS con condizioni su Windows Groups e NAS‑ID/Called‑Station‑ID offre un controllo fine, tracciabile e scalabile. L’aggiunta di GPO per la distribuzione dei profili Wi‑Fi e, se necessario, delle VLAN dinamiche consolida la sicurezza e semplifica la gestione operativa.
Riepilogo operativo minimo
- Crea
WiFi‑AlphaeWiFi‑Beetain AD; assegna correttamente gli utenti. - Configura NPS e i RADIUS clients (AP/controller).
- Due policy distinte per SSID con doppio filtro (gruppo + SSID).
- Ordina policy top‑down; abilita logging.
- Testa: Accept sull’SSID giusto, Reject
In sintesi: con pochi accorgimenti mirati—gruppi AD, condizioni NPS su SSID, ordine policy e GPO—puoi garantire che ogni utente si colleghi solo alla rete Wi‑Fi prevista, senza rinunciare alla centralizzazione e alla tracciabilità offerte da Active Directory e NPS.