NPS e Microsoft Entra ID: EAP‑TLS per device cloud‑joined—limiti, soluzioni e best practice

Vuoi usare NPS come RADIUS on‑prem per autenticare in Wi‑Fi/VPN i PC “cloud‑only” iscritti a Microsoft Entra ID con EAP‑TLS e policy basate sul device? Ecco cosa oggi è possibile, cosa no, e come progettare un’architettura robusta senza sorprese.

Indice

Scenario e obiettivo

In molte organizzazioni il Network Policy Server (NPS) di Windows Server è ancora il motore RADIUS per l’accesso 802.1X (Wi‑Fi, LAN, VPN). Con la transizione a Microsoft Entra ID (ex Azure AD) cresce l’esigenza di spostare il controllo d’accesso dal semplice utente al dispositivo, per esempio consentendo la connessione a una VLAN “corporate” solo ai device cloud‑joined e gestiti, e relegando gli altri a una rete ospiti o bloccandoli.

La domanda tipica è: “Se faccio EAP‑TLS e nel certificato del client inserisco il deviceID Entra ID, NPS è in grado di verificarlo contro il tenant e applicare una policy basata sull’identità del device (non dell’utente)?”

Risposta breve

NPS non ha un connettore nativo per interrogare Microsoft Entra ID sui device cloud‑joined. Può validare il certificato (catena, revoca, EKU, scadenza) e leggere gli attributi presenti, ma non sa “risolvere” un deviceId verso l’oggetto del tenant e valutarne stato o compliance.
NPS Extension for Microsoft Entra Multifactor Authentication estende la verifica dell’utente in Entra ID, ma non effettua controlli sull’identità/stato del dispositivo. Inoltre l’estensione si applica ai flussi utente (es. PEAP‑MSCHAPv2), non a EAP‑TLS puro lato device.
Se ti serve davvero policy device‑centric in un contesto cloud‑only, serve un RADIUS che integri con Entra ID/Intune via API (Graph/REST) oppure un’architettura ibrida che renda “visibile” il device ad Active Directory.

Come funziona EAP‑TLS con NPS (e dove si ferma)

Il flusso 802.1X con EAP‑TLS, semplificato:

Il supplicant (device) inizia il handshake TLS col NAS (AP/Controller/Firewall), che inoltra a NPS.
Il device presenta un certificato client (Device o User) con catena valida e uso “Client Authentication”.
NPS verifica la catena verso una CA di fiducia e le regole di politica (EKU, lunghezza chiave, CRL/OCSP, scadenza).
In base alle condizioni configurate, NPS non “chiama” Microsoft Entra ID: decide con ciò che vede nel certificato e negli attributi RADIUS.
Se la policy è rispettata, NPS invia Access-Accept e può includere attributi di autorizzazione (p.es. VLAN).

Se il certificato contiene un deviceId nel Subject o nel SAN, NPS può usarlo solo come stringa per filtri statici (matching sul testo), non per una risoluzione dinamica verso l’oggetto di Entra ID.

Perché NPS non riconosce i device “cloud‑only”

NPS nasce per ambienti Active Directory. Con EAP‑TLS può mappare un certificato dispositivo al relativo computer account in AD (scenario Hybrid), ma non ha un “provider” Entra ID.
Non esiste, allo stato attuale, un provider/plug‑in Microsoft ufficiale che consenta a NPS di interrogare Entra ID per:
- validare un deviceId (GUID) e trovarne l’oggetto;
- leggere proprietà come compliance, ownership (Corporate/Personal), joinType (Azure AD Joined vs Registered), isManaged (Intune);
- usarle come condizioni di authorization RADIUS.

Stato dell’arte: cosa puoi fare oggi

Supporto nativo assente

NPS gestisce l’autenticazione EAP‑TLS e può convalidare solo ciò che è nel certificato contro una CA di fiducia o, in scenari ibridi, contro AD. Nessun connettore nativo per Microsoft Entra ID.

Estensione NPS per Entra MFA

NPS Extension for Microsoft Entra MFA permette di aggiungere una challenge MFA a flussi user‑centric (es. PEAP‑MSCHAPv2), ma non verifica lo stato del dispositivo e, con EAP‑TLS puro, di norma non entra in gioco.

Opzioni alternative praticabili

