Un único servidor NPS puede convertirse en la puerta de entrada a toda tu red inalámbrica. Configurarlo para que cada usuario solamente vea el SSID que le corresponde no solo mejora la experiencia, también reduce de forma drástica la superficie de ataque al eliminar intentos de conexión fuera de segmento y hacer más visibles los accesos indebidos.

Visión general de la arquitectura

En un escenario tradicional, los puntos de acceso recopilan las credenciales 802.1X del cliente y las envían al servidor RADIUS (NPS). El NPS consulta Active Directory para validar al usuario, aplica las reglas definidas en las Network Policies y, si corresponde, entrega atributos adicionales (p. ej. VLAN, QoS o ACLs). Aprovecharemos ese mismo flujo pero añadiendo dos comprobaciones clave:

• ¿En qué grupo de seguridad de AD se encuentra el usuario (WiFi‑Alpha o WiFi‑Beeta)?
• ¿Desde qué SSID proviene la solicitud (capturado en Called‑Station‑ID o NAS‑Identifier)?

La combinación de ambos criterios permite otorgar o denegar el acceso con una granularidad prácticamente idéntica a la que obtenemos en redes cableadas con puerto dedicado y 802.1X.

Requisitos previos y buenas prácticas

• Controlador de dominio Windows Server 2016 o posterior (recomendado 2022 para aprovechar TLS 1.3).
• NPS instalado localmente o en servidor independiente unido al dominio.
• Autoridad de certificación (CA) corporativa para emitir un certificado de servidor al NPS (obligatorio si usas PEAP o EAP‑TLS).
• Todos los puntos de acceso configurados para reenviar peticiones 802.1X al servidor RADIUS.
• Computadoras cliente con la raíz de la CA en el almacén Trusted Root Certification Authorities y con la directiva WLAN distribuida mediante GPO o MDM.

Creación de los grupos de seguridad

En Active Directory Users and Computers:

1. Crea dos Global Security Groups denominados WiFi‑Alpha y WiFi‑Beeta.
2. Agrega cada usuario al grupo cuyo SSID deba utilizar. Un usuario puede pertenecer a varios grupos si necesita acceso a múltiples redes.
3. Evita anidar estos grupos dentro de otros que puedan heredar permisos Wi‑Fi de forma no deseada.

Instalación y preparación del rol NPS

1. En Server Manager › Add roles and features instala Network Policy and Access Services.
2. Importa o genera un certificado de servidor con las extensiones EKU Server Authentication y un CN coincidente con el nombre DNS del host.
3. En el NPS Management Console registra el servidor en AD (clic derecho › Register server in Active Directory).

Registro de los puntos de acceso como RADIUS clients

Campo	Valor sugerido	Motivo
Friendly Name	AP Alpha‑01	Identificación humana
Address (IP or DNS)	192.168.50.11	IP de gestión del AP
Shared Secret	(aleatorio, 32 car.)	Protege el canal RADIUS
Vendor Name	RADIUS Standard	Usa estándar salvo que el fabricante requiera atributos especiales

Repite el proceso para cada punto de acceso o, si tu controlador lo permite, registra únicamente la IP del controlador Wi‑Fi.

Creación de las Network Policies

Política “Alpha SSID”

1. Conditions
   • User Groups: WiFi‑Alpha.
   • Called‑Station‑ID: *:Alpha (asterisco para ignorar la BSSID y coincidir solo el sufijo SSID).
2. Constraints
   • Autenticación: PEAP‑MSCHAPv2 o EAP‑TLS según tu infraestructura.
   • Rechazar PAP, CHAP y métodos obsoletos.
3. Settings
   • Action: Grant access.
   • (Opcional) Atributos RADIUS: Tunnel‑Type = VLAN Tunnel‑Medium‑Type = IEEE‑802 Tunnel‑Pvt‑Grp‑ID = 30 para asignar la VLAN 30.

Política “Beeta SSID”

Duplica la anterior y ajusta:

• User Groups = WiFi‑Beeta
• Called‑Station‑ID = *:Beeta
• (Opcional) VLAN diferente, p. ej. 40.

Orden de evaluación

En el panel Policies, mueve “Alpha SSID” y “Beeta SSID” a la parte superior. Bajo ellas, deja una política de denegación genérica para frustrar cualquier intento que no coincida con un grupo/SSID válido.

Distribución de la configuración WLAN al cliente

Una vez que el lado servidor está listo, aún necesitas que los dispositivos conozcan:

• El nombre del SSID.
• Que la autenticación es WPA‑Enterprise con 802.1X.
• Que deben validar el certificado del servidor NPS y la CA emisora.

La forma más fiable es a través de una GPO de Wireless Network (IEEE 802.11) Policies:

