En muchas implementaciones Wi‑Fi corporativas surge la necesidad de que un mismo servidor Network Policy Server (NPS) funcione a la vez como autoridad de autenticación para los usuarios de Active Directory y como proxy RADIUS que reenvía determinadas solicitudes a otro servidor, por ejemplo a un proveedor de servicios gestionados. A continuación encontrarás una guía completa, probada en Windows Server 2016, para lograrlo sin que el acceso local se interrumpa y garantizando una experiencia perfecta para los clientes UniFi.
Arquitectura y flujo de autenticación
Antes de entrar en los pasos prácticos conviene entender el recorrido de una credencial desde que sale del punto de acceso (AP) hasta que se concede o deniega la conexión:
- El AP UniFi encapsula las credenciales (por ejemplo, EAP‑MSCHAPv2 dentro de PEAP).
- Envía un paquete Access‑Request al NPS local.
- NPS aplica las Connection Request Policies (CRP) en orden descendente:
- Si la solicitud coincide con CRP‑Remoto, actúa como proxy y la envía al servidor del grupo Remote RADIUS Server Group.
- Si coincide con CRP‑Local, procesa la autenticación contra Active Directory.
- NPS (o el servidor remoto) responde con Access‑Accept/Access‑Reject que el AP traduce en “conectado” o “sin acceso”.
Requisitos previos
- Windows Server 2016 con rol NPS y Active Directory Domain Services.
- Consola Network Policy Server en modo avanzado.
- Acceso de administrador para crear políticas y modificar firewall.
- Datos del servidor RADIUS remoto: IP, puertos 1812/1813, secreto compartido y métodos EAP habilitados.
Paso a paso detallado
| Paso | Acción | Detalle clave |
|---|---|---|
| 1 | Crear dos Connection Request Policies | CRP‑Remoto → Forward requests to Remote RADIUS Server Group CRP‑Local → Authenticate requests on this server |
| 2 | Definir la prioridad | Coloca CRP‑Remoto por encima de CRP‑Local. NPS evalúa de arriba abajo. |
| 3 | Aplicar condiciones diferenciadoras | Ejemplos útiles: Realm/Nombre de usuario: @remoto.com, remoto\* SSID o VLAN: “Invitados”, VLAN 20 NAS‑IPAddress o NAS‑Identifier correspondiente a un AP concreto Windows‑Group: grupo de seguridad “Usuarios‑Proveedor” |
| 4 | Crear las Network Policies | Vincula cada CRP con su NP homóloga: NP‑Remoto (solo sirve para requisitos secundarios, ej. controlar la hora de acceso; la decisión final es del servidor remoto). NP‑Local con EAP‑PEAP + MS‑CHAPv2, grupos de AD y restricciones de sesión. |
| 5 | Registrar el servidor remoto | En Remote RADIUS Server Groups crea el grupo, añade la IP y define tiempos de espera razonables (3 s x 2 reintentos) para evitar retrasos perceptibles. |
| 6 | Sincronizar métodos de autenticación | Asegúrate de que ambos NPS aceptan exactamente los mismos tipos EAP. Una divergencia provoca Access‑Reject. |
| 7 | Abrir puertos y revisar firewall | UDP 1812 (Authentication) y UDP 1813 (Accounting) en ambos sentidos. Usa reglas específicas para la IP del peer. |
| 8 | Supervisar con los logs | En Event Viewer → Custom Views → Server Roles → Network Policy and Access Services filtra por: ID 6272 (éxito) y 6273 (error). Nombre de la CRP y NP aplicadas. Atributos enviados y recibidos. |
| 9 | Ajustes finos | Si locales y remotos comparten el mismo realm (p.ej. todos usan @empresa.com), emplea VSA de UniFi (Vendor‑Specific Attribute 01‑08) o propiedades del certificado (SAN) para clasificarlos. |
Por qué fallaban los usuarios locales
Al modificar la única CRP existente para reenviar todas las solicitudes, NPS dejaba de validar localmente; simplemente actuaba como proxy para cada petición procedente de los AP. Al no encontrarse la cuenta en el servidor remoto, se devolvía Access‑Reject. Separar las políticas y controlar la coincidencia resuelve el conflicto.
Buenas prácticas recomendadas
- Entorno de pruebas: crea una SSID oculta o un AP aislado para validar cambios sin afectar a producción.
- Herramientas de test:
radclient(Linux) oNTRadPing(Windows) para enviar paquetes sintéticos.- PowerShell 5.1+:
Test‑NpsAuthentication -User usuario -Password * -Server nps.local -Protocol peap.
- Accounting habilitado: genera registros RADIUS estándar que UniFi Cloud Manager interpreta para informes de presencia y tiempo en línea.
- Documentación: versiona un archivo .csv con el orden, condiciones y fecha de cada CRP/NP.
- Revisiones periódicas: cada semestre comprueba que ningún AP nuevo esté saltándose las políticas esperadas.
Seguridad y cumplimiento
El uso de un NPS double‑role no debe comprometer el principio de mínimo privilegio. Aplica estas salvaguardas:
- Habilita Certificados TLS modernos (SHA‑256, RSA 2048 bits o ECC) en PEAP; renueva antes de 30 días de la expiración.
- Configura Registro de sucesos con integridad: almacena logs en un servidor Syslog WORM o SIEM.
- Implementa NPS Role Separation: cuando sea posible, delega el rol de proxy a un host DMZ dedicado.
- Limita los Shared Secrets a 32 caracteres alfanuméricos y rota cada 90 días.
- Activa Network Access Protection (NAP) o su equivalente moderno (según el dispositivo cliente) para la comprobación de estado.
Escenarios avanzados
Acceso invitados mediante captive portal
UniFi puede derivar las solicitudes del portal cautivo a NPS usando EAP‑TTLS. Define un tercer CRP que identifique el Called‑Station‑ID “Invitados” y reenvíe todo hacia un servidor RADIUS cloud externo.
Redundancia y balanceo
El mismo Remote RADIUS Server Group admite múltiples miembros. El algoritmo es fail‑over tradicional (orden secuencial), pero Windows Server 2022 ya permite round‑robin. En 2016 consigue un efecto similar con NPS pairs y un DNS RR.
Autenticación basada en certificados EAP‑TLS
Para BYOD de alto perfil (ingeniería, I‑o‑T industrial) considera emitir certificados vía Enterprise CA y validar con una NP que requiera Smart Card or other certificate. Así evitas la exposición de contraseñas y habilitas revocación inmediata.
Rendimiento y resolución de problemas
| Síntoma | Posible causa | Acción recomendada |
|---|---|---|
| Retraso de 5‑7 segundos antes de asociar | Timeout/Retry elevados | Reduce a 2 s x 1 reintento. Habilita Message‑Authenticator. |
| Usuarios locales aleatorios son rechazados | Políticas superpuestas | Revisa orden CRP. Añade condición explícita Windows‑Group = Domain Users. |
| Event ID 6273 con razón 16 | Método EAP no admitido | Alinea la lista de métodos entre ambos NPS. Actualiza drivers Wi‑Fi. |
| No hay registros en el servidor remoto | Puertos 1812/1813 bloqueados | Usa Test‑NetConnection -ip remoto -Port 1812 y ajusta firewall. |
| El servidor remoto responde “Access‑Accept” pero el cliente sigue desconectado | UniFi ignora atributo VLAN | Comprueba que la VLAN exista en el switch y que el perfil Wireless la incluya. |
Preguntas frecuentes
¿Puedo usar el mismo certificado SSL para EAP en ambos NPS?
Sí, pero lo aconsejable es generar un certificado por host con el FQDN correspondiente para evitar advertencias y simplificar la rotación.
¿Qué diferencia hay entre una Connection Request Policy y una Network Policy?
La CRP decide dónde y cómo se procesa la solicitud (local o proxy), mientras que la NP define quién obtiene acceso y bajo qué condiciones (métodos de autenticación, horarios, grupos, VLAN, etc.).
¿El orden de las políticas puede romperse al crear nuevas?
Sí. Cada vez que añades una CRP o NP NPS la coloca al final. Revisa y ajusta la prioridad manualmente tras cada cambio para conservar la lógica.
Conclusión
Una estrategia clara de doble política —CRP‑Remoto para reenviar y CRP‑Local para autenticar— es la clave para que un mismo NPS atienda simultáneamente a usuarios internos y externos. Añadir condiciones granulares, mantener los métodos EAP alineados y vigilar la prioridad evitará la mayoría de los problemas comunes. Con la solución aquí descrita tu red Wi‑Fi UniFi dispondrá de un servicio de identidad fiable y flexible, listo para crecer y adaptarse a futuros requisitos.