RADIUS “cloud‑native” con integrazione Entra ID/Intune
Soluzioni come servizi RADIUS gestiti o piattaforme NAC moderne si collegano al tenant via Graph/REST per:
- risolvere il deviceId del certificato verso l’oggetto Entra ID;
- valutare compliance e proprietà MDM;
- applicare policy dinamiche (VLAN, ACL, tag) basate sul device.
Esempi di famiglie di prodotto: servizi RADIUS as‑a‑Service, controller di rete con connettori cloud, NAC enterprise con plugin per Entra.
Microsoft Entra Certificate‑Based Authentication (CBA) per web/app
È nativa per scenari di accesso a servizi federati/ SaaS, ma non è un sostituto di RADIUS/NPS per 802.1X. Per il Wi‑Fi serve comunque un RADIUS con le capacità del punto precedente.
Hybrid Azure AD Join
Se il device è sia Entra ID joined che “conosciuto” in AD, NPS può mapparlo tramite l’account computer on‑prem e applicare policy dispositivo. Si perde però la “purezza” cloud‑only e aumentano le dipendenze infrastrutturali.
Migrazione a WPA3‑Enterprise + EAP‑TLS su RADIUS cloud
Consente di portare in rete l’approccio Zero Trust sfruttando identity & compliance del device, riducendo al minimo le eccezioni e i bypass statici.

Tabella comparativa (decisione rapida)

Opzione	Identità usata	Controlli dispositivo	Pro	Contro	Quando sceglierla
NPS on‑prem + EAP‑TLS (device cert)	Certificato; nessuna lookup Entra	No (solo attributi certificato)	Semplice, nessun SaaS	Niente compliance/DeviceID	Ambienti piccoli, requisiti base
NPS + PEAP‑MSCHAPv2 + NPS Extension	Utente Entra (MFA)	No	MFA e controllo utente	Niente device insight	Budget limitato, transizione
NAC/RADIUS cloud integrato Entra	Device + Utente	Sì (DeviceID, compliance)	Policy ricche, CA/Intune aware	Licenze e integrazioni	Cloud‑first, Zero Trust
Hybrid Azure AD Join + NPS	Device AD on‑prem	Sì (via AD)	Compatibilità 802.1X classica	Dipendenza da AD/DC	Organizzazioni ibride

Progettare l’architettura: due percorsi vincenti

Percorso A — RADIUS “as‑a‑Service” integrato con Entra ID

Goal: policy realmente device‑centriche in ambiente cloud‑only.

PKI per device cert: usa Intune Cloud PKI o una CA privata dedicata per emettere certificati device (EKU Client Authentication). Progetta un template che includa nel Subject/SAN gli identificativi utili (nome dispositivo, seriale, eventuale deviceId come stringa).
Profili Wi‑Fi/VPN via Intune: distribuisci SSID e impostazioni EAP‑TLS ai gruppi di device. Abilita SSO solo dispositivo (machine auth) o mista (machine+user) a seconda dei casi.
Integrazione Entra/Intune: registra l’app del RADIUS nel tenant con scopes minimi necessari (lettura device, attributi di gestione, compliance). Configura la sincronizzazione just‑in‑time o on‑demand per interrogare lo stato del device durante l’authorization.
Policy di autorizzazione: definisci regole come:
- Allow solo se deviceId esiste in Entra, isCompliant = true, isManaged = true, joinType = AzureADJoined.
- Assegna VLAN/ACL in base a dynamic groups (Reparto, Sede, Ownership Corporate/Personal).
- Fallback controllato: se isCompliant = false sposta su VLAN remediation con captive portal MDM.
Hardening EAP‑TLS: imposta TLS 1.2, verifica CRL/OCSP, rifiuta SHA‑1, controlla lunghezza minima chiave (≥ 2048), limita le CA fidate ai soli issuer del template MDM.
Osservabilità: centralizza i log RADIUS, correalì con Intune/Entra audit; traccia i rifiuti per stato di compliance e scadenza certificati.

Percorso B — Restare su NPS (budget zero) con mitigazioni

Goal: massimizzare la sicurezza pur senza controllo device‑centric nativo.

Scegli il metodo di autenticazione:
- EAP‑TLS (utente): più forte di PEAP‑MSCHAPv2, ma resta user‑centric. NPS verifica solo il certificato utente.
- PEAP‑MSCHAPv2 + NPS Extension: abilita MFA per l’utente, utile per VPN o SSID sensibili. Non risolve il device.
Usa una CA dedicata “solo MDM”: emetti certificati da una CA isolata e non pubblicamente fidata, così da impedire che certificati esterni accedano alla rete anche se tecnicamente validi.
Template mirati: differenzia i template (Device vs User) e filtra in NPS per Issuer, EKU, Policy OID proprietarie. Questo riduce il rischio di BYOD con cert “non approvati”.
Segmentazione: usa gli attributi RADIUS (Tunnel‑Type, Tunnel‑Medium‑Type, Tunnel‑Private‑Group‑ID) per assegnare VLAN a minori privilegi quando il certificato non corrisponde ai criteri desiderati.
Conditional Access complementare: anche se non agisce sul RADIUS, CA limita l’accesso alle app Microsoft 365 dalle sole postazioni conformi. Insieme alle VLAN riduce la superficie d’attacco.
Monitoraggio scadenze: sfrutta Intune e la CA per alert proattivi sui certificati in scadenza, evitando interruzioni di servizio.