Computer Configuration
└─ Policies
   └─ Windows Settings
      └─ Security Settings
         └─ Wireless Network (IEEE 802.11)

Define un perfil por SSID seleccionando el mismo método EAP configurado en NPS. En “Trusted Root Certification Authorities” marca la CA corporativa y habilita la opción “Validate server certificate”. Si utilizas Intune u otra plataforma MDM, replica los mismos parámetros en la plantilla equivalente.

Pruebas de validación paso a paso

1. Conéctate a Alpha con un usuario miembro de WiFi‑Alpha. El inicio de sesión debería completarse en menos de 1 s y se te asignará la VLAN 30 (si la configuraste).
2. Intenta conectarte a Beeta con ese mismo usuario. El cliente recibirá un Access‑Reject del NPS y el intento fallará.
3. Repite la operación a la inversa con un usuario del grupo WiFi‑Beeta.
4. En Event Viewer › Custom Views › Server Roles › Network Policy and Access Services confirma que solo existen Event ID 6272 (Access Granted) para las conexiones permitidas y 6273 (Access Denied) para las bloqueadas.

Auditoría y cumplimiento

Para un entorno regulado (PCI‑DSS, ISO‑27001, ENS MEDIO/ALTO) conviene mantener:

• Logs locales en NPS: habilita Accounting y fija retención ≥ 90 días.
• Forwarding a SIEM vía syslog o API: muchos SIEM decodifican automáticamente atributos RADIUS.
• Alertas en tiempo real para:
  • Más de n rechazos consecutivos desde la misma MAC (posible fuerza bruta).
  • Conexiones exitosas fuera de horario laboral.

Automatización avanzada con Azure AD e Intune

Si tu empresa sincroniza AD con Azure AD, puedes delegar la pertenencia a los grupos WiFi‑Alpha y WiFi‑Beeta a dynamic groups basados en atributos como departamento, ubicación o proyecto. La ventaja es doble:

1. Los cambios se reflejan en cuestión de minutos sin intervención manual.
2. Intune puede desplegar perfiles Wi‑Fi y certificados de forma automática, incluso en dispositivos móviles BYOD gestionados.

En ese caso, asegúrate de que la replicación de grupos (Azure AD Connect) sea bidireccional o emplea Group Writeback para que los cambios vuelvan al AD on‑premises.

Solución de problemas común

Síntoma	Causa probable	Acción
El cliente no solicita certificado del servidor	Perfil WLAN no fuerza la validación de CA	Revisa GPO/Intune y marca “Validate server certificate”
Event ID 18 en cliente (“Bad username or password”)	Usuario no pertenece al grupo correcto	Agrega el usuario a WiFi‑Alpha o WiFi‑Beeta
Event ID 13 en cliente (“Server certificate revoked”)	CRL inaccesible o certificado caducado	Verifica la URL de la CRL y renueva el certificado NPS
Event ID 6273 con razón “Undefined RADIUS Attribute”	AP envía atributos propietarios	Cambia Vendor‑Specific a RADIUS Standard o instala el diccionario del fabricante

Preguntas frecuentes

¿Puedo usar un solo SSID y separar usuarios por VLAN?

Sí. Basta con omitir la condición Called‑Station‑ID y asignar distintas VLAN según pertenencia a grupo. Esta aproximación disminuye el roaming delay al cambiar de AP, pero pierde visibilidad para el usuario.

¿Qué pasa si un usuario pertenece a ambos grupos?

NPS evalúa las políticas en orden. Coloca primero la política más restrictiva o decide la prioridad operativa (p. ej. producción sobre invitados). También puedes añadir una tercera política “Doble acceso” para gestionar casos híbridos.

¿Los dispositivos IoT sin 802.1X pueden convivir?

Lo ideal es aislarlos en un SSID separado con WPA2‑PSK y segmentación de red (ACLs o VLAN). Si deben permanecer en el mismo SSID, limita su acceso a puertos y protocolos mínimos mediante listas de control en el controlador inalámbrico.

Resumen y próximos pasos

Restricción por grupo en NPS es una estrategia sólida, sencilla y al alcance de cualquier organización con Active Directory. Los resultados más tangibles son:

• Menos superficie de ataque: reduces intentos de conexión a SSIDs indebidos.
• Seguridad contextual: cada usuario viaja únicamente por la VLAN o SSID que le corresponde.
• Auditoría precisa: los logs muestran exactamente quién, cuándo y desde qué red accedió.

Dale continuidad al proyecto mediante:

• Rotación periódica de la clave compartida RADIUS.
• Renovación automática del certificado NPS con Autoenroll.
• Integración de NPS con soluciones NAC para políticas basadas en estado del dispositivo.

Con estas prácticas tendrás un entorno inalámbrico escalable y alineado con los requisitos de seguridad modernos.