Autenticación WiFi basada en certificados: Guía de EAP-TLS
Published
Alguien se va de la empresa y su equipo está decidiendo si debe cambiar nuevamente la contraseña del WiFi para empleadosWiFi. Cambiarla significa volver a conectar computadoras portátiles, teléfonos, tabletas de recepción y equipos que nadie recuerda haber configurado. Dejarla como está significa aceptar que alguien ajeno a la organización aún sabe cómo conectarse.
La autenticación basada en certificados WiFi le ofrece una mejor manera de identificar dispositivos confiables. Sin embargo, también cambia el trabajo que su equipo debe realizar: en lugar de distribuir contraseñas, administrará cadenas de confianza, renovación de certificados, revocación y dispositivos que desaparecen en almacenamiento durante meses. La mejora en la seguridad es real. Una operación confiable requiere más que solo seleccionar EAP-TLS en un perfil inalámbrico.
Tabla de contenido
- Qué significa la autenticación basada en certificadosWiFi
- Cómo funciona el intercambio de señales EAP-TLS paso a paso
- Certificados en comparación con contraseñas compartidas y PEAP
- Creación de la AC y aprovisionamiento de certificados mediante MDM
- Gestión del ciclo de vida del certificado: de la emisión a la renovación
- Revocación de acceso en caso de pérdida de dispositivos o salida de personal
- Elegibilidad de dispositivos y planificación de excepciones
- Confirme su plan de certificados antes del despliegue
Significado de la autenticación WiFi basada en certificados
La autenticación basada en certificados WiFi reemplaza una contraseña compartida de WiFi con un certificado digital individual, el cual la red verifica antes de conceder el acceso. Piense en el código de acceso compartido de una oficina frente a una credencial de empleado. Con el código, todos demuestran que conocen el mismo secreto. Con una credencial, el personal de seguridad puede identificar una credencial específica y cancelarla de manera independiente.
Supongamos que una laptop administrada necesita acceso a la red del personal. Su certificado identifica al dispositivo o a su usuario asignado, y su clave privada protegida le permite demostrar que posee esa credencial. El certificado en sí no es una contraseña secreta, y copiar únicamente el certificado público no proporciona la clave privada correspondiente.
El diagrama muestra cómo las credenciales individuales reemplazan la contraseña común.
Dónde encajan los componentes
El marco subyacente es IEEE 802.1X, desarrollado originalmente para Ethernet cableado y adaptado para redes LAN inalámbricas. El resumen 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 RADIUS evalúa la solicitud de autenticación. EAP-TLS es el método de autenticación basado en certificados que se realiza a través de ese esquema. El dispositivo y el servidor de autenticación se validan mutuamente antes de establecer el material de claves para la conexión.
Mantenga estos componentes separados:
- Certificado de dispositivo: Identifica el punto de conexión o al usuario y funciona con una clave privada conservada por el dispositivo.
- Certificado de servidor de autenticación: Permite que el dispositivo verifique 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 confiable.
El dispositivo y el servidor no necesitan necesariamente certificados de la misma autoridad emisora. Lo que importa es que cada parte confíe en el emisor adecuado y aplique la política de validación correcta.
Regla práctica: Trate los certificados como un sistema de identidad de red, no como contraseñas complicadas.
Esa distinción cambia la forma en que gestiona la pérdida de una computadora portátil. Puede revocar su credencial sin tener que reemplazar las credenciales en los equipos de todos los demás. Sin embargo, la posesión de un certificado válido establece la identidad, no un permiso ilimitado. Su política de acceso aún debe decidir a qué puede acceder esa identidad.
Cómo funciona el intercambio de señales 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 maneja la autenticación de la red empresarial.
Este flujo simplificado muestra las transferencias principales, en lugar de cada mensaje de protocolo.
Siga el intercambio y sus puntos de falla
La autenticación mutua y la derivación de claves subyacentes 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 punto final y el servicio de autenticación en lugar de emitir el certificado del dispositivo por sí mismo. Un problema de conectividad de RADIUS o un punto de acceso registrado de forma incorrecta pueden detener el intercambio en este punto.
El servidor presenta su certificado. El dispositivo verifica la cadena de certificados, la validez y la identidad esperada del servidor. Un emisor no confiable, una cadena incompleta o un nombre de servidor no esperado deberían hacer que el dispositivo rechace la conexión.
El dispositivo presenta su certificado de cliente. El servidor valida la credencial, verifica la información de revocación aplicable y evalúa la identidad. La falta de un certificado o una clave privada inaccesible pueden parecer una falla de conexión genérica para el usuario, incluso cuando los registros del servidor muestran una causa específica.
El intercambio TLS establece el material de claves compartidas. El punto final debe demostrar la posesión de su clave privada, no solo presentar un archivo de certificado. Las configuraciones criptográficas incompatibles pueden impedir que se complete el proceso, incluso cuando ambos certificados sean válidos por lo demás.
RADIUS devuelve el resultado de la autenticación y los atributos de política. Una aceptación puede incluir una asignación de VLAN u otros atributos de autorización compatibles. Una autenticación exitosa seguida de una conexión no utilizable puede indicar un problema de política descendente o de VLAN, 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 RADIUS esperados. Mantenga habilitada la validación del certificado del servidor. No permita que los usuarios omitan una advertencia solo para conectarse.
Utilice este video junto con el flujo del protocolo al analizar 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 lo tanto, la resolución de problemas requiere evidencia tanto del suplicante como de RADIUS, no solo un panel del punto de acceso que muestre que un cliente no pudo conectarse.
Comparación de certificados con contraseñas compartidas y PEAP
WiFi métodos de autenticación bajo los mismos criterios
| Método | Credencial en el dispositivo | Alcance de revocación | Rendición de cuentas | Esfuerzo de configuración |
|---|---|---|---|---|
| Frase de contraseña compartida de WPA2 o WPA3-Personal | Una frase de contraseña conocida por todos los usuarios | Cambia la clave para todos | Ninguna a partir de la credencial compartida en sí | 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 únicos por dispositivo | Revoca un certificado | Por dispositivo y usuario cuando se mapea | Alto, requiere PKI y aprovisionamiento administrado |
| WPA3-Enterprise de 192 bits con EAP-TLS | Certificado que cumple con los requisitos criptográficos del perfil | Revoca un certificado | Por dispositivo y usuario cuando se mapea | Alto, además de verificaciones de compatibilidad de cifrado |
EAP-TLS no es sinónimo de WPA3. El registro de certificación de Wi-Fi Alliance identifica a EAP-TLS entre los métodos de autenticación empresarial compatibles. La autenticación por 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 acceso compartida demuestra el conocimiento de un secreto común. No establece qué empleado la proporcionó, aunque el equipo de red aún puede registrar los detalles de la conexión. Las salidas del personal se vuelven complicadas porque reemplazar 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 una validación adecuada del servidor sigue siendo importante. Puede proporcionar registros útiles por usuario, pero los cambios de contraseña y los problemas de cuenta siguen formando parte del soporte de 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 administrar, siempre que el inventario vincule correctamente los certificados con los puntos finales y los propietarios.
Elija el método cuyo ciclo de vida de credenciales su equipo pueda operar realmente, no simplemente la etiqueta más sólida en el menú del controlador.
Adapte el método a la población
Las frases de contraseña compartidas son una opción predeterminada deficiente para el acceso del personal gestionado donde la retirada individual y la responsabilidad son importantes. Incluso para invitados y equipos de bajo riesgo, una contraseña común requiere una política deliberada de distribución y reemplazo.
Los certificados son ideales para laptops y teléfonos administrados porque se pueden aprovisionar a través de un sistema de administración existente. El perfil empresarial de mayor seguridad añade trabajo de compatibilidad; no elimina ninguna responsabilidad del ciclo de vida. PEAP puede seguir siendo una opción de migración cuando existen cuentas individuales pero el aprovisionamiento de certificados aún no está listo, en lugar de ser un motivo para posponer indefinidamente un diseño de acceso basado en identidades.
Creación de la CA y aprovisionamiento de certificados mediante MDM
Un despliegue manejable comienza con una infraestructura de clave pública, o PKI, cuya titularidad sea clara. Una jerarquía común mantiene una autoridad de certificación raíz fuera de línea y utiliza una CA emisora para la emisión rutinaria de certificados. Un servicio PKI administrado puede cumplir esas funciones sin que su equipo tenga que operar cada componente de manera local.
La CA emisora firma los certificados del dispositivo y del servidor. RADIUS debe confiar en la cadena de certificados del cliente, mientras que los puntos de extremo deben confiar en la cadena de servidores adecuada. No asuma que la instalación de 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 el uso de autenticación de cliente, una identidad de dispositivo o usuario que su política pueda resolver, y un periodo de validez regido por su diseño de renovación y recuperación.
Perfiles de certificado por nivel de seguridad
| Perfil | Clave y algoritmo | Validez típica | Dónde se adapta |
|---|---|---|---|
| Laptop o teléfono administrado estándar | Algoritmo aprobado por la organización y compatible con toda la flota | Definido por la política de renovación y recuperación | Flotas mixtas en WPA2-Enterprise |
| Dispositivo administrado más estricto | Plantilla más sólida aprobada después de pruebas de punto final | Definido por la política y la capacidad de renovación | Flotas modernas con firmware actual |
| WPA3-Enterprise de 192 bits | ECDSA P-384 o RSA 3072 o superior | Definido por la política y la capacidad de renovación | Sitios de mayor garantía después de pruebas de compatibilidad |
| Dispositivo sin pantalla o heredado | A menudo incompatible | Ciclo de vida respaldado por el proveedor o vencimiento por excepción | Ruta de excepción |
La guía de implementación de Wi-Fi Alliance especifica que el modo de 192 bits de WPA3-Enterprise 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 debe verificarse con respecto a la suite completa seleccionada, no solo con la etiqueta de clave del certificado.
Las plantillas de certificados, el software RADIUS, los suplicantes y los proveedores criptográficos deben coincidir. Un punto de acceso que admita EAP-TLS ordinario aún puede fallar bajo este perfil más estricto.
Entregue confianza, credenciales y configuración en conjunto
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 varias máquinas.
Implemente las dependencias en un orden controlado:
- Confíe primero: Instale los certificados de CA de confianza requeridos.
- Credencial después: Entregue la configuración SCEP y confirme la emisión correcta.
- Perfil inalámbrico al final: Haga referencia a las credenciales del cliente previstas y a la configuración de validación del servidor.
Mantenga una segmentación de grupos consistente en los perfiles dependientes. Utilice la comparación de perfiles de certificados MDM WiFi para revisar las diferencias de plataforma antes de estandarizar el despliegue. Asimismo, proporcione una conexión de inscripción que no dependa del certificado que el dispositivo todavía está intentando obtener.
Gestión del ciclo de vida de los certificados desde la emisión hasta la renovación
Una computadora portátil que se conecta con éxito hoy puede fallar después de permanecer en un armario durante su periodo de renovación. El punto de acceso puede estar en buen estado, la contraseña no ha cambiado y el usuario no ha cometido ningún error. El punto final simplemente ya no tiene una credencial aceptable.
La guía de 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, incluyendo el estado de revocación. Esos requisitos hacen que las dependencias del ciclo de vida formen parte de la disponibilidad de la red.
Esta cronología es útil para asignar la responsabilidad más allá del despliegue inicial.
Asigne un control operativo a cada etapa
| Etapa | Control | Falla que previene |
|---|---|---|
| Inscripción | Monitorear el registro de MDM y la asignación de perfiles | El dispositivo nunca recibe una instrucción de inscripción |
| Emisión | Validar los permisos de la plantilla y los resultados de la solicitud | La CA rechaza las solicitudes o emite certificados inservibles |
| Despliegue | Verificar la instalación y el acceso protegido a la clave privada | El certificado existe pero el suplicante no puede usarlo |
| Renovación | Comenzar temprano, monitorear la finalización y permitir un solapamiento probado | Los dispositivos llegan al vencimiento sin un reemplazo |
| Vencimiento | Alertar a los propietarios y proporcionar una ruta de recuperación restringida | Los dispositivos vencidos no tienen forma de recuperarse |
| Retiro | Retirar credenciales y eliminar entradas obsoletas del inventario | El equipo retirado conserva una identidad aceptada |
La renovación requiere confirmación de finalización, no solo una configuración de automatización habilitada. Supervise si se emitió, instaló y utilizó correctamente un certificado de reemplazo. Durante el período de superposición, confirme que el suplicante seleccione una credencial adecuada en lugar de elegir repetidamente una obsoleta.
Planifique para los dispositivos que no están en línea
Establezca la ventana de renovación según el comportamiento real del dispositivo. El equipo utilizado de forma estacional o guardado como repuesto puede requerir un proceso de recuperación diferente al de una laptop que se conecta a diario. No asuma que un punto de extremo fuera de línea puede renovarse solo porque su certificado anterior sigue 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, el vencimiento y el estado de renovación. Incluya los certificados de la CA emisora y del servidor de autenticación, ya que su reemplazo puede afectar a una población mucho más amplia.
Un trabajo de renovación que se ejecutó correctamente no es lo mismo que un dispositivo que puede autenticarse con su certificado de reemplazo.
Ponga a prueba errores de reloj, reconstrucciones de sistemas operativos y cambios en la cadena de la CA. Una reconstrucció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 acceso sin la confianza requerida.
Asigne responsables nombrados para las fallas que involucren MDM, PKI y servicios de red. De lo contrario, cada equipo puede informar que su propio sistema funciona correctamente mientras el dispositivo final permanece desconectado. EAP-TLS transforma el riesgo de interrupciones en un problema de inventario, automatización y gestión de dependencias. No elimina ese riesgo.
Revocación del acceso cuando se pierden dispositivos o las personas se van
La cuenta de directorio de una persona que deja la empresa se inhabilita, pero su laptop aún conserva un certificado que no ha expirado. Si puede reconectarse o no depende de su integración de autorización y de sus controles de revocación. Inhabilitar una cuenta y revocar un certificado son acciones distintas, a menos que su flujo de trabajo configurado las vincule explícitamente.
Defina el resultado de la baja de usuarios en términos operativos: las nuevas autenticaciones deben fallar, la inscripción no debe emitir credenciales de reemplazo y las sesiones existentes deben finalizar mediante un mecanismo compatible. Un ticket de RR. HH. completado no demuestra ninguno de esos resultados.
Comprenda las verificaciones 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. Para los certificados de cliente, esto normalmente lo realiza 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 falla puede bloquear dispositivos que de otro modo serían válidos, mientras que una directiva de apertura por falla 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 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 cada decisión de autenticación de inmediato.
Utilice un procedimiento completo para dispositivos extraviados
En caso de que extravíe una laptop, 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 final con su número de serie de certificado real y revoque la credencial correspondiente.
- Evite la emisión de reemplazos. Deshabilite la elegibilidad de inscripción del dispositivo y aplique el proceso adecuado de retiro o eliminación de MDM.
- Finalice el acceso activo. Utilice controles compatibles de desconexión de sesión, incluyendo el Cambio de Autorización de RADIUS donde la infraestructura lo admita.
- Verifique el resultado. Confirme que la sesión finalizó y que se rechaza cualquier nuevo intento de autenticación.
La revocación por sí sola no necesariamente finaliza una sesión inalámbrica establecida. En equipos que no cuentan con 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 de rechazo posterior.
- Exposición pendiente: Cualquier sesión que no se haya podido finalizar de manera forzada y la acción de contención realizada.
Programe ejercicios de revocación. Ejecútelos después de realizar cambios en la política de autenticación, así como durante las pruebas operativas de rutina, de modo que un incidente real de extravío de dispositivo no sea su primer intento de probar todo el proceso.
Planificación de elegibilidad de dispositivos y excepciones
Clases de dispositivos y su adecuación con EAP-TLS
| Clase de dispositivo | Ajuste de EAP-TLS | Alternativa típica | Pregunta clave a realizar |
|---|---|---|---|
| Laptops y teléfonos administrados | Fuerte | Ninguna necesaria, inscripción en MDM | ¿Es confiable la inscripción en MDM? |
| Tabletas corporativas y quioscos | Bueno cuando está administrado por MDM | Clave específica de quiosco por sí sola SSID | ¿Puede ubicarse la clave privada en un almacenamiento seguro? |
| Sensores IoT sin interfaz humana | Deficiente sin el firmware adecuado | Clave por dispositivo en una red aislada VLAN | ¿El firmware es compatible con 802.1X? |
| Sistemas de salas, AV y videoconferencias | Soporte específico del proveedor | SSID dedicada con clave por dispositivo | ¿El proveedor puede instalar y renovar certificados? |
| Dispositivos médicos | A menudo limitado | Red segmentada con un método aprobado por el proveedor | ¿El dispositivo está certificado para este método? |
| Endpoints con sistemas operativos heredados | Sin soporte cuando faltan las capacidades requeridas | VLAN de cuarentena con una excepción con tiempo límite | ¿Cuándo se revisa la excepción? |
La restricción fundamental es que cada EAP-TLS cliente necesita su propio certificado, no solo la confianza en el servidor. La guía de redes inalámbricas del NIST distingue este requisito de certificado de cliente de la autenticación por certificado solo de servidor.
Por lo tanto, un dispositivo necesita un suplicante operativo, una protección adecuada de la clave privada y una forma compatible de recibir y reemplazar su credencial. Una hoja de especificaciones que indique que la WiFi empresarial es compatible no es suficiente para establecer esas 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 después de 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 del equipo médico y operativo, mantenga 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é administración o instalación de perfil es aceptable antes de solicitar a los usuarios que se inscriban.
Haga que las excepciones sean limitadas y auditables
Un dispositivo que no puede utilizar certificados no debe heredar los permisos de acceso de una laptop de empleado gestionada. Asigne a su credencial alternativa un propietario definido y restrinja la red a los destinos necesarios.
Registre lo siguiente para cada excepción:
- Razón técnica: La capacidad faltante o la restricción del proveedor, respaldada por una verificació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 reemplazo: La actualización de firmware, el método de incorporación compatible o el reemplazo de hardware que le daría fin.
Evite convertir una red de cuarentena temporal en un espacio permanente para equipos no identificados. Una excepción sin un propietario o sin una condición de salida se convierte en una política de acceso no documentada. El enfoque defendible no consiste en obtener certificados a cualquier costo; se trata de una autenticación sólida de dispositivos administrados junto con alternativas delimitadas deliberadamente.
Confirme su plan de certificados antes de la implementación
Una demostración exitosa muestra que una laptop en buen estado puede conectarse. Un piloto útil muestra lo que sucede cuando falla la inscripción, expira una credencial, se retira un dispositivo y una dependencia deja de estar disponible. Apruebe el modelo operativo, no solo la primera negociación de conexión exitosa.
Elija un sitio piloto e identifique las clases de dispositivos contempladas dentro del alcance antes de modificar el acceso en producción. Inventaríe las capacidades de los puntos de acceso, el comportamiento del suplicante y las versiones de firmware. Cuando se requiera un perfil de mayor garantía, valide la plantilla de certificado seleccionada, las verificaciones de la cadena de certificados y el uso extendido de claves con puntos finales representativos.
Haga concreta la revisión de preparación de esta semana
Utilice esta lista de verificación para exponer a los propietarios faltantes y las suposiciones no probadas.
- Confirme el soporte del dispositivo: Verifique que cada dispositivo dentro del alcance pueda almacenar y usar una clave privada protegida, y no simplemente importar un certificado.
- Confirme la confianza y la renovación: Asigne propietarios para la cadena de CA, el servicio de inscripción, el monitoreo de renovación y la ruta de recuperación.
- Pruebe la aplicación: Demuestre la aceptación, el rechazo, la revocación y la terminación de sesiones activas compatibles.
- Apruebe excepciones: Otorgue a cada clase no compatible una alternativa restringida, un propietario responsable y una fecha de revisión.
- Configure alertas accionables: Encamine los eventos de vencimiento 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 evidencia comparable. Registre la condición del cliente, el resultado esperado, el resultado real y el código de falla correspondiente.
Juzgue el piloto por la capacidad de soporte
Ejecute la ruta de certificados junto a la red existente con un procedimiento de reversión definido. Incluya la inscripción remota, un punto final reconstruido, un repuesto fuera de línea y los sistemas operativos que admite su mesa de ayuda. No elija únicamente computadoras portátiles asignadas recientemente.
Revise los tickets de soporte junto con los registros de autenticación. Separe las fallas de certificados de los problemas de cobertura de red inalámbrica, asignación de direcciones y VLAN, para que el equipo no rediseñe la PKI para resolver una falla no relacionada.
La aceptación del piloto debe significar que los dispositivos gestionados normalmente se conectan sin intervención del usuario, las fallas tienen causas identificadas y se puede demostrar la revocación del acceso. Conserve evidencia tanto de los intentos exitosos como de los rechazados, con suficiente contexto de identidad para explicar la decisión.
Establezca la fecha de revisión del piloto antes de que comience. Confirme el sitio, las clases de dispositivos, los propietarios y los criterios de aceptación esta semana; posteriormente, realice la expansión únicamente después de que el equipo haya resuelto las fallas y demostrado la recuperación. Un despliegue más pequeño con renovación y revocación confiables es una mejor base que una implementación amplia que nadie pueda reparar con certeza.
Purple Access ofrece WiFi para empleados basada en certificados mediante EAP-TLS entregado por MDM, junto con acceso para invitados y por dispositivo en los puntos de acceso que usted ya posee. Visite Purple Access para planificar una prueba piloto en una ubicación, validar los certificados y las rutas de excepción, y evaluar el resultado en los tickets de soporte y evidencia de auditoría antes de ampliar el despliegue.
