Autenticación WiFi basada en certificados: Guía de EAP-TLS
Published
Alguien deja la empresa y su equipo está decidiendo si debe cambiar de nuevo la contraseña de la WiFi para empleados WiFi. Cambiarla implica volver a conectar portátiles, teléfonos, tabletas de recepción y equipos que nadie recuerda haber configurado. Dejarla tal como está significa aceptar que alguien ajeno a la organización sigue sabiendo cómo conectarse.
La autenticación WiFi basada en certificados le ofrece una mejor manera de identificar dispositivos de confianza. Pero también cambia el trabajo que debe realizar su equipo: en lugar de distribuir contraseñas, gestionará cadenas de confianza, renovación y revocación de certificados, y dispositivos que desaparecen en el almacén durante meses. La mejora de la seguridad es real. Un funcionamiento fiable requiere algo más que seleccionar EAP-TLS en un perfil inalámbrico.
Índice de contenidos
- Qué significa la autenticación basada en certificadosWiFi
- Cómo funciona el intercambio de saludos EAP-TLS paso a paso
- Comparativa de certificados con contraseñas compartidas y PEAP
- Creación de la CA y aprovisionamiento de certificados mediante MDM
- Gestión del ciclo de vida de los certificados: de la emisión a la renovación
- Revocación del acceso por pérdida de dispositivos o bajas de personal
- Elegibilidad de dispositivos y planificación de excepciones
- Confirme su plan de certificados antes del despliegue
Qué significa la autenticación WiFi basada en certificados
La autenticación WiFi basada en certificados sustituye una contraseña WiFi compartida por un certificado digital individual, que la red comprueba antes de conceder el acceso. Piense en el código de acceso compartido a la puerta de una oficina frente a una tarjeta de empleado. Con el código, todo el mundo demuestra que conoce el mismo secreto. Con la tarjeta, el puesto de seguridad puede identificar una credencial concreta y cancelarla de forma independiente.
Supongamos que un portátil gestionado necesita acceso a la red del personal. Su certificado identifica el dispositivo o el usuario asignado, y su clave privada protegida le permite demostrar que posee dicha credencial. El certificado en sí no es una contraseña secreta, y la mera copia del certificado público no proporciona la clave privada correspondiente.
El diagrama muestra cómo las credenciales individuales sustituyen a la contraseña común.
Dónde encaja cada componente
El marco subyacente es IEEE 802.1X, desarrollado originalmente para Ethernet por cable y adaptado para LAN inalámbricas. La descripción general de Microsoft sobre la autenticación IEEE 802.1X describe el marco y la función de la autenticación centralizada a través de RADIUS.
El punto de acceso controla la admisión, mientras que el servicio de RADIUS evalúa la solicitud de autenticación. EAP-TLS es el método de autenticación basado en certificados que se lleva a cabo mediante esa disposición. El dispositivo y el servidor de autenticación se validan mutuamente antes de establecer el material clave para la conexión.
Mantenga estos componentes diferenciados:
- Certificado de dispositivo: Identifica el extremo o usuario y funciona con una clave privada conservada por el dispositivo.
- Certificado de servidor de autenticación: Permite al dispositivo verificar que se está comunicando con un servicio de autenticación aprobado.
- Autoridad de certificación: Emite certificados que cada parte puede validar a través de una cadena de certificados explícitamente de confianza.
El dispositivo y el servidor no necesitan necesariamente certificados de la misma autoridad emisora. Lo importante es que cada parte confíe en el emisor adecuado y aplique la directiva de validación correcta.
Regla práctica: Trate los certificados como un sistema de identidad de red, no como contraseñas complicadas.
Esta distinción cambia la forma de gestionar la pérdida de un portátil. Puede revocar sus credenciales sin tener que sustituir las del equipo de todos los demás. Sin embargo, la posesión de un certificado válido establece la identidad, no un permiso ilimitado. Su directiva de acceso debe seguir determinando a qué puede acceder dicha identidad.
Cómo funciona la negociación EAP-TLS paso a paso
Una conexión involucra al suplicante del dispositivo, al punto de acceso que actúa como autenticador y al servidor de autenticación. El suplicante es el componente del sistema operativo que gestiona la autenticación en la red empresarial.
Este flujo simplificado muestra las transferencias principales, en lugar de cada mensaje de protocolo.
Siga el intercambio y sus puntos de fallo
La autenticación mutua y la derivación de claves que subyacen a este intercambio se definen en la especificación EAP-TLS, RFC 5216.
El dispositivo se asocia con el punto de acceso. Comienza el intercambio de autenticación empresarial y proporciona una identidad. La asociación por sí sola no otorga acceso normal a la red. Una configuración de seguridad inalámbrica incorrecta puede impedir por completo que el dispositivo alcance la autenticación por certificado.
El punto de acceso retransmite los mensajes EAP a RADIUS. Transfiere el intercambio entre el extremo y el servicio de autenticación en lugar de emitir el certificado de dispositivo por sí mismo. Un problema de conectividad con RADIUS o un punto de acceso registrado de forma incorrecta pueden detener el intercambio en este punto.
El servidor presenta su certificado. El dispositivo comprueba la cadena de certificados, la validez y la identidad del servidor prevista. Un emisor no fidedigno, una cadena incompleta o un nombre de servidor inesperado deberían hacer que el dispositivo rechace la conexión.
El dispositivo presenta su certificado de cliente. El servidor valida la credencial, comprueba la información de revocación aplicable y evalúa la identidad. La falta de un certificado o la inaccesibilidad de una clave privada pueden parecer un fallo de conexión genérico para el usuario, incluso cuando los registros del servidor muestran una causa específica.
El intercambio TLS establece el material de clave compartido. El extremo debe demostrar la posesión de su clave privada, no limitarse a presentar un archivo de certificado. Una configuración criptográfica incompatible puede impedir la finalización incluso cuando ambos certificados son válidos por lo demás.
RADIUS devuelve el resultado de la autenticación y los atributos de directiva. Una aceptación puede incluir una asignación de VLAN u otros atributos de autorización compatibles. Una autenticación correcta seguida de una conexión no utilizable puede indicar un problema de VLAN o de directiva descendente, en lugar de un problema de certificado.
Configure el cliente para verificar el servidor
En el perfil del suplicante, seleccione explícitamente EAP-TLS, configure la CA de confianza y especifique los nombres de servidor de RADIUS esperados. Mantenga habilitada la validación del certificado del servidor. No permita que los usuarios omitan una advertencia solo para conectarse.
Utilice este vídeo junto con el flujo del protocolo cuando analice el intercambio con su equipo.
Cada conexión depende de que las credenciales estén presentes, accesibles y sean aceptables en el momento de la autenticación. Por tanto, la resolución de problemas requiere pruebas tanto del suplicante como del RADIUS, y no solo un panel del punto de acceso que muestre que un cliente no se ha podido conectar.
Comparativa entre certificados, contraseñas compartidas y PEAP
WiFi métodos de autenticación según los mismos criterios
| Método | Credencial en el dispositivo | Alcance de revocación | Rendición de cuentas | Esfuerzo de configuración |
|---|---|---|---|---|
| Frase de paso compartida WPA2 o WPA3-Personal | Una frase de paso conocida por todos los usuarios | Cambia la clave para todo el mundo | Ninguna a partir de la propia credencial compartida | Bajo |
| WPA2-Enterprise con PEAP-MSCHAPv2 | Nombre de usuario y contraseña por usuario | Deshabilita una cuenta | Por usuario | Medio |
| EAP-TLS en WPA2 o WPA3-Enterprise | Certificado de cliente y clave privada exclusivos por dispositivo | Revoca un certificado | Por dispositivo y usuario cuando está asignado | Alto, requiere PKI y aprovisionamiento gestionado |
| WPA3-Enterprise de 192 bits con EAP-TLS | Certificado que cumple los requisitos criptográficos del perfil | Revoca un certificado | Por dispositivo y usuario cuando está asignado | Alto, además de comprobaciones de compatibilidad de cifrado |
EAP-TLS no es sinónimo de WPA3. El registro de certificación de Wi-Fi Alliance identifica EAP-TLS entre los métodos de autenticación empresarial admitidos. La autenticación mediante certificado es una opción de autenticación empresarial, mientras que el perfil WPA también determina los requisitos de seguridad inalámbrica.
Compare las credenciales, no solo la etiqueta
Una frase de paso compartida demuestra el conocimiento de un secreto común. No establece qué empleado la proporcionó, aunque los equipos de red aún pueden registrar los detalles de la conexión. Las salidas del personal resultan complicadas porque sustituir la credencial implica actualizar cada dispositivo que la utiliza.
PEAP-MSCHAPv2 pasa a utilizar nombres de usuario y contraseñas individuales. Utiliza un túnel TLS autenticado por servidor para proteger el intercambio de autenticación interno, por lo que la validación adecuada del servidor sigue siendo importante. Puede proporcionar registros individuales de usuario muy útiles, pero los cambios de contraseña y los problemas de cuenta siguen formando parte del soporte de la red inalámbrica.
Con EAP-TLS, el punto final utiliza su certificado y clave privada en lugar de una contraseña de cuenta durante la autenticación. Esto proporciona a los administradores una credencial específica del dispositivo para gestionar, siempre que el inventario asocie correctamente los certificados con los puntos finales y sus propietarios.
Elija el método cuyo ciclo de vida de credenciales pueda operar realmente su equipo, no simplemente la etiqueta más sólida del menú del controlador.
Adapte el método a la población
Las frases de paso compartidas son una mala opción por defecto para el acceso gestionado del personal cuando la retirada individual y la responsabilidad son importantes. Incluso para invitados y equipos de bajo riesgo, una contraseña común requiere una directiva deliberada de distribución y sustitución.
Los certificados son adecuados para portátiles y teléfonos gestionados porque se pueden aprovisionar mediante un sistema de gestión existente. El perfil de empresa de mayor garantía añade trabajo de compatibilidad; no elimina ninguna responsabilidad del ciclo de vida. PEAP puede seguir siendo una opción de migración cuando existan cuentas individuales pero el aprovisionamiento de certificados no esté listo, en lugar de una razón para posponer indefinidamente un diseño de acceso basado en la identidad.
Creación de la CA y aprovisionamiento de certificados a través de MDM
Un despliegue gestionable comienza con una infraestructura de clave pública (PKI) cuya titularidad esté clara. Una jerarquía habitual mantiene una autoridad de certificación raíz fuera de línea y utiliza una CA emisora para la emisión habitual de certificados. Un servicio PKI gestionado puede cumplir estas funciones sin necesidad de que su equipo opere cada componente de forma local.
La CA emisora firma los certificados de dispositivo y de servidor. RADIUS debe confiar en la cadena de certificados de cliente, mientras que los extremos deben confiar en la cadena de servidor adecuada. No asuma que instalar un certificado raíz configura automáticamente el resto de la política inalámbrica.
Elija los perfiles antes de emitir certificados
Una plantilla de dispositivo requiere uso para autenticación de cliente, una identidad de dispositivo o usuario que su directiva pueda resolver, y un periodo de validez regido por su diseño de renovación y recuperación.
Perfiles de certificados por nivel de seguridad
| Perfil | Clave y algoritmo | Validez típica | Dónde se adapta |
|---|---|---|---|
| Ordenador portátil o teléfono gestionado estándar | Algoritmo aprobado por la organización y compatible con toda la flota | Establecida por la directiva de renovación y recuperación | Flotas mixtas en WPA2-Enterprise |
| Dispositivo gestionado más estricto | Plantilla más sólida aprobada tras las pruebas del punto de conexión | Establecida por la directiva y la capacidad de renovación | Flotas modernas con firmware actualizado |
| WPA3-Enterprise de 192 bits | ECDSA P-384 o RSA 3072 o superior | Establecida por la directiva y la capacidad de renovación | Sitios de mayor garantía tras pruebas de compatibilidad |
| Dispositivo sin interfaz o heredado | A menudo no compatible | Ciclo de vida admitido por el proveedor o caducidad por excepción | Ruta de excepción |
La guía de despliegue de Wi-Fi Alliance especifica que el modo WPA3-Enterprise de 192 bits restringe la autenticación a EAP-TLS y utiliza suites AES-256-GCM con parámetros de curva elíptica P-384 o tamaños de módulo RSA/DH de al menos 3072 bits. Por lo tanto, el perfil de mayor garantía de la tabla se debe verificar con la suite seleccionada completa, no solo con la etiqueta de la clave del certificado.
Las plantillas de certificados, el software RADIUS, los suplicantes y los proveedores criptográficos deben coincidir. Un punto de extremo que admita EAP-TLS ordinario aún puede fallar bajo este perfil más estricto.
Proporcione confianza, credenciales y configuración de forma conjunta
Con SCEP, el perfil de gestión indica al dispositivo que genere un par de claves y solicite un certificado. La CA firma la solicitud; el dispositivo conserva su clave privada en un almacenamiento protegido. No distribuya el mismo certificado de cliente y la misma clave privada a varios equipos.
Despliegue las dependencias en un orden controlado:
- Primero, la confianza: instale los certificados de CA de confianza requeridos.
- A continuación, las credenciales: entregue la configuración SCEP y confirme que se ha emitido correctamente.
- Por último, el perfil inalámbrico: haga referencia a las credenciales del cliente previstas y a los ajustes de validación del servidor.
Mantenga una segmentación de grupos coherente en todos los perfiles dependientes. Utilice la comparación de perfiles de certificados MDMWiFi para revisar las diferencias entre plataformas antes de estandarizar el despliegue. Proporcione también una conexión de inscripción que no dependa del certificado que el dispositivo aún está intentando obtener.
Gestión del ciclo de vida del certificado, desde la emisión hasta la renovación
Un ordenador portátil que se conecta correctamente hoy puede fallar tras permanecer en un armario durante su periodo de renovación. El punto de acceso puede estar en perfecto estado, la contraseña no ha cambiado y el usuario no ha cometido ningún error. El problema es que el punto final ya no dispone de una credencial aceptable.
La guía sobre los requisitos de EAP del NIST describe la necesidad de aprovisionar certificados antes de la autenticación, los cuales deben estar disponibles durante el intercambio y ser verificables, incluido el estado de revocación. Estos requisitos hacen que las dependencias del ciclo de vida formen parte de la disponibilidad de la red.
Esta cronología resulta útil para asignar la responsabilidad más allá del despliegue inicial.
Asigne un control operativo a cada etapa
| Fase | Control | Fallo que previene |
|---|---|---|
| Inscripción | Supervisar el registro en MDM y la asignación de perfiles | El dispositivo nunca recibe una instrucción de inscripción |
| Emisión | Validar los permisos de las plantillas y los resultados de las solicitudes | La CA rechaza las solicitudes o emite certificados no utilizables |
| Despliegue | Verificar la instalación y el acceso protegido a la clave privada | El certificado existe pero el suplicante no puede utilizarlo |
| Renovación | Iniciar con antelación, supervisar la finalización y permitir un solapamiento comprobado | Los dispositivos alcanzan la caducidad sin un sustituto |
| Caducidad | Alertar a los propietarios y proporcionar una ruta de recuperación restringida | Los dispositivos caducados no tienen forma de recuperarse |
| Retirada | Retirar las credenciales y eliminar las entradas obsoletas del inventario | El equipo retirado conserva una identidad aceptada |
La renovación requiere una prueba de finalización, no basta con tener habilitada una configuración de automatización. Realice un seguimiento para comprobar si se ha emitido, instalado y utilizado correctamente un certificado de sustitución. Durante el periodo de solapamiento, confirme que el suplicante selecciona la credencial adecuada en lugar de elegir repetidamente una obsoleta.
Planifique para dispositivos que no están en línea
Establezca la ventana de renovación en función del comportamiento real del dispositivo. Los equipos utilizados de forma estacional o guardados como repuesto pueden requerir un proceso de recuperación diferente al de un portátil que se conecta a diario. No asuma que un extremo fuera de línea puede renovar porque su certificado antiguo siga figurando en el MDM.
Mantenga un inventario que vincule el número de serie del certificado, el identificador del punto final, el propietario, el emisor, la fecha de caducidad y el estado de renovación. Incluya la CA emisora y los certificados del servidor de autenticación, ya que su sustitución puede afectar a un grupo mucho más amplio.
Un trabajo de renovación que se ha ejecutado correctamente no es lo mismo que un dispositivo que pueda autenticarse con su certificado de sustitución.
Pruebe errores de reloj, reinstalaciones del sistema operativo y cambios en la cadena de CA. Una reinstalación puede eliminar la clave privada; un error de reloj puede hacer que un certificado válido parezca aún no válido; un cambio en la cadena puede dejar a los puntos de extremo sin la confianza requerida.
Asigne responsables con nombres y apellidos a los fallos en los que intervengan servicios MDM, PKI y de red. De lo contrario, cada equipo puede informar de que su propio sistema funciona correctamente mientras el punto final sigue desconectado. EAP-TLS convierte el riesgo de interrupción en un problema de inventario, automatización y gestión de dependencias. No elimina dicho riesgo.
Revocación del acceso cuando se pierden dispositivos o hay bajas de personal
La cuenta de directorio de un empleado que abandona la empresa se deshabilita, pero su portátil aún conserva un certificado que no ha caducado. La posibilidad de que vuelva a conectarse depende de la integración de la autorización y de los controles de revocación. Deshabilitar una cuenta y revocar un certificado son acciones distintas, a menos que el flujo de trabajo configurado las conecte de forma explícita.
Defina el resultado de la baja en términos operativos: las nuevas autenticaciones deben fallar, la inscripción no debe emitir credenciales de sustitución y las sesiones existentes deben finalizar a través de un mecanismo compatible. Un ticket de RR. HH. resuelto no demuestra ninguno de esos resultados.
Comprenda las comprobaciones de estado
Una lista de revocación de certificados, o CRL, publica los certificados que un emisor ha retirado. El Protocolo de Estado de Certificados en Línea, u OCSP, permite a un validador solicitar el estado del certificado a un emisor de respuestas.
El componente que valida el certificado aplica la directiva de comprobación de estado correspondiente. En el caso de los certificados de cliente, suele ser el servicio de autenticación y no el punto de acceso. Si la información de estado no está disponible, una directiva de cierre por fallo («fail-closed») puede bloquear dispositivos válidos, mientras que una directiva de apertura por fallo («fail-open») puede aceptar una credencial cuya revocación no se pueda confirmar.
Haga que esa elección sea explícita. Incluya la información de estado almacenada en caché, los retrasos de publicación y la disponibilidad del emisor de respuestas en sus pruebas, en lugar de asumir que hacer clic en “revocar” cambia de inmediato cada decisión de autenticación.
Utilice un procedimiento completo para dispositivos extraviados
Para un portátil extraviado, coordine las acciones en lugar de tratar cada una como el paso final de un equipo independiente:
- Identifique y retire la credencial. Asocie el punto de conexión con el número de serie de su certificado real y revoque la credencial correspondiente.
- Evite la emisión de sustituciones. Deshabilite la elegibilidad de inscripción del dispositivo y aplique el proceso adecuado de retirada o eliminación del MDM.
- Finalice el acceso activo. Utilice los controles de desconexión de sesión compatibles, incluido el cambio de autorización (RADIUS Change of Authorization) donde la infraestructura lo admita.
- Verifique el resultado. Confirme que la sesión ha finalizado y que se rechaza cualquier nuevo intento de autenticación.
La revocación por sí sola no interrumpe necesariamente una sesión inalámbrica establecida. En equipos que no dispongan de un mecanismo de desconexión compatible, la sesión puede continuar hasta la reconexión, la reautenticación u otro límite de sesión impuesto. Registre esa limitación en el procedimiento de incidentes.
Su registro de auditoría debe incluir:
- Identidad de la credencial: Identificador del dispositivo, número de serie del certificado y propietario asociado.
- Evidencia de la decisión: Motivo de la revocación, operador y hora de la acción.
- Evidencia de aplicación: Hora de finalización de la sesión y resultado del rechazo posterior.
- Exposición pendiente: Cualquier sesión que no se haya podido finalizar de forma forzada y la acción de contención realizada.
Programe ejercicios de revocación. Ejecútelos tras cambios en la directiva de autenticación, así como durante las pruebas operativas de rutina, para que un incidente real de pérdida de dispositivo no sea su primer intento de probar la ruta completa.
Planificación de elegibilidad de dispositivos y excepciones
Tipos de dispositivos y su adecuación con EAP-TLS
| Clase de dispositivo | Idoneidad de EAP-TLS | Alternativa habitual | Pregunta clave que debe hacerse |
|---|---|---|---|
| Portátiles y teléfonos gestionados | Alta | Ninguna necesaria, registro en MDM | ¿Es fiable el registro en MDM? |
| Tabletas corporativas y quioscos | Buena cuando están gestionados por MDM | Clave específica de quiosco por sí sola en SSID | ¿Puede la clave privada residir en un almacenamiento seguro? |
| Sensores IoT sin interfaz gráfica (headless) | Deficiente sin el firmware adecuado | Clave por dispositivo en una VLAN aislada | ¿Admite el firmware 802.1X? |
| Sistemas de salas, audiovisuales y conferencias | Compatibilidad específica del proveedor | SSID dedicada con clave por dispositivo | ¿Puede el proveedor instalar y renovar certificados? |
| Dispositivos médicos | A menudo limitada | Red segmentada mediante un método aprobado por el proveedor | ¿Está el dispositivo certificado para este método? |
| Endpoints con sistemas operativos heredados | No compatible si faltan las capacidades requeridas | VLAN en cuarentena con excepción con límite de tiempo | ¿Cuándo se revisa la excepción? |
La restricción fundamental es que cada EAP-TLS cliente necesita su propio certificado, no basta únicamente con confiar en el servidor. La guía sobre redes inalámbricas del NIST distingue este requisito de certificado de cliente de la autenticación mediante certificado exclusivo en el servidor.
Por lo tanto, un dispositivo necesita un suplicante operativo, una protección de clave privada adecuada y una vía compatible para recibir y sustituir su credencial. Una ficha de especificaciones que indique "compatible con enterprise WiFi" no es suficiente para confirmar dichas capacidades.
Pruebe todo el ciclo de vida del dispositivo
Para un sistema de sala de conferencias, solicite al proveedor que demuestre la instalación, renovación y recuperación de certificados tras un restablecimiento de fábrica. Una interfaz web que acepte la carga de certificados puede resolver la incorporación sin resolver el mantenimiento.
En el caso de los equipos médicos y operativos, conserve los requisitos de soporte del proveedor. No cambie el método de autenticación de un dispositivo de producción únicamente porque otro producto del mismo fabricante lo admita.
Los dispositivos personales requieren una decisión de elegibilidad independiente. Su diseño de incorporación BYOD debe establecer qué gestión o instalación de perfil es aceptable antes de requerir la inscripción de los usuarios.
Defina excepciones acotadas y justificables
Un dispositivo que no pueda utilizar certificados no debe heredar los permisos de acceso del portátil de un empleado gestionado. Asigne un propietario definido a su credencial alternativa y restrinja la red a sus destinos necesarios.
Registre lo siguiente para cada excepción:
- Motivo técnico: La falta de capacidad o la restricción del proveedor, respaldada por una comprobación de configuración.
- Controles compensatorios: Segmentación, servicios permitidos y la alternativa revocable de forma individual.
- Fecha de revisión: Una decisión programada para renovar, cambiar o eliminar la excepción.
- Plan de sustitución: La actualización de firmware, el método de incorporación compatible o el reemplazo de hardware que le pondría fin.
Evite convertir una red de cuarentena temporal en un destino permanente para equipos no identificados. Una excepción sin propietario ni condición de salida se transforma en una directiva de acceso no documentada. El enfoque más defendible no consiste en utilizar certificados a cualquier precio, sino en implantar una autenticación sólida de dispositivos gestionados junto con alternativas restringidas deliberadamente.
Confirme su plan de certificados antes del despliegue
Una demostración con éxito muestra que un portátil en buen estado puede conectarse. Un piloto útil muestra qué ocurre cuando falla la inscripción, caduca una credencial, se retira un dispositivo y una dependencia deja de estar disponible. Apruebe el modelo operativo, no solo el primer saludo con éxito.
Elija una ubicación piloto e identifique las clases de dispositivos incluidas en el alcance antes de modificar el acceso a producción. Elabore un inventario con las capacidades de los puntos de acceso, el comportamiento de los suplicantes y las versiones de firmware. Cuando se requiera un perfil de mayor garantía, valide la plantilla de certificado seleccionada, las comprobaciones de la cadena de certificados y el uso ampliado de la clave con extremos representativos.
Concrete la revisión de preparación de esta semana
Utilice esta lista de comprobación para sacar a la luz la falta de responsables y las suposiciones no probadas.
- Confirmar la compatibilidad de los dispositivos: verifique que cada dispositivo dentro del alcance puede almacenar y utilizar una clave privada protegida, y no solo importar un certificado.
- Confirmar la confianza y la renovación: asigne propietarios para la cadena de CA, el servicio de inscripción, la supervisión de renovaciones y la ruta de recuperación.
- Probar la aplicación de directivas: demuestre la aceptación, el rechazo, la revocación y la finalización de sesiones activas compatibles.
- Aprobar excepciones: asigne a cada clase no compatible una alternativa restringida, un propietario responsable y una fecha de revisión.
- Configurar alertas accionables: dirija los eventos de caducidad inminente y las renovaciones fallidas a alguien que pueda resolverlos.
Utilice un RADIUS procedimiento de prueba de autenticación repetible para que los ingenieros recopilen pruebas comparables. Registre el estado del cliente, el resultado esperado, el resultado real y el código de fallo correspondiente.
Juzgue el piloto según su nivel de soporte
Ejecute la ruta del certificado junto a la red existente con un procedimiento de reversión definido. Incluya la inscripción remota, un punto final recompilado, un repuesto fuera de línea y los sistemas operativos compatibles con su servicio de asistencia. No elija únicamente ordenadores portátiles asignados recientemente.
Revise las incidencias del servicio de asistencia junto con los registros de autenticación. Separe los fallos de certificados de los problemas de cobertura inalámbrica, asignación de direcciones y VLAN, para que el equipo no rediseñe la PKI para solucionar un fallo no relacionado.
La aceptación del piloto debería significar que los dispositivos gestionados normalmente se conectan sin intervención del usuario, los fallos tienen causas identificadas y se puede demostrar la revocación del acceso. Conserve pruebas de los intentos tanto correctos como denegados, con suficiente contexto de identidad para explicar la decisión.
Fije la fecha de revisión del piloto antes de que este comience. Confirme la ubicación, las clases de dispositivos, los propietarios y los criterios de aceptación esta semana; a continuación, amplíe el alcance solo después de que el equipo haya resuelto los fallos y demostrado la capacidad de recuperación. Un despliegue más reducido con una renovación y revocación fiables constituye una base mejor que una implantación amplia que nadie sea capaz de reparar con garantía.
Purple Access ofrece WiFi para empleados basada en certificados a través de EAP-TLS entregado por MDM, junto con acceso para invitados y por dispositivo en los puntos de acceso que ya posee. Visite Purple Access para planificar un piloto en una ubicación, validar el certificado y las rutas de excepción, y evaluar el resultado en los tickets de soporte y las pruebas de auditoría antes de ampliar el despliegue.