Modello di policy: esempi utili

Esempio di regola su RADIUS cloud

{
  "if": {
    "all": [
      { "cert.eku": "1.3.6.1.5.5.7.3.2" },
      { "entra.device.exists": true },
      { "entra.device.isCompliant": true },
      { "entra.device.joinType": "AzureADJoined" }
    ]
  },
  "then": {
    "access": "allow",
    "vlan": "corp-10",
    "notes": "Device compliant &amp; managed"
  },
  "else": {
    "access": "allow",
    "vlan": "remediation-30",
    "notes": "Non compliant - quarantine"
  }
}

Esempio di template certificato (solo illustrativo)

Subject: CN=Device-{{DeviceName}}; O=Contoso; OU=MDM
Subject Alternative Name:
  DNS: {{DeviceName}}
  OtherName (custom): deviceId={{DeviceId}}
Key Usage: Digital Signature
Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2)

Nota: l’inclusione del deviceId nel certificato è utile per i RADIUS che sanno leggerlo e interrogarne lo stato su Entra ID. Con NPS resta solo un campo testo.

Implementazione NPS: guida passo‑passo

Prepara la CA: configura una PKI che emetta certificati per user e/o device. Se usi Intune, pubblica profili SCEP/PFX per distribuire i cert.
Installa NPS su Windows Server e registra il server nel dominio (se necessario).
Aggiungi i NAS RADIUS clients (AP, controller, firewall) con segreto condiviso robusto.
Crea le Connection Request Policies: per SSID/VPN specifici, NAS Port Type appropriati, eventuali condizioni per inoltro/terminazione locale.
Crea le Network Policies:
- Condizioni: SSID (Calling‑Station‑Id/Service‑Type), gruppo utenti (se user‑centric), Issuer CA.
- Constraints: Authentication Methods → “Smart Card or other certificate” (EAP‑TLS) oppure “Microsoft: Protected EAP (PEAP)” con EAP‑MSCHAPv2.
- Settings: imposta gli attributi VLAN (Tunnel‑Type=VLAN, Tunnel‑Medium‑Type=IEEE‑802, Tunnel‑Private‑Group‑ID).
(Opzionale) Installa NPS Extension se adotti PEAP‑MSCHAPv2 e vuoi MFA per l’utente.
Verifica CRL/OCSP: il server NPS deve raggiungere i punti di distribuzione liste di revoca e rispondere a OCSP (se usato).
Test end‑to‑end con un device gestito e uno non gestito, validando la corretta assegnazione VLAN/ACL e la gestione degli errori.

Mitigazioni di sicurezza quando resti su NPS

Issuer pinning e EKU pinning nei criteri NPS: accetta solo certificati emessi dalla tua CA MDM e con l’EKU corretto.
Scadenze aggressive per i certificati device (es. 6–12 mesi) con rinnovo automatico via MDM.
VLAN di quarantena per accessi con certificati anomali o profili non conformi.
SSID separati per BYOD, guest e IoT; per IoT senza supplicant 802.1X, usa MAB con ACL strettissime e network micro‑segmentato.
Logging e auditing: centralizza i log NPS (Event ID 6272/6273, Reason Code) e correlali con i registri MDM per capire se i rifiuti dipendono da cert scaduti o configurazioni errate.

FAQ rapide

Posso far mettere il deviceId nel Subject del certificato e far sì che NPS lo verifichi su Entra ID? Puoi inserirlo, ma NPS non lo risolve contro Entra ID. Puoi usarlo solo per matching statici lato NPS o per ispezioni logiche nel RADIUS, se il tuo RADIUS li supporta. L’estensione NPS per Entra MFA mi aiuta con EAP‑TLS? No: l’estensione è per user auth (p.es. PEAP‑MSCHAPv2). Con EAP‑TLS device‑centric non introduce controlli sullo stato del device. Esiste un “connettore” ufficiale Microsoft che abilita NPS a interrogare Entra ID? Ad oggi non è disponibile un connettore nativo. Per il controllo device‑centric servono soluzioni RADIUS/NAC con integrazione API verso Entra/Intune o architetture ibride. Il Hybrid Azure AD Join risolve? Sì, perché il device esiste in AD on‑prem e NPS può mappare il certificato al computer account. Ma si rinuncia al modello cloud‑only e si mantengono DC/GPO.

Raccomandazioni operative

Se vuoi davvero policy device‑centric in cloud‑only: valuta un RADIUS as‑a‑Service integrato con Entra ID/Intune che supporti deviceId e compliance.
Se non c’è budget: resta su autenticazione utente con NPS (EAP‑TLS utente o PEAP‑MSCHAPv2 + MFA), rafforza CA/Intune, segmenta con VLAN/ACL e usa Conditional Access per proteggere le app.
Monitora la roadmap: segui l’evoluzione delle offerte Microsoft in area accesso privato e servizi RADIUS gestiti, nate proprio per colmare il gap tra rete e identità cloud.

Checklist di progetto

Definisci perimetro: SSID/VPN, categorie di device (corp, BYOD, IoT), sedi.
Scegli modello PKI (Cloud PKI vs CA on‑prem) e durata certificati.
Decidi il percorso: NPS “hardening” (user‑centric) o RADIUS cloud (device‑centric).
Mappa le policy: quali attributi fanno “Allow”, quali mandano in quarantena, quali negano.
Prepara runbook di troubleshooting (Event ID, Reason Code NPS, packet capture RADIUS).
Implementa telemetria e report (tasso di successo 802.1X, motivi dei rifiuti, compliance).

Troubleshooting essenziale

Sintomo	Causa probabile	Come verificare	Rimedi
Access‑Reject subito	CA non fidata o cert scaduto	Event Viewer NPS (Reason Code), catena cert sul server	Aggiungi CA a “Trusted Root”, verifica CRL/OCSP
Loop di tentativi EAP	EKU errato / template sbagliato	Esamina cert client: EKU, Key Usage	Correggi template PKI per device/user
MFA non scatta	EAP‑TLS in uso	Verifica metodo in Network Policy	Usa PEAP‑MSCHAPv2 per MFA utente
VLAN errata	Attributi RADIUS non accettati	Trace RADIUS; controlla supporto NAS	Allinea mapping VLAN e formato attributi

Best practice riassuntive

Riduci la fiducia implicita: accetta solo i certificati emessi dalla tua PKI MDM, con EKU/Policy dedicati.
Segmenta by design: VLAN remediation e ACL “deny‑most” per qualsiasi device non perfettamente atteso.
Automatizza: distribuzione profili Wi‑Fi via Intune, rinnovo cert, rotazione segreti RADIUS.
Osservabilità: misura il successo delle autenticazioni e i motivi di rifiuto; nessuna rete è sicura senza dati.
Progetta l’uscita dall’on‑prem: se l’obiettivo è cloud‑only, pianifica la migrazione a un RADIUS con integrazione nativa a Entra ID/Intune.

Conclusione

Oggi NPS non può applicare policy di rete basate su un device cloud‑joined Entra ID leggendo un deviceId dal certificato e interrogando il tenant. Può, al massimo, prendere decisioni sugli attributi del certificato e su criteri statici. Se il requisito è davvero device‑centric in chiave Zero Trust, la strada maestra è un RADIUS integrato con Entra ID/Intune. In mancanza di budget, si può continuare con NPS rafforzando autenticazione utente, PKI e segmentazione, mantenendo sotto controllo la roadmap delle soluzioni Microsoft e l’evoluzione dei servizi RADIUS gestiti.

Appendice – Glossario minimo

EAP‑TLS: metodo EAP che usa TLS e certificati client/server per l’autenticazione.
PEAP‑MSCHAPv2: metodo EAP che incapsula MSCHAPv2 in un tunnel TLS; tipico per autenticazione utente e MFA.
RADIUS: protocollo AAA (Authentication, Authorization, Accounting) usato da access point, VPN, switch.
NPS: implementazione RADIUS di Microsoft su Windows Server.
Entra ID joined / registered / hybrid: stati di registrazione/adesione del dispositivo a Microsoft Entra ID e AD on‑prem.
Compliance: stato gestionale del device (es. tramite Intune) rispetto a policy aziendali.

Messaggio chiave: senza integrazione API verso Entra ID, NPS non può “capire” chi è davvero un device cloud‑only; o rendi visibile il device ad AD (ibrido) o sposti l’intelligenza sul RADIUS.