NPS no puede validar certificados EAP‑TLS usando el DeviceID de equipos unidos sólo a Entra ID; para lograr autenticación basada en dispositivos debes optar por Hybrid Join, cambiar a un RADIUS «cloud‑aware» o aprovechar Azure AD CBA. A continuación encontrarás el análisis completo, alternativas y guía de migración.
Contexto: por qué la autenticación de dispositivos importa
En infraestructuras Wi‑Fi o VPN empresariales, la autenticación basada en certificados de dispositivo (EAP‑TLS) ofrece dos ventajas determinantes frente a credenciales de usuario:
- Cero factor humano: el usuario no gestiona contraseñas ni OTP para la conexión automática.
- Control de estado corporativo: sólo dispositivos administrados y en conformidad logran conectarse.
En el ecosistema Microsoft, la pieza tradicional para entregar RADIUS es Network Policy Server (NPS), mientras que la identidad de nube vive en Entra ID (antes Azure AD). El choque aparece cuando el dispositivo existe únicamente en Entra ID y no está representado en el Directorio Activo local.
Cómo funciona realmente NPS bajo el capó
NPS fue concebido para trabajar con Active Directory Domain Services (AD DS):
- Recibe la solicitud RADIUS (por ejemplo, de un controlador Wi‑Fi).
- Desencapsula EAP‑TLS, comprueba la cadena de certificados contra la CA autorizada y extrae el atributo
Subject/SubjectAltName. - Consulta el atributo
samAccountName(o mapea el UPN) contra AD DS. - Evalúa la Network Policy (grupos, autenticación, propiedad, etc.).
El resultado de esa búsqueda determina si el dispositivo (o usuario) existe y cumple los requisitos. Si el objeto no se encuentra, la autenticación falla; aquí radica el problema para entornos cloud‑only.
¿Qué es el DeviceID y por qué no basta?
Con Intune o cualquier MDM puedes emitir un certificado que incluya en SubjectAltName el ID de dispositivo de Entra ID. Sin embargo, NPS no sabe llamar a Entra ID para validar esa identidad:
- No existe un driver ni API en NPS que traduzca
DeviceID→ objeto Entra ID. - Todas las llamadas LDAP/GC se limitan al bosque AD local.
- La extensión NPS Extension for Azure MFA solo delega autenticación de usuario, no resuelve dispositivos.
En consecuencia, el certificado se considerará “huérfano” para el RADIUS y la conexión será rechazada.
Escenarios hoy soportados
Dispositivos Hybrid Azure AD Join
Si el equipo está unido a AD DS y registrado en Entra ID, NPS puede mapear el certificado porque el objeto de equipo existe en AD. La autenticación es totalmente compatible con EAP‑TLS tradicional.
NPS con autenticación de usuario
Para Wi‑Fi basado en usuario, puedes incorporar la extensión MFA y delegar la comprobación de segundo factor a Entra ID; el certificado se expide al usuario, no al dispositivo.
RADIUS de terceros con conector Entra ID
- Soluciones Cloud RADIUS SaaS (SecureW2, JumpCloud, PacketFence).
- Plataformas on‑prem como Cisco ISE o Aruba ClearPass con plugin OAUTH/OIDC.
Estas opciones autentican el DeviceID contra Entra ID directamente vía Graph o SCIM.
Azure AD Certificate Based Authentication (CBA)
Servicio gestionado de Entra ID (actualmente GA) que acepta certificados X.509 emitidos por tu CA o Intune y actúa como Identity Provider para Wi‑Fi/VPN Gateway de Azure. No utiliza NPS y, por tanto, carece del bloqueo descrito.
Por qué no funcionará en dispositivos solo Entra ID
Aunque importes la CA raíz y NPS confíe en ella, la etapa crítica es la coincidencia del certificado con un objeto de directorio. Al no haber entrada en AD DS, el proceso se rompe antes de evaluar políticas:
| Fase | Necesidad de AD | Implicación para Entra ID joined |
|---|---|---|
| Validación de cadena | No | Funciona (CA conocida) |
| Extracción de identidad | No | Funciona (DeviceID leído) |
| Lookup de objeto | Sí | Falla (objeto no existe en AD) |
| Evaluación de grupos | Sí | N/A |
Alternativas prácticas
Hacer Hybrid Join y mantener NPS
Pros:
- Sin cambios en infra Wi‑Fi/VPN ni políticas NPS.
- Beneficios de GPO y autenticación Kerberos en campus.
Contras:
- Requiere ADConnect y sincronización de dispositivos.
- Mayor superficie de ataque on‑prem.
Adoptar un RADIUS «cloud‑aware»
Pros:
- Elimina dependencia de AD DS.
- Orquestación simplificada con Intune (Zero‑Touch enrollment).
- Integración con políticas de acceso condicional Entra ID.
Contras:
- Licenciamiento adicional (SaaS o appliance).
- Curva de aprendizaje en la gestión de políticas.
Migrar a Azure AD CBA
Pros:
- Servicio PaaS gestionado por Microsoft, HA por diseño.
- Políticas de Conditional Access aplicables a la identidad del dispositivo.
Contras:
- Compatibilidad limitada a gateways o puntos de acceso que soporten SAML/OIDC.
- Alineación de PKI y perfil de certificados con los requisitos de CBA.
Pasos de transición recomendados
- Avalúa tu topología actual: volumen de dispositivos, puntos de autenticación, CA, TLS versión.
- Define el objetivo: continuidad con NPS (Hybrid) o paso a cloud RADIUS/Azure CBA.
- Pilota con un grupo reducido: mide tiempos de onboarding, logs y experiencia de usuario.
- Actualiza documentación y formación: helpdesk, SOP y planes de recuperación.
- Plan de desmantelamiento (si aplica): apagar NPS cuando todos los clientes usen la nueva ruta.
Preguntas frecuentes
¿Puedo extender NPS con un plugin personalizado contra Graph API?
En teoría, un custom authentication DLL podría hacer esa consulta, pero Microsoft no publica SDK oficial y romperías soporte.
¿Funciona la extensión «NPS Extension for Azure MFA» para esto?
No. Esa extensión solo intercepta usuarios; el flujo de dispositivo nunca se desvía a Azure MFA.
¿Qué pasa con los routers Wi‑Fi que traen su propio RADIUS?
Si el fabricante integra OAUTH 2.0 u OpenID Connect, puedes federar con Entra ID sin necesidad de NPS ni AD DS.
Comparativa rápida de opciones
| NPS + Hybrid Join | RADIUS Cloud‑Aware | Azure AD CBA | |
|---|---|---|---|
| Dependencia AD DS | Alta | None | None |
| Licencias extra | No | Variable | Incluido en Entra ID P1+ |
| Control granular Wi‑Fi | Alto | Alto | Medio (depende del gateway) |
| Conditional Access | Limitado | Completo | Completo |
| Mantenimiento infra | Alto | Bajo (SaaS) | Bajo (PaaS) |
Conclusión
Mientras NPS siga anclado a Active Directory, la autenticación de dispositivo puro para equipos unidos solo a Entra ID no es factible sin una capa adicional. Decidir entre Hybrid Join, un RADIUS moderno o Azure AD CBA dependerá de tu apetito por mantener infraestructura on‑prem y del grado de integración con políticas de acceso condicional que necesites. Evalúa coste, complejidad y hoja de ruta tecnológica antes de elegir.
Resumen ejecutivo
| Punto clave | Detalle |
|---|---|
| Capacidad nativa de NPS | Solo resuelve objetos de AD DS; carece de integración con Entra ID para DeviceID. |
| Conclusión práctica | No hay device auth para Cloud‑only; debes usar Hybrid Join o sustituir NPS. |
| Opciones viables | 1) Hybrid Join + NPS 2) RADIUS con integración Entra ID 3) Intune + Azure AD CBA |
| Expectativa de futuro | Microsoft no planea añadir esta función a NPS; tendencia a servicios cloud native. |
Al adoptar la ruta correcta garantizarás una postura Zero Trust coherente y una experiencia de acceso silenciosa y segura para tus usuarios.