Resolución de problemas de fallos de autenticación 802.1X (RADIUS/EAP)
Guía de diagnóstico paso a paso para resolver errores de autenticación 802.1X, EAP-TLS, PEAP y RADIUS en redes WiFi empresariales.
Video overview
Escuchar esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de seguridad de WiFi empresarial →
Resumen Ejecutivo
Para los responsables de TI que gestionan redes WiFi empresariales en hoteles, cadenas de tiendas, estadios y recintos del sector público, la autenticación 802.1X es la columna vertebral del control de acceso a la red - y cuando falla, el impacto es inmediato y operativamente grave. Un único perfil de suplicante mal configurado, un certificado RADIUS caducado o un secreto compartido discrepante pueden bloquear a cientos de usuarios simultáneamente, lo que provoca una escalada de incidencias de soporte, pérdida de ingresos y posibles infracciones de cumplimiento normativo.
El estándar IEEE 802.1X define el control de acceso a la red basado en puertos, operando en la Capa 2 del modelo OSI. Funciona en combinación con el Protocolo de Autenticación Extensible (EAP) y un servidor RADIUS para autenticar cada dispositivo antes de conceder acceso a la red. El protocolo admite múltiples métodos EAP - EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS y EAP-FAST - cada uno con distintos perfiles de seguridad, requisitos de certificados y complejidad operativa.
Esta guía proporciona un marco de diagnóstico estructurado para resolver fallos de 802.1X a lo largo de la cadena de autenticación de tres componentes: el Suplicante (dispositivo final), el Autenticador (punto de acceso o switch) y el Servidor de Autenticación (RADIUS). Incluye casos de estudio del mundo real, un árbol de decisión para un triaje rápido, mejores prácticas de implementación alineadas con los estándares PCI-DSS v4.0 y WPA3-Enterprise, y una biblioteca de ejemplos prácticos extraídos de despliegues en hostelería y comercio minorista.
Para las organizaciones que despliegan WiFi de invitados junto con redes de personal, comprender dónde falla 802.1X - y cómo solucionarlo rápidamente - es una prioridad operativa y comercial directa.
Análisis Técnico Detallado
La Arquitectura de Autenticación 802.1X
El estándar IEEE 802.1X define un modelo de tres componentes que gobierna cada intercambio de autenticación WiFi empresarial. Comprender el papel de cada componente es el requisito previo para una resolución de problemas eficaz.
El Suplicante es el dispositivo del usuario final - un portátil, smartphone, tableta o terminal de punto de venta. Ejecuta un componente de software (el cliente suplicante, integrado en el sistema operativo en Windows, macOS, iOS y Android) que inicia el intercambio EAP y presenta las credenciales a la red. La configuración del suplicante - específicamente el método EAP, los ajustes de confianza del certificado y la fuente de las credenciales - es una de las fuentes más comunes de fallos de autenticación.
El Autenticador es el punto de acceso inalámbrico o el conmutador gestionado. Es fundamental tener en cuenta que el Autenticador no toma decisiones de autenticación. Actúa como un relé sin estado, bloqueando todo el tráfico de datos en el puerto controlado hasta que el servidor RADIUS emite una decisión de autorización. Se comunica con el Suplicante utilizando tramas EAPOL (EAP sobre LAN) a través del medio inalámbrico o por cable, y con el servidor RADIUS utilizando paquetes RADIUS Access-Request y Access-Accept/Reject a través de los puertos UDP 1812 (autenticación) y 1813 (contabilidad).
El Servidor de autenticación es el servidor RADIUS. Aquí es donde se produce la validación real de las credenciales. El servidor RADIUS negocia el método EAP con el Suplicante, valida las credenciales frente a un directorio de identidad (Active Directory, Azure AD, Okta o LDAP) y devuelve un Access-Accept con atributos opcionales de asignación de VLAN, o un Access-Reject con un código de motivo. En los despliegues modernos, este servicio está cada vez más alojado en la nube - consulte Cómo implementar la autenticación 802.1X con Cloud RADIUS para obtener una guía de implementación completa.
Comparación de métodos EAP
EAP no es un método de autenticación único, sino un marco de trabajo que admite múltiples métodos internos. La elección del método EAP tiene implicaciones directas en el nivel de seguridad, los requisitos de la infraestructura de certificados y los tipos de fallos que es probable que encuentre.
| Método EAP | Requisito de certificado | Nivel de seguridad | Complejidad del despliegue | Caso de uso principal |
|---|---|---|---|---|
| EAP-TLS | Mutuo (cliente + servidor) | El más alto | Alta (requiere PKI + MDM) | Dispositivos corporativos gestionados |
| PEAP-MSCHAPv2 | Solo en el servidor | Medio | Media | Entornos integrados en AD |
| EAP-TTLS | Solo en el servidor | Medio | Media | Entornos BYOD con sistemas operativos mixtos |
| EAP-FAST | Ninguno (utiliza PAC) | Medio-Alto | Baja | Soporte para dispositivos heredados |
WPA3-Enterprise con EAP-TLS es la mejor práctica actual del sector para flotas de dispositivos corporativos gestionados. Para los establecimientos que despliegan Guest WiFi y redes de personal en paralelo - algo habitual en entornos de Hospitality y Retail - es común un enfoque híbrido: EAP-TLS para dispositivos corporativos y Captive Portal con backend RADIUS para invitados.
El flujo de autenticación: paso a paso
Comprender la secuencia precisa del intercambio 802.1X es esencial para identificar dónde se produce un fallo. El flujo se desarrolla de la siguiente manera:
- El Suplicante se asocia con el SSID. El Autenticador abre un puerto controlado, bloqueando todo el tráfico que no sea EAP.
- El Autenticador envía un EAP-Request/Identity al Suplicante.
- El Suplicante responde con un EAP-Response/Identity (la identidad del usuario o dispositivo).
- El Authenticator encapsula esto en una solicitud RADIUS Access-Request y la reenvía al servidor RADIUS.
- El servidor RADIUS emite un Access-Challenge, proponiendo el método EAP (por ejemplo, EAP-TLS o PEAP).
- El Supplicant y el servidor RADIUS negocian el método EAP e intercambian credenciales a través de múltiples viajes de ida y vuelta de Access-Request / Access-Challenge, retransmitidos por el Authenticator.
- El servidor RADIUS valida las credenciales contra el directorio de identidad y devuelve un Access-Accept (con atributos opcionales de asignación de VLAN) o un Access-Reject (con un código de motivo).
- Si se acepta, el Authenticator abre el puerto controlado y el dispositivo obtiene acceso a la red. Para WPA2/WPA3-Enterprise, se realiza a continuación un protocolo de acuerdo de 4 vías (4-Way Handshake) para derivar las claves de cifrado de la sesión.
Un fallo en cualquier paso de esta secuencia produce un perfil de síntomas diferente. Asociar el síntoma con el paso correspondiente es la base para un triaje rápido.
Modos de fallo comunes e indicadores de diagnóstico
Modo de fallo 1: Caducidad del certificado (servidor o cliente)
Este es el modo de fallo más disruptivo en los despliegues de producción de 802.1X. Cuando el certificado TLS del servidor RADIUS caduca, todos los clientes fallan la autenticación simultáneamente - una interrupción completa de la red. Cuando caduca un certificado de cliente (en despliegues EAP-TLS), los dispositivos individuales fallan mientras que otros continúan autenticándose normalmente.
Indicadores de diagnóstico: Los registros de eventos de NPS/RADIUS muestran el Código de motivo 22 ("El certificado de cliente ha caducado o aún no es válido") o el Código de motivo 16 ("La autenticación falló debido a una discrepancia de credenciales de usuario"). En Windows NPS, compruebe el ID de evento 6273 en el registro de eventos de seguridad. En FreeRADIUS, busque TLS Alert read:fatal:certificate expired en la salida de depuración.
Resolución: Renueve el certificado caducado y distribuya el certificado de CA actualizado a todos los clientes a través de MDM. Implemente una monitorización automatizada de la caducidad de certificados con un umbral de alerta de 90 días.
Modo de fallo 2: Discrepancia en el secreto compartido de RADIUS
El secreto compartido se utiliza para autenticar los mensajes RADIUS entre el Authenticator y el servidor RADIUS. Una discrepancia hace que el servidor RADIUS descarte silenciosamente los paquetes Access-Request. Desde la perspectiva del AP, el servidor RADIUS parece no responder.
Indicadores de diagnóstico: Los registros del AP muestran tiempos de espera agotados y retransmisiones de RADIUS. El servidor RADIUS no muestra entradas de registro correspondientes para los intentos fallidos - las solicitudes se descartan antes de ser procesadas. Una captura de Wireshark en la interfaz del servidor RADIUS mostrará paquetes UDP entrantes en el puerto 1812 que se descartan silenciosamente.
Resolución: Verifique y sincronice el secreto compartido tanto en el Authenticator (configuración del AP/controlador) como en el servidor RADIUS (configuración del cliente NAS). Utilice un secreto fuerte generado aleatoriamente de al menos 32 caracteres. Implemente RadSec (RADIUS sobre TLS) para eliminar la dependencia del secreto compartido en los despliegues de RADIUS en la nube.
Modo de fallo 3: Configuración incorrecta del perfil del Supplicant
En implementaciones PEAP-MSCHAPv2, los clientes deben configurarse para validar el certificado del servidor RADIUS frente a una CA de confianza. Si la validación del certificado está desactivada - un atajo común durante el despliegue inicial - la red es vulnerable a ataques de captación de credenciales mediante AP falsos. Si se confía en una CA incorrecta, o si el CN/SAN del certificado del servidor no coincide con el nombre de servidor configurado, la autenticación fallará.
Indicadores de diagnóstico: Dispositivos individuales fallan mientras otros funcionan correctamente. Los registros de RADIUS muestran fallos en el saludo EAP-TLS o en el establecimiento del túnel PEAP. En Windows, el ID de evento WLAN-AutoConfig 8001 o 8002 en el registro Operational indica fallos en el lado del suplicante.
Resolución: Despliegue perfiles de WiFi estandarizados a través de MDM (Microsoft Intune, Jamf o equivalente). Asegúrese de que el certificado de la CA de confianza esté incluido en el perfil y de que se aplique la validación del certificado del servidor. Nunca desactive la validación de certificados en producción.
Modo de fallo 4: Problemas de tránsito de red (fragmentación de MTU)
Los intercambios EAP-TLS implican la transmisión de cadenas de certificados completas, lo que puede generar paquetes RADIUS de gran tamaño. Si la ruta WAN entre el autenticador y un servidor RADIUS en la nube tiene una MTU baja (común en ciertas configuraciones MPLS o SD-WAN), estos paquetes pueden fragmentarse. Muchos cortafuegos y dispositivos de inspección de estado descartan los paquetes UDP fragmentados, lo que hace que el saludo TLS se detenga de forma silenciosa.
Indicadores de diagnóstico: La autenticación EAP-TLS falla de forma intermitente o constante en sitios conectados a través de WAN, mientras que los sitios con RADIUS local funcionan correctamente. Las capturas de paquetes muestran que los paquetes RADIUS Access-Request se fragmentan en la interfaz WAN. La autenticación tiene éxito cuando el servidor RADIUS está en la LAN local.
Resolución: Despliegue RadSec (RADIUS sobre TLS en el puerto TCP 2083). TCP gestiona la fragmentación y la retransmisión de forma nativa, eliminando por completo este modo de fallo. Como alternativa, ajuste la MTU en la interfaz WAN o configure los parámetros de fragmentación de RADIUS en el servidor.
Modo de fallo 5: Fallo de conectividad del directorio de identidad
El servidor RADIUS debe poder comunicarse con el directorio de identidad (Active Directory, LDAP, Azure AD) para validar las credenciales. Un fallo de DNS, un cambio en las reglas del cortafuegos o una caída del controlador de dominio harán que fallen todos los intentos de autenticación, aunque el propio servicio RADIUS funcione correctamente.
Indicadores de diagnóstico: Los registros del servidor RADIUS muestran que se reciben intentos de autenticación pero fallan con "No se puede contactar con el servidor LDAP" o errores equivalentes. ID de evento NPS 6273 con código de motivo 16 o 66. Es posible que el propio control de estado del servidor RADIUS no refleje esto si no se monitoriza explícitamente la conectividad con el directorio.
Resolución: Implemente una monitorización de estado dedicada para la ruta de conexión entre RADIUS y el directorio. Configure múltiples controladores de dominio o réplicas LDAP como objetivos de conmutación por error. Para despliegues de RADIUS en la nube, asegúrese de que la integración con el proveedor de identidad (Azure AD Connect, proxy LDAP) esté incluida en su monitorización de disponibilidad.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.
Guía de implementación
Fase 1: Validación previa al despliegue
Antes de desplegar 802.1X a gran escala, valide los siguientes requisitos previos. Omitir esta fase es la causa principal de fallos tras el despliegue.
En primer lugar, confirme que el certificado de su servidor RADIUS ha sido emitido por una CA en la que confían todas las plataformas de dispositivos clientes de su parque. En Windows, esto significa que la CA debe estar en el almacén de Entidades de certificación raíz de confianza. En iOS y Android, el certificado de la CA debe distribuirse explícitamente mediante perfiles MDM. No utilice certificados autofirmados en entornos de producción.
En segundo lugar, verifique la conectividad de red entre todos los autenticadores (puntos de acceso y switches) y el servidor RADIUS en los puertos UDP 1812 y 1813. Utilice un cliente de prueba RADIUS (como radtest en Linux o la herramienta de prueba NPS en Windows) para confirmar la autenticación de extremo a extremo antes de realizar el despliegue en SSIDs de producción.
En tercer lugar, valide la integración del directorio de identidades. Confirme que el servidor RADIUS puede realizar vinculaciones LDAP y consultas de pertenencia a grupos en su directorio. Realice pruebas con una cuenta de servicio y verifique que se devuelven los atributos de asignación de VLAN esperados en la respuesta Access-Accept.
Fase 2: Selección del método EAP y estrategia de certificados
Para los dispositivos corporativos gestionados, despliegue EAP-TLS con certificados de cliente distribuidos a través de MDM. Esto elimina el riesgo de robo de credenciales y ofrece la postura de autenticación más sólida. Asegúrese de que su plataforma MDM esté configurada para renovar automáticamente los certificados de cliente antes de que expiren.
Para entornos con dispositivos no gestionados o BYOD, PEAP-MSCHAPv2 es la opción más pragmática. Obligue a validar el certificado del servidor en todos los perfiles de cliente. Nunca distribuya perfiles de WiFi con la validación de certificados desactivada.
Para los dispositivos heredados (sensores IoT, terminales de punto de venta antiguos) que no pueden ejecutar un suplicante 802.1X, implemente MAC Authentication Bypass (MAB) como alternativa. Asigne los dispositivos MAB a una VLAN altamente restringida con reglas de firewall explícitas que limiten su acceso a la red únicamente a los servicios que requieran.
Fase 3: Despliegue y monitorización
Realice el despliegue de forma escalonada: haga un piloto con un grupo controlado de 20 a 50 dispositivos, valide los registros de autenticación, confirme la asignación de VLAN y verifique los registros de contabilidad antes de ampliarlo a todo el parque. Para despliegues en grandes espacios - estadios, centros de conferencias, hoteles - este enfoque escalonado es esencial para contener el radio de impacto de cualquier error de configuración.
Implemente una monitorización continua de: la expiración del certificado del servidor RADIUS (alerta a los 90 días), la disponibilidad y el tiempo de respuesta del servidor RADIUS, las tasas de éxito y fallo de autenticación por SSID y sitio, y la conectividad del directorio de identidades. Para entornos de Sanidad y Retail sujetos a auditorías normativas, asegúrese de que los registros de contabilidad de RADIUS se conserven durante el periodo requerido (normalmente 12 meses según PCI-DSS).Para despliegues en el sector del Transporte y en grandes recintos públicos, considere la posibilidad de desplegar servidores RADIUS redundantes con conmutación por error automática. Un único servidor RADIUS representa un punto único de fallo para toda la infraestructura de control de acceso a la red.
Buenas prácticas
Las siguientes buenas prácticas se basan en las especificaciones IEEE 802.1X, WPA3-Enterprise, los requisitos de PCI DSS v4.0 y la experiencia operativa en despliegues en recintos empresariales.
La gestión del ciclo de vida de los certificados es el control operativo de mayor prioridad. Implemente una monitorización automatizada con alertas a los 90, 60 y 30 días antes del vencimiento para todos los certificados de servidor RADIUS. Para despliegues EAP-TLS, extienda esta monitorización a los certificados de cliente a través de su plataforma MDM. El vencimiento de los certificados es la causa principal de las interrupciones masivas de autenticación en despliegues 802.1X en producción.
El despliegue de RadSec debería ser la opción por defecto para cualquier despliegue de 802.1X en el que el tráfico RADIUS atraviese la internet pública o una WAN. RadSec (RFC 6614) encapsula RADIUS en TLS sobre TCP, lo que proporciona seguridad en el transporte, elimina los problemas de fragmentación UDP y suprime la dependencia de secretos compartidos. La mayoría de las plataformas modernas de RADIUS en la nube y los proveedores de AP empresariales son compatibles con RadSec.
Los perfiles de cliente impuestos por MDM eliminan la mayor fuente de errores de configuración del suplicante. Todos los dispositivos propiedad de la empresa deben recibir sus perfiles WiFi a través de MDM, no mediante configuración manual. Los perfiles deben incluir el certificado de CA de confianza, exigir la validación del certificado del servidor y especificar el método EAP correcto y la configuración de autenticación interna.
La segmentación de red mediante asignación dinámica de VLAN es un control obligatorio para el cumplimiento de PCI DSS y una pieza fundamental de la arquitectura de red Zero Trust. Configure las políticas de autorización de RADIUS para asignar a los usuarios a la VLAN adecuada en función de su pertenencia a grupos - el personal a la VLAN corporativa, los invitados a una VLAN aislada solo para internet, y los dispositivos IoT a una VLAN de gestión restringida. Esto limita el radio de impacto de cualquier dispositivo comprometido.
La retención de registros de contabilidad de RADIUS proporciona la pista de auditoría exigida por el requisito 10 de PCI DSS y es esencial para la investigación forense tras un incidente de seguridad. Asegúrese de que los registros de contabilidad capturen los eventos de inicio y finalización de sesión, la identidad del usuario, la dirección MAC del dispositivo, la VLAN asignada, la duración de la sesión y el volumen de datos. Integre la contabilidad de RADIUS con su SIEM para la detección de anomalías en tiempo real.
Para las organizaciones que despliegan WiFi Analytics junto con 802.1X, la combinación de los datos de autenticación por usuario y la analítica proporciona una potente capa de inteligencia operativa - lo que permite el análisis del tiempo de permanencia, la planificación de la capacidad y la detección de anomalías a nivel de sesión individual.
Solución de problemas y mitigación de riesgos
Marco de triaje rápido
Cuando se informa de un fallo de autenticación 802.1X, la primera pregunta de diagnóstico determina toda la ruta de solución de problemas: ¿Afecta esto a un solo usuario/dispositivo o a todos los usuarios de la red?
Si el fallo afecta a todos los usuarios simultáneamente, la causa principal es casi seguro a nivel de infraestructura: un certificado de servidor RADIUS caducado, una caída del servidor RADIUS, una discrepancia de secreto compartido tras un cambio de configuración o un fallo de conectividad entre el autenticador y el servidor RADIUS. Comience por comprobar la disponibilidad del servidor RADIUS y la validez del certificado.
Si el fallo afecta a un solo usuario o dispositivo, la causa principal es casi seguro a nivel de cliente: un certificado de cliente caducado (EAP-TLS), una configuración incorrecta del perfil del suplicante, credenciales incorrectas o un problema de software específico del dispositivo. Comience por comprobar el almacén de certificados del cliente y la configuración del suplicante.
Conjunto de herramientas de diagnóstico
Las siguientes herramientas son esenciales para la resolución de problemas de 802.1X en diferentes componentes de la infraestructura.
| Herramienta | Plataforma | Caso de uso |
|---|---|---|
| NPS Event Log (Event IDs 6272/6273) | Windows Server | Éxito/fallo de autenticación RADIUS con códigos de motivo |
| WLAN-AutoConfig Operational Log | Windows Client | Fallos de intercambio EAP en el lado del suplicante |
| CAPI2 Event Log | Windows Client | Fallos de validación de certificados |
debug radius authentication |
Cisco IOS/WLC | Depuración del intercambio RADIUS en el autenticador |
radiusd -X |
FreeRADIUS | Salida de depuración completa que incluye la negociación EAP |
| Wireshark (filtro EAPOL) | Cualquiera | Captura de paquetes del lado del cliente de tramas EAP |
| Wireshark (filtro EAP) | Cualquiera | Captura de paquetes RADIUS del lado del servidor |
radtest |
Linux | Prueba manual de autenticación RADIUS |
Referencia de códigos de motivo de NPS
El ID de evento 6273 de Microsoft NPS (fallo de autenticación) incluye un código de motivo que identifica directamente la causa del fallo. Los códigos más significativos desde el punto de vista operativo son:
| Código de motivo | Descripción | Causa principal probable |
|---|---|---|
| 16 | Error de autenticación debido a discrepancia de credenciales de usuario | Contraseña incorrecta, certificado de cliente caducado o fallo de búsqueda en el directorio |
| 22 | El certificado de cliente ha caducado o aún no es válido | Caducidad del certificado de cliente - comprobar la renovación del certificado MDM |
| 23 | La cuenta de usuario ha caducado | Caducidad de la cuenta de AD - comprobar el estado de la cuenta |
| 48 | La solicitud de conexión no coincide con ninguna política configurada | Configuración incorrecta de la política RADIUS - comprobar las políticas de red de NPS |
| 66 | El usuario intentó utilizar un método de autenticación no habilitado en la política de red coincidente | Discrepancia del método EAP entre el cliente y el servidor |
Mitigación de riesgos: El desastre de la caducidad de certificados
La interrupción más común y evitable de 802.1X es la expiración del certificado del servidor RADIUS. En enero de 2025, una importante cadena minorista sufrió una interrupción completa de la red del personal cuando el certificado de su servidor RADIUS expiró a las 3:00 AM de un lunes. A las 9:00 AM, más de 300 terminales de punto de venta en 45 tiendas habían perdido la conectividad de red. El certificado se había implementado dos años antes sin supervisión automatizada, y el recordatorio de renovación se había omitido durante una reestructuración del equipo.
La mitigación es sencilla: implemente una supervisión automatizada de la expiración de certificados integrada con su plataforma de alertas (PagerDuty, OpsGenie o equivalente). Establezca umbrales de alerta a los 90, 60 y 30 días. Asigne la renovación de certificados como una responsabilidad nominal en su manual de procedimientos de operaciones de TI. Para plataformas RADIUS en la nube, verifique si el proveedor gestiona la renovación de certificados en su nombre - este es un diferenciador clave entre las ofertas gestionadas y las de autoservicio.
ROI e impacto empresarial
El coste del tiempo de inactividad de la autenticación
Para los operadores de recintos, los fallos de autenticación 802.1X se traducen directamente en un impacto empresarial medible. En entornos de Hostelería, una interrupción de la red del personal afecta a los sistemas de gestión de la propiedad, a los terminales de punto de venta y a la prestación de servicios a los huéspedes. En el sector Minorista, los fallos de autenticación de los terminales de punto de venta detienen por completo las transacciones. En centros de conferencias y estadios, los fallos de autenticación durante los eventos de mayor afluencia generan fallos de servicio inmediatos y visibles.
El coste operativo de una interrupción de la autenticación de 30 minutos en un hotel de 200 habitaciones - que afecte al acceso al sistema de gestión, al punto de venta del restaurante y a los terminales de conserjería - suele superar las 5.000 libras esterlinas en interrupción operativa directa, sin tener en cuenta el impacto en la experiencia del huésped y las posibles penalizaciones por incumplimiento de SLA.
Valor de cumplimiento
Para las organizaciones dentro del alcance de PCI-DSS v4.0, una infraestructura 802.1X correctamente desplegada satisface directamente múltiples requisitos: Requisito 1 (controles de acceso a la red), Requisito 7 (restringir el acceso a los componentes del sistema), Requisito 8 (identificar a los usuarios y autenticar el acceso) y Requisito 10 (registrar y supervisar todos los accesos). La alternativa - redes PSK compartidas - no cumple ninguno de los cuatro requisitos y genera una importante responsabilidad de auditoría.
Para las organizaciones del sector público y los despliegues de Asistencia sanitaria sujetos a normativas de protección de datos, la autenticación por usuario y los registros de contabilidad exhaustivos proporcionan la pista de auditoría necesaria para demostrar el cumplimiento de las obligaciones de control de acceso.
Medición del éxito
Los indicadores clave de rendimiento para un despliegue de 802.1X con un funcionamiento óptimo son: tasa de éxito de la autenticación (objetivo >99,5%), tiempo medio de autenticación (<150 ms para RADIUS en la nube), incidentes por expiración de certificados (objetivo cero) y disponibilidad del servidor RADIUS (objetivo 99,9%). Estas métricas deben seguirse en su plataforma de gestión de red y revisarse mensualmente como parte de su ritmo de operaciones de red. Para las organizaciones que utilizan WiFi Analytics, la combinación de datos de sesión por usuario de 802.1X con la analítica proporciona inteligencia empresarial adicional: medición precisa del tiempo de permanencia, distribución del tipo de dispositivo y patrones de utilización de la red que sirven de base para la planificación de la capacidad y las decisiones de operaciones del recinto.
Para seguir leyendo sobre soluciones de control de acceso a la red relacionadas, consulte 10 Best Network Access Control (NAC) Solutions for 2026 y Cisco Wireless APs: 2026 Guide to Products & Deployment. Para implementaciones en escuelas y educación, WiFi in Schools: The 2026 Administrator & IT Guide cubre la implementación de 802.1X en entornos educativos multiusuario.
Definiciones clave
802.1X
IEEE 802.1X es un estándar de control de acceso a redes basado en puertos que define un marco de autenticación que opera en la Capa 2 del modelo OSI. Bloquea todo el tráfico de red de un dispositivo hasta que el servidor RADIUS lo ha autenticado positivamente, utilizando EAP como protocolo de intercambio de credenciales. Se aplica tanto a redes Ethernet cableadas como a redes inalámbricas (WiFi).
Los equipos de TI se encuentran con 802.1X como mecanismo de autenticación para los SSID WPA2-Enterprise y WPA3-Enterprise. Es el estándar que permite la autenticación por usuario, la asignación dinámica de VLAN y la pista de auditoría necesaria para el cumplimiento de PCI-DSS.
RADIUS (Servicio de autenticación remota de usuarios de marcación telefónica)
Un protocolo de red cliente-servidor (RFC 2865) que proporciona una gestión centralizada de Autenticación, Autorización y Contabilización (AAA) para el acceso a la red. En despliegues de 802.1X, el servidor RADIUS valida las credenciales de usuario contra un directorio de identidades y devuelve respuestas Access-Accept o Access-Reject al Autenticador. Opera sobre los puertos UDP 1812 (autenticación) y 1813 (contabilización).
El servidor RADIUS es el componente de toma de decisiones en 802.1X. Cuando falla la autenticación, los registros del servidor RADIUS contienen el código de motivo que identifica la causa raíz. Las implementaciones comunes incluyen Microsoft NPS, FreeRADIUS y servicios alojados en la nube.
EAP (Protocolo de autenticación extensible)
Un marco de protocolo (RFC 3748) que define un conjunto de métodos de autenticación utilizados dentro de 802.1X. EAP en sí mismo no es un método de autenticación, sino un contenedor que admite múltiples métodos internos, incluidos EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS y EAP-FAST. El método EAP se negocia entre el Suplicante y el servidor RADIUS; el Autenticador retransmite las tramas EAP sin interpretarlas.
La selección del método EAP determina el estado de seguridad y la complejidad operativa del despliegue. EAP-TLS requiere una infraestructura de PKI y MDM pero proporciona la seguridad más sólida. PEAP-MSCHAPv2 es más sencillo de desplegar pero requiere una validación estricta de certificados para evitar la recolección de credenciales.
Suplicante
El componente de software en el dispositivo del usuario final (portátil, smartphone, terminal de punto de venta) que inicia el intercambio de autenticación 802.1X. En Windows, el suplicante está integrado en el sistema operativo como el servicio Configuración automática de WLAN o Configuración automática de red cableada. En iOS y Android, se gestiona a través de la configuración del perfil de WiFi del dispositivo.
La configuración incorrecta del suplicante, en particular la validación de certificados desactivada en despliegues PEAP, es una de las fuentes más comunes tanto de fallos de autenticación como de vulnerabilidades de seguridad. Estandarizar la configuración del suplicante a través de MDM es un control operativo crítico.
Autenticador
El dispositivo de red (punto de acceso inalámbrico o switch gestionado) que aplica el control de acceso basado en puertos en un despliegue de 802.1X. El Autenticador no toma decisiones de autenticación; actúa como un intermediario entre el Suplicante (usando EAPOL) y el servidor RADIUS (usando RADIUS). Bloquea todo el tráfico que no sea EAP en el puerto controlado hasta que el servidor RADIUS emita un Access-Accept.
La configuración del Autenticador, específicamente la IP o nombre de host del servidor RADIUS, el secreto compartido y los ajustes de tiempo de espera, es una fuente común de fallos. Tras realizar cambios en la infraestructura, verifique siempre que la configuración del cliente RADIUS del Autenticador coincida con la configuración del cliente NAS del servidor RADIUS.
EAPOL (EAP sobre LAN)
El protocolo utilizado para transportar tramas EAP entre el Suplicante y el Autenticador a través de un medio cableado o inalámbrico. Las tramas EAPOL son tramas de Capa 2 (tipo Ethernet 0x888E) y no requieren conectividad IP. El Autenticador encapsula las tramas EAPOL en paquetes RADIUS para su reenvío al Servidor de Autenticación.
EAPOL es visible en las capturas de Wireshark en el lado del cliente. Filtrar por tramas EAPOL en una captura de paquetes inalámbricos permite a los ingenieros observar el intercambio EAP e identificar en qué paso falla la autenticación.
RadSec (RADIUS sobre TLS)
Una extensión del protocolo RADIUS (RFC 6614) que encapsula paquetes RADIUS en un túnel TLS a través del puerto TCP 2083. RadSec proporciona seguridad de transporte para el tráfico RADIUS que atraviesa redes no confiables (como internet público hacia un servidor RADIUS en la nube), elimina los problemas de fragmentación UDP y suprime la dependencia de secretos compartidos para la autenticación de paquetes.
RadSec es el transporte recomendado para despliegues de RADIUS en la nube. Resuelve simultáneamente dos modos de fallo comunes: la fragmentación de MTU que causa fallos en el saludo EAP-TLS y la complejidad de la gestión de secretos compartidos en sitios distribuidos.
Asignación dinámica de VLAN
Una función de autorización de RADIUS que permite al servidor RADIUS ordenar al autenticador que coloque un dispositivo autenticado en una VLAN específica, según la pertenencia a un grupo del usuario o el tipo de dispositivo. El servidor RADIUS devuelve los atributos de asignación de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) en la respuesta Access-Accept.
La asignación dinámica de VLAN es el mecanismo que impone la segmentación de red en despliegues 802.1X. Es un control obligatorio para el cumplimiento de PCI-DSS (aislando el Entorno de Datos de Tarjetas de Pago) y una piedra angular de la arquitectura de red Zero Trust. Los atributos de VLAN mal configurados en las políticas de RADIUS son una causa común de que los usuarios terminen en el segmento de red incorrecto después de la autenticación.
Bypass de autenticación MAC (MAB)
Un mecanismo de autenticación de respaldo que permite a los dispositivos sin suplicantes 802.1X autenticarse utilizando su dirección MAC tanto como nombre de usuario como contraseña en un intercambio RADIUS. Debido a que las direcciones MAC se pueden suplantar, MAB proporciona una garantía de seguridad mínima y solo debe utilizarse para dispositivos que realmente no puedan admitir 802.1X.
MAB se requiere habitualmente para dispositivos IoT heredados, terminales de punto de venta antiguos e impresoras de red. Los dispositivos autenticados a través de MAB deben colocarse en una VLAN muy restringida con reglas de firewall explícitas. Nunca utilice MAB como un atajo de conveniencia para dispositivos que podrían admitir 802.1X.
NPS (Servidor de políticas de red)
La implementación de Microsoft de un servidor RADIUS, incluida con Windows Server. NPS admite PEAP-MSCHAPv2, EAP-TLS y EAP-TTLS, y se integra de forma nativa con Active Directory para la validación de credenciales. Los fallos de autenticación se registran en el registro de eventos de seguridad de Windows como Event ID 6273 (fallo) y 6272 (éxito), con códigos de motivo que identifican la causa específica del fallo.
NPS es el servidor RADIUS más implementado en entornos empresariales centrados en Windows. El registro de eventos de seguridad en el servidor NPS es la herramienta de diagnóstico principal para fallos de 802.1X en estos entornos. Asegúrese de que la política de auditoría de NPS esté habilitada tanto para eventos de éxito como de fallo.
Ejemplos prácticos
Un grupo hotelero de 450 habitaciones con 12 establecimientos ha implantado WPA2-Enterprise con PEAP-MSCHAPv2 en todos sus centros, utilizando un servidor local Windows NPS en cada ubicación. Tras una renovación de la infraestructura de red, el equipo de TI informa de que el personal de tres centros no puede autenticarse en el SSID corporativo. Los huéspedes de la red con Captive Portal no se ven afectados. Los servidores NPS de los centros afectados están en funcionamiento y el registro de eventos de seguridad de Windows muestra el ID de evento 6273 con el código de motivo 16. ¿Cuál es la causa más probable y cómo debe resolverla el equipo?
El código de motivo 16 en el ID de evento 6273 de NPS indica un fallo de autenticación debido a una discordancia de credenciales - pero en el contexto de una interrupción tras una renovación de infraestructura que afecta a varios centros simultáneamente, la causa más probable no es que las contraseñas de usuario sean incorrectas, sino una discordancia de la clave secreta compartida de RADIUS entre los puntos de acceso o el controlador inalámbrico recién configurados y los servidores NPS.
Paso 1: En el servidor NPS de uno de los centros afectados, acceda a Clientes y servidores RADIUS > Clientes RADIUS y verifique la clave secreta compartida configurada para cada dirección IP de AP o controlador inalámbrico. Compárela con la configuración del servidor RADIUS en el AP o controlador.
Paso 2: Si las claves secretas compartidas coinciden, compruebe si la política de red de NPS está configurada correctamente para permitir PEAP-MSCHAPv2. Acceda a Directivas > Directivas de red, abra la directiva correspondiente y verifique que Microsoft: EAP protegido (PEAP) aparece como método de autenticación permitido con EAP-MSCHAPv2 como método interno.
Paso 3: Si la directiva es correcta, compruebe la directiva de solicitud de conexión de NPS para confirmar que la solicitud se está procesando localmente (no se reenvía a un servidor RADIUS remoto). Verifique que las condiciones coinciden con los atributos RADIUS entrantes del nuevo hardware de AP.
Paso 4: Habilite la depuración de contabilidad de RADIUS en el AP o controlador y verifique que los paquetes Access-Request se envían a la IP y al puerto 1812 correctos del servidor NPS. Si no llega ninguna solicitud al servidor NPS, el problema está en la configuración del autenticador, no en el servidor RADIUS.
Paso 5: Si las solicitudes llegan a NPS pero se rechazan con el código de motivo 16, y se confirma que las credenciales son correctas, compruebe si el controlador de dominio de Active Directory es accesible desde el servidor NPS. Un problema de DNS o de conectividad con el DC provocará que NPS falle en la validación de credenciales con este código de motivo.
Resolución: En la mayoría de los escenarios posteriores a una renovación, la causa principal es una discordancia en la clave secreta compartida introducida al configurar el nuevo hardware de AP. Sincronice la clave secreta compartida en todos los clientes RADIUS y servidores NPS. Considere la posibilidad de migrar a RadSec para eliminar por completo la gestión de claves secretas compartidas.
Una importante cadena minorista que opera 85 tiendas ha implementado EAP-TLS con certificados de cliente gestionados a través de Microsoft Intune. Un lunes por la mañana, el servicio de soporte de TI recibe una oleada de informes de los gerentes de las tiendas que indican que los dispositivos del personal no pueden conectarse a la red WiFi corporativa. El problema afecta a todas las tiendas simultáneamente. Los registros del servidor RADIUS muestran respuestas Access-Reject con el mensaje 'TLS Alert: certificate expired'. El propio servidor RADIUS funciona con normalidad y su propio certificado es válido durante otros 18 meses. ¿Qué ha ocurrido y cuál es la vía de solución inmediata?
El mensaje 'TLS Alert: certificate expired' en los registros del servidor RADIUS, combinado con el hecho de que el fallo es simultáneo en las 85 tiendas y que el certificado del servidor RADIUS es válido, indica que los certificados de cliente implementados en los dispositivos del personal han caducado. En EAP-TLS, tanto el cliente como el servidor presentan certificados. Si el certificado de cliente ha caducado, el servidor RADIUS rechazará el saludo TLS y emitirá un Access-Reject.
Solución inmediata (0 - 2 horas):
Paso 1: Confirme el diagnóstico comprobando la fecha de caducidad del certificado en un dispositivo afectado. En Windows, abra certmgr.msc, vaya a Personal > Certificados y compruebe la fecha de caducidad del certificado de autenticación de WiFi. Si ha caducado, esto confirma la causa raíz.
Paso 2: En Microsoft Intune, vaya a Dispositivos > Perfiles de configuración y busque el perfil de certificado SCEP o PKCS utilizado para la autenticación WiFi. Compruebe el periodo de validez del certificado y los ajustes del umbral de renovación.
Paso 3: Si el perfil de certificado está configurado para renovarse automáticamente, compruebe si los dispositivos han podido conectarse al servicio de gestión de Intune recientemente. Si los dispositivos estaban desconectados o no registrados, es posible que no se haya producido la renovación automática.
Paso 4: Fuerce la renovación de un certificado activando una sincronización de dispositivos en Intune (Dispositivos > Todos los dispositivos > Sincronizar). Para los dispositivos que no puedan conectarse a la WiFi, asegúrese de que dispongan de una vía de conectividad alternativa (datos móviles o Ethernet por cable) para acceder al servicio de Intune para la renovación.
Paso 5: Como medida temporal mientras se renuevan los certificados, considere la posibilidad de crear un SSID PEAP-MSCHAPv2 temporal para las tiendas afectadas con el fin de restaurar la capacidad operativa. Esto debe considerarse como un puente temporal, no como una solución permanente.
Prevención a largo plazo:
Configure los perfiles de certificado de Intune para que se renueven cuando quede el 20% de la vida útil del certificado (por ejemplo, para un certificado de 1 año, renovar aproximadamente 73 días antes de la caducidad). Implemente alertas SIEM en eventos RADIUS Access-Reject con códigos de motivo de caducidad de certificado. Añada la supervisión de la caducidad de los certificados a su revisión mensual de operaciones de TI.
Preguntas de práctica
Q1. Su organización opera un estadio de 60.000 asientos con 800 puntos de acceso desplegados en vestíbulos, suites de hospitalidad y áreas de servicio internas. Los dispositivos del personal utilizan EAP-TLS con certificados gestionados a través de Jamf. Durante un evento importante, el 15% de los dispositivos del personal en múltiples zonas reportan fallos de autenticación. Los registros del servidor RADIUS muestran respuestas Access-Reject. El 85% restante del personal se está autenticando con normalidad. ¿Cuál es su enfoque de diagnóstico y cuál es la causa raíz más probable?
Sugerencia: El patrón de fallo parcial (15% de los dispositivos, no todos) es la señal de diagnóstico clave. Concéntrese en lo que distingue a los dispositivos que fallan de los que tienen éxito: modelo de dispositivo, versión de sistema operativo, fecha de emisión del certificado o estado de inscripción en Jamf.
Ver respuesta modelo
El patrón de fallo parcial descarta de inmediato causas a nivel de infraestructura (la expiración del certificado del servidor RADIUS, un desajuste en el secreto compartido o una caída del servidor afectarían a todos los dispositivos). Casi con total seguridad, la causa principal es un subconjunto de certificados de cliente que han expirado o no se han renovado.
Enfoque de diagnóstico: Extraiga los logs del servidor RADIUS y filtre por eventos Access-Reject. Identifique los dispositivos afectados (CN de los certificados o direcciones MAC). En Jamf, realice una referencia cruzada de estos dispositivos con el estado de despliegue del perfil de certificado. Compruebe si los dispositivos que fallan comparten una fecha común de emisión de certificados - si todos se registraron en el mismo lote, es posible que tengan la misma fecha de expiración.
Causa principal más probable: Un lote de certificados de cliente emitidos al mismo tiempo ha llegado a su fecha de expiración. Los dispositivos registrados más recientemente tienen certificados válidos y se están autenticando con normalidad.
Resolución: En Jamf, identifique los dispositivos afectados y fuerce una actualización del certificado. Asegúrese de que el perfil del certificado esté configurado con un umbral de renovación adecuado (20% de la vida útil del certificado). Para los dispositivos que no puedan conectarse al servicio Jamf MDM a través de WiFi (porque no pueden autenticarse), proporcione una conexión por cable Ethernet temporal o un SSID PEAP temporal mientras dure la incidencia. Tras la resolución, implemente alertas SIEM sobre los eventos RADIUS Access-Reject con códigos de motivo de expiración de certificados para evitar que vuelva a ocurrir.
Q2. Una cadena minorista regional con 35 tiendas está migrando de servidores NPS locales a un servicio RADIUS en la nube. Durante la fase piloto en tres tiendas, la autenticación EAP-TLS funciona correctamente en dos de ellas, pero falla de forma intermitente en la tercera. La tercera tienda se conecta al servicio RADIUS en la nube a través de un enlace WAN MPLS. Los fallos de autenticación no son constantes: algunos intentos tienen éxito y otros fallan. El proveedor de RADIUS en la nube confirma que el servicio funciona correctamente y los logs muestran que llegan algunos paquetes Access-Request, pero no se envía el correspondiente Access-Accept. ¿Cuál es la causa más probable?
Sugerencia: Los fallos intermitentes en un sitio específico conectado por WAN, combinados con el hecho de que el proveedor de RADIUS en la nube reciba algunos paquetes pero no todos, sugieren claramente un problema de tránsito de red en lugar de un error de configuración.
Ver respuesta modelo
La combinación de fallos intermitentes en un sitio conectado por WAN y el hecho de que el proveedor de RADIUS en la nube detecte secuencias de paquetes incompletas es un síntoma clásico de fragmentación MTU. Las cadenas de certificados EAP-TLS generan paquetes RADIUS de gran tamaño que pueden superar la MTU del enlace WAN MPLS. Cuando estos paquetes se fragmentan, es posible que el servidor RADIUS en la nube reciba el primer fragmento pero no los siguientes, lo que hace que el proceso de negociación TLS se detenga y, finalmente, expire por tiempo límite.
Confirmación del diagnóstico: Realice una captura con Wireshark en la interfaz WAN de la tienda afectada. Filtre el tráfico UDP en el puerto 1812. Busque paquetes IP fragmentados en el intercambio RADIUS. Compare el tamaño de los paquetes en las tiendas donde la conexión es correcta frente a la tienda donde falla.
Opción de resolución 1 (preferida): Migre el sitio afectado a RadSec (RADIUS sobre TLS en el puerto TCP 2083). TCP gestiona la fragmentación y la retransmisión de forma nativa, lo que elimina por completo este modo de fallo. La mayoría de los proveedores de RADIUS en la nube y los fabricantes de AP modernos son compatibles con RadSec.
Opción de resolución 2: Reduzca la MTU en la interfaz WAN de la tienda afectada para que coincida con la MTU de la ruta MPLS, garantizando así que los paquetes RADIUS no se fragmenten. Esta solución es menos óptima, ya que afecta a todo el tráfico del enlace WAN.
Opción de resolución 3: Configure el servidor RADIUS para que utilice tamaños de registro TLS más pequeños con el fin de reducir la fragmentación de los paquetes. Esta es una opción de configuración en el lado del servidor disponible en algunas implementaciones de RADIUS.
Recomendación a largo plazo: Migre todos los sitios a RadSec como parte del despliegue de RADIUS en la nube. Esto elimina el riesgo de fragmentación, cifra el tráfico RADIUS en tránsito y suprime la complejidad de la gestión de secretos compartidos.
Q3. El director de TI de un centro de conferencias está planificando una actualización de la red para soportar WPA3-Enterprise con 802.1X para el personal y un Captive Portal para los delegados de los eventos. El recinto alberga más de 200 eventos al año, con una asistencia de delegados que varía entre 50 y 5.000 personas. El equipo de TI tiene una experiencia interna limitada en redes y carece de infraestructura PKI. El director desea implementar 802.1X para el personal, pero le preocupa la complejidad operativa. ¿Qué método EAP se debería recomendar, qué infraestructura se requiere y cuáles son los principales riesgos operativos que se deben mitigar?
Sugerencia: Considere las limitaciones operativas: personal interno con experiencia limitada, ausencia de PKI actual y la necesidad de una solución que se pueda mantener de manera fiable. Equilibre los requisitos de seguridad con la viabilidad operativa.
Ver respuesta modelo
Dadas las limitaciones operativas - experiencia interna limitada y sin PKI existente -, el método EAP recomendado para la autenticación del personal es PEAP-MSCHAPv2, no EAP-TLS. Aunque EAP-TLS proporciona una seguridad superior, requiere una infraestructura PKI y una plataforma MDM para la distribución de certificados. Sin estos elementos, el despliegue de EAP-TLS conlleva un riesgo operativo significativo: la gestión de la expiración de certificados se convierte en un proceso manual y el equipo carece de la experiencia para solucionar problemas de la cadena de certificados bajo presión.
PEAP-MSCHAPv2 se integra directamente con Active Directory (o Azure AD), solo requiere un certificado en el lado del servidor y es gestionable operativamente por un equipo sin conocimientos profundos de PKI. El compromiso de seguridad es aceptable siempre que se exija estrictamente la validación del certificado del servidor en todos los dispositivos cliente - este es el control no negociable que evita el robo de credenciales a través de puntos de acceso no autorizados.
Infraestructura requerida: Un servicio RADIUS en la nube (para evitar la gestión de servidores locales), un certificado de servidor de una CA pública de confianza para el servicio RADIUS, una solución MDM (Microsoft Intune o equivalente) para desplegar perfiles WiFi en los dispositivos del personal, y Active Directory o Azure AD como directorio de identidades.
Riesgos operativos clave a mitigar:
Validación de certificados desactivada en los clientes: Despliegue todos los perfiles WiFi a través de MDM con la validación de certificados activada de forma obligatoria. No permita nunca la configuración manual de perfiles WiFi en los dispositivos del personal.
Expiración del certificado del servidor RADIUS: Configure una supervisión automatizada con alertas a los 90 días. Con un servicio RADIUS en la nube, verifique si el proveedor gestiona la renovación del certificado - este es un criterio de selección clave.
Capacidad durante grandes eventos: Asegúrese de que el servicio RADIUS en la nube esté dimensionado para la carga máxima de autenticaciones simultáneas. Durante un evento de 5.000 delegados, si los dispositivos del personal se autentican de nuevo simultáneamente (por ejemplo, tras un reinicio de la red), el servicio RADIUS debe ser capaz de absorber el pico de demanda.
Segmentación de red de invitados y personal: Asegúrese de que la red de invitados del Captive Portal y la red del personal con 802.1X estén en VLAN distintas con las reglas de firewall adecuadas entre ellas. Este es un requisito de PCI-DSS si algún dispositivo de la red del personal procesa datos de tarjetas de pago.
Continúe leyendo esta serie
Cómo revocar el acceso WiFi cuando un empleado se va
Esta guía muestra a los equipos de TI y operaciones cómo eliminar el acceso a Staff WiFi cuando un empleado se marcha sin interrumpir al resto del personal. Compara el aprovisionamiento mediante 802.1X basado en certificados, iPSK específicos de identidad y la desprogramación basada en SCIM, para luego ofrecer un manual del mismo día, un método de prueba y un modelo de auditoría.
Planificación de un despliegue de WiFi 7 en un entorno clínico: dispositivos IoMT, interferencias e HIPAA
Esta guía exhaustiva explora la planificación de un despliegue de WiFi 7 en un entorno clínico, centrándose en la estrategia de la banda de 6 GHz, la compatibilidad con dispositivos IoMT heredados, las obligaciones de interferencia de RF según la norma IEC 60601-1-2 y la segmentación de red adaptada a HIPAA. Proporciona consejos prácticos de arquitectura para que los responsables de TI del sector sanitario protejan flotas de dispositivos mixtas mediante la plataforma RADIUS en la nube de Purple.
Cómo segmentar de forma segura las redes WiFi de empleados y de invitados: mejores prácticas para LAN empresariales
Esta guía proporciona a los directores de TI y arquitectos de red un modelo técnico e independiente del proveedor para proteger las LAN empresariales mediante la segmentación correcta del tráfico de las redes WiFi de empleados e invitados. Abarca la autenticación 802.1X, RADIUS en la nube, el aislamiento de VLAN y la gestión del ciclo de vida de las credenciales necesaria para eliminar las contraseñas compartidas y proteger los activos corporativos.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.