¿Quieres modernizar tu Wi‑Fi, VPN o red cableada aprovechando solo la nube, pero tu infraestructura sigue dependiendo de Network Policy Server (NPS)? En 2025 la respuesta corta es que NPS aún necesita un dominio AD, pero con planificación puedes acercarte a un modelo “cloud‑only” y sentar las bases para cuando Microsoft libere un servicio RADIUS nativo en Entra ID.

Contexto y desafío

NPS es el rol RADIUS de Windows Server que lleva dos décadas autenticando 802.1X, VPN, dial‑up o NAC. Microsoft Entra ID (antes Azure AD) es, por su parte, la plataforma de identidad en la nube para Microsoft 365 y cientos de miles de SaaS. Combinar ambos mundos promete MFA, passwordless y gobernanza centralizada, pero existe un obstáculo clave: NPS no conoce Entra ID de forma directa. El único puente oficial es la “NPS Extension for Microsoft Entra MFA”, la cual exige que el usuario se compruebe primero en Active Directory local o en IaaS. Así, el inicio de sesión sigue pasando por Kerberos/NTLM antes de escalar a la nube para el segundo factor.

Estado actual de la integración

• Extensión MFA: Único complemento soportado y gratuito. Requiere un DC accesible para la validación de contraseña y réplicas de atributos.
• Restricciones: No sincroniza políticas de Acceso Condicional, no soporta grupos dinámicos de Entra ID, ni despliega RADIUS como servicio gestionado.
• Posición oficial (agosto 2025): Microsoft no ha anunciado GA o vista previa pública de “RADIUS‑as‑a‑Service” dentro de Entra ID. Los comentarios en TechCommunity y Q&A indican que la petición está reconocida pero sin fechas.

Flujo de autenticación paso a paso

1. Un cliente (por ejemplo un portátil con 802.1X) envía una solicitud RADIUS a NPS.
2. NPS consulta el controlador de dominio para verificar contraseña o certificado, según el método EAP utilizado.
3. La extensión reenvía la sesión a Entra ID, que aplica políticas MFA (Authenticator, FIDO2, SMS, etc.).
4. Tras la aprobación del segundo factor, NPS devuelve Access‑Accept con los atributos configurados (VLAN, ACL, QoS).

Observa que los atributos de autorización—grupos, UPN, restricciones horarias—siguen viniendo de AD. Si deseas condicionar el acceso a un “Risky Sign‑In” de Entra ID, no existe un mecanismo estándar con NPS puro.

Análisis de limitaciones técnicas

• Dependencia de Kerberos: El servidor NPS necesita pertenecer al dominio para consultar el KDC. Desconectarlo rompe el proceso de autenticación.
• Sin sincronía en tiempo real: Cambios de grupo o password en Entra ID solo llegan a NPS tras replicarse a AD, lo que introduce latencia o inconsistencias para escenarios de just‑in‑time.
• MFA enrutado: En entornos con cientos de servidores NPS, cada uno debe tener la extensión configurada individualmente; no se ofrece centralización ni auto‑scaling.
• Auditoría fragmentada: Los registros RADIUS se almacenan localmente o en Windows Event Logs; para correlacionarlos con los Sign‑In Logs de Entra ID se requiere SIEM.

Hoja de ruta y posicionamiento de Microsoft

En la conferencia Ignite 2024 Microsoft reiteró que “cloud‑centric authentication” es prioritaria, pero hasta la fecha las inversiones se han enfocado en Passkey, FIDO2 y el nuevo servicio de identidad Entra External ID. Un servicio RADIUS nativo, similar a AWS Managed Microsoft AD + IAM Roles Anywhere, aparece con frecuencia en la voz del cliente, pero no existe una fecha de lanzamiento señalada. El equipo de producto recomienda, entretanto, adoptar soluciones de terceros o mover NPS a máquinas IaaS si tu meta es abandonar el CPD.

Alternativas para un diseño “cloud‑first”

Alternativa	Ventajas	Consideraciones
Azure AD Domain Services (AAD DS)	Dominios gestionados totalmente en Azure; sin controladores locales; NPS se instala en VM bajo la misma VNet.	Coste extra; no replica todas las extensiones de esquema; latencia si el usuario se halla fuera de Azure.
Cloud RADIUS de terceros (JumpCloud, SecureW2, Keytos EZRADIUS, Foxpass, etc.)	Puntos RADIUS escalables multi‑región; integración con Entra ID vía SAML/OIDC o sincronía SCIM; soporte EAP‑TLS y certificados Intune.	Suscripciones mensuales; revisar cumplimiento y soberanía de datos; cierta re‑ingeniería de políticas de seguridad.
Dispositivos/VPN con autenticación Entra ID nativa	Firewalls de nueva generación (Fortinet, Palo Alto, Cisco FTD, Check Point), Azure VPN Gateway y muchos controladores Wi‑Fi actuales permiten OIDC/SAML directo.	Puede requerir cambios de firmware o licencias; funcionalidades ACL basadas en grupo varían entre fabricantes.
EAP‑TLS con certificados emitidos desde Intune o AutoPilot	Elimina contraseña; imposible de “phishing”; combinación natural con dispositivos gestionados; compatibilidad con Cloud RADIUS.	Necesita PKI (SCEP o Prefijo Intune) y ciclo de vida de certificados; para invitados se requiere método alternativo.

Buenas prácticas de diseño y operación

• Alta disponibilidad: Ejecuta al menos dos instancias de RADIUS (o dos proveedores PoP) detrás de un balanceador UDP 1812/1813. Configura reintentos cortos para evitar demoras en la conexión.
• Protocolo EAP: Utiliza EAP‑TLS siempre que sea viable. Descarta PAP/CHAP; si un equipo heredado lo requiere, restringe su VLAN y aplica políticas NAC.
• Logs centralizados: Exporta los registros RADIUS a un SIEM (Microsoft Sentinel, Splunk, Graylog) con correlación hacia los Sign‑In Logs de Entra ID para obtener vista unificada de inicio de sesión.
• Conditional Access: Implementa políticas de riesgo y Compliant Device en Entra ID. Si tu RADIUS es de terceros, verifica que admita “step‑up MFA” o “Zero Trust Posture”.
• Segmentación: Aísla servidores NPS o Cloud RADIUS en subredes protegidas; solo puertos UDP 1812/1813 deben exponerse a los dispositivos clientes o NAS.

Casos de uso frecuentes

Wi‑Fi corporativo 802.1X

En oficinas donde cada portátil gestiona su certificado a través de Intune, un Cloud RADIUS proporciona autenticación omnipresente con enclaves regionales. Para invitados, se habilita un portal cautivo que delega en Entra ID o un IdP social.

VPN site‑to‑site y usuario‑a‑sitio

Azure VPN Gateway y Cisco AnyConnect ya pueden federarse con Entra ID. Deshabilitar NPS simplifica el diagrama y elimina la puerta de enlace AD.

Acceso cableado en campus

Conmutadores que soportan MAB para impresoras pueden coexistir con EAP‑TLS en PCs; la decisión VLAN reside en atributos RADIUS devueltos desde el proveedor cloud.

Arquitectura de referencia

Para un entorno de 5 000 usuarios con todo en la nube:

• Azure AD Connect se retira; las cuentas viven solo en Entra ID.
• Cloud RADIUS con puntos en East US y West Europe.
• Intune emite certificados usando PKCS#7 o SCEP; expiración = 1 año.
• Firewall NGFW integra SAML con Entra ID para VPN y portal de invitados.
• Sentinel recoge logs via Syslog/CEF y Connector for M365 Defender.

Coste estimado y licenciamiento

Los precios varían, pero un cálculo TCO de tres años muestra:

• Máquinas IaaS NPS (A vm) + AAD DS: ~1 800 USD/mes (dos VM, Azure Files, AD DS Standard).
• Cloud RADIUS gestionado: ~1 200 USD/mes (5 000 usuarios, dos regiones, soporte 24×7).
• Dispositivo Wi‑Fi con OIDC nativo: Cero coste RADIUS, pero posible licencia enhanced security en el controlador.

Además, Entra ID P1 es obligatorio para MFA y Conditional Access; P2 agrega Identity Protection y Privileged Identity Management, muy recomendables si tu red corporativa controla acceso crítico.

Preguntas frecuentes (FAQ)

¿Puedo instalar la extensión MFA sin exponer los DC fuera de la red? Sí. La extensión solo necesita salida HTTPS a Entra ID; ningún puerto entrante desde Internet. ¿Existe soporte para autenticación FIDO2 desde NPS? No directamente. FIDO2 se utiliza solo en la fase MFA; la primera fase de NPS sigue siendo contraseña o certificado. ¿Cómo revoco acceso de un usuario comprometido si no hay DC? Con Cloud RADIUS, la revocación ocurre mediante SCIM o API en segundos; con NPS estándar debes deshabilitar la cuenta en AD y esperar replicación.

Próximos pasos recomendados

1. Evalúa Azure AD Domain Services si tu prioridad es migrar DC al cloud sin rediseñar políticas NPS.
2. Realiza un piloto con Cloud RADIUS y EAP‑TLS, habilitando passwordless en el 10 % de la plantilla.
3. Monitorea el roadmap público de Entra ID (Ignite, Build, TechCommunity) y prueba cualquier private preview de RADIUS nativo cuando aparezca.

Conclusión

Pasar de un modelo on‑prem basado en NPS a una autenticación cien por ciento nube no es todavía tan sencillo como pulsar un botón, pero la combinación de Cloud RADIUS, Conditional Access y certificados gestionados aproxima tu red a la filosofía Zero Trust. Mientras Microsoft madura su oferta nativa, adoptar estas prácticas asegura compatibilidad a futuro y reduce tu superficie de ataque hoy mismo.