Cómo usar Microsoft Intune para distribuir certificados de WiFi a los dispositivos

CÓMO USAR MICROSOFT INTUNE PARA DISTRIBUIR CERTIFICADOS DE WIFI A DISPOSITIVOS Una sesión informativa sobre inteligencia de WiFi empresarial de Purple [INTRODUCCIÓN Y CONTEXTO — aproximadamente 1 minuto] Bienvenidos de nuevo. Hoy les hablo en nombre de Purple, la plataforma de inteligencia de WiFi empresarial, y este episodio es una sesión informativa enfocada en una de las capacidades más prácticas y, honestamente, más subestimadas del conjunto de herramientas de Microsoft Entra ID e Intune: la implementación automatizada de certificados para la autenticación WiFi 802.1X. Si usted administra WiFi en un complejo hotelero, una cadena de tiendas de retail, un estadio o propiedades del sector público, conocerá el problema que estoy por describir. Tiene cientos o miles de dispositivos administrados. Quiere que se conecten a su WiFi corporativo de forma automática y segura, sin que los usuarios tengan que escribir contraseñas y sin que el equipo de TI tenga que intervenir en cada dispositivo. Y quiere que esa conexión sea criptográficamente sólida, no solo una contraseña compartida que alguien ya envió por correo electrónico a la mitad de la organización. Eso es exactamente lo que resuelve la implementación de certificados de Intune. Y en los próximos nueve minutos, lo guiaré a través de cómo funciona, cómo implementarlo y los errores comunes que atrapan a la mayoría de los equipos en su primer intento. [INMERSIÓN TÉCNICA PROFUNDA — aproximadamente 5 minutos] Comencemos con la arquitectura. La base aquí es el estándar IEEE 802.1X, el estándar de control de acceso a redes basado en puertos que ha sido el pilar de la seguridad WiFi empresarial durante más de dos décadas. Cuando un dispositivo se conecta a su WiFi, 802.1X requiere que se autentique antes de obtener acceso a la red. La conversación de autenticación ocurre entre tres partes: el dispositivo (llamado suplicante), su punto de acceso WiFi (que actúa como el autenticador) y su servidor RADIUS (que es el servidor de autenticación que toma la decisión final). Ahora bien, 802.1X admite múltiples métodos de autenticación. El más seguro es EAP-TLS (protocolo de autenticación extensible con seguridad de la capa de transporte). EAP-TLS utiliza autenticación mutua por certificados: el dispositivo presenta un certificado para probar su identidad y el servidor RADIUS presenta un certificado para probar la suya. No hay contraseñas involucradas. No hay credenciales que puedan ser objeto de phishing. Esto es a lo que apuntamos. El desafío siempre ha sido instalar esos certificados en los dispositivos a escala. Ahí es donde entra Microsoft Intune. Intune admite dos mecanismos de implementación de certificados: SCEP (protocolo simple de inscripción de certificados) y PKCS, que significa estándares de criptografía de clave pública. Comprender la diferencia es importante. Con SCEP, la clave privada se genera en el propio dispositivo. El dispositivo crea una solicitud de firma de certificado, la envía a su autoridad de certificación a través de un servidor intermediario llamado NDES (servicio de inscripción de dispositivos de red) y la CA emite el certificado de vuelta. La clave privada nunca sale del dispositivo. Este es el enfoque más seguro y se recomienda para entornos BYOD e implementaciones de alta seguridad.Con PKCS, la autoridad de certificación genera el par de claves y el conector de certificados de Intune entrega la clave privada y el certificado al dispositivo. Es más fácil de configurar - no se requiere un servidor NDES - pero la clave privada sí transita a través del conector, lo cual es un factor a considerar para su postura de seguridad. Para la mayoría de las implementaciones empresariales recomendaría SCEP para BYOD y entornos de dispositivos mixtos, y PKCS donde tenga una flota homogénea de dispositivos Windows propiedad de la empresa y desee minimizar la complejidad de la infraestructura. Ahora hablemos de la secuencia de implementación, porque el orden importa y hacerlo mal es la causa más común de fallas en los lanzamientos. Paso uno: configure su autoridad de certificación. Necesita una plantilla de certificado en su instancia de Active Directory Certificate Services - o si es totalmente nativo de la nube, la Cloud PKI de Intune de Microsoft ya está disponible para el público en general y elimina por completo el requisito de una CA local. La plantilla necesita las extensiones de uso de clave correctas: la autenticación de cliente es obligatoria. Establezca el tamaño mínimo de clave en 2048 bits, o 4096 si la política de seguridad de su organización lo requiere. Paso dos: implemente el certificado raíz de confianza. Antes de que cualquier dispositivo pueda validar el certificado del servidor RADIUS, debe confiar en la CA que lo emitió. Cree un perfil de configuración de certificado de confianza en Intune, cargue el certificado de la CA raíz y asígnelo a sus grupos de dispositivos. Esto debe llegar a los dispositivos antes que cualquier perfil de WiFi o de certificado de cliente. Si se equivoca en la secuencia, los dispositivos rechazarán el servidor RADIUS y pasará la tarde entera analizando el ID de evento 20271 en el registro de eventos de Windows. Paso tres: implemente el perfil de certificado de cliente. Este puede ser su perfil SCEP (que apunta a la URL de su servidor NDES) o su perfil PKCS (que apunta a su autoridad de certificación). El Nombre alternativo del sujeto (SAN) debe incluir el Nombre principal de usuario (UPN) para certificados de usuario, o el ID de dispositivo de AAD para certificados de dispositivo. Esta distinción es importante: los certificados de usuario autentican al usuario que ha iniciado sesión, mientras que los certificados de dispositivo autentican a la máquina misma, lo que significa que el dispositivo puede conectarse a la WiFi antes de que el usuario inicie sesión - lo cual es útil para escenarios de unión a dominios e implementaciones de quioscos. Paso cuatro: cree el perfil de configuración de WiFi. En Intune, esto se encuentra en Dispositivos, Perfiles de configuración, Plantillas, Wi-Fi. Establezca el tipo de WiFi en Enterprise, ingrese su SSID, configure el tipo de EAP en EAP-TLS, configure los ajustes de confianza del servidor (aquí es donde hace referencia al nombre del certificado del servidor RADIUS) y, para la autenticación del cliente, haga referencia al perfil de certificado que creó en el paso tres. Paso cinco: asigne todo a los grupos correctos y valide. Asigne su certificado raíz, certificado de cliente y perfiles de WiFi a los mismos grupos de usuarios o dispositivos. Utilice los informes integrados de Intune para monitorear el estado de implementación de los perfiles. Una implementación exitosa muestra los tres perfiles con el estado Succeeded en la lista de perfiles de configuración del dispositivo. Un punto crítico en la configuración de NPS para entornos de Windows Server: desde principios de 2024, Microsoft endureció los requisitos de asignación de certificados. Si utiliza certificados de dispositivo con dispositivos unidos a Azure AD que se autentican contra un NPS local, debe asegurarse de que el atributo altSecurityIdentities en el objeto de equipo en Active Directory esté completo con la huella digital del certificado. Esto no ocurre de forma automática; necesita un script o un flujo de trabajo para gestionarlo, que normalmente se activa cuando la CA emite un nuevo certificado. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos] Permítame compartir los tres errores más frecuentes que veo en los despliegues empresariales. Error uno: brechas en la cadena de certificados. El dispositivo debe confiar en cada certificado de la cadena, desde la CA raíz hasta el certificado del servidor RADIUS. Si el certificado de su servidor RADIUS fue emitido por una CA intermedia, debe implementar tanto la raíz como la intermedia en los dispositivos. He visto fallar despliegues durante semanas porque alguien implementó la raíz pero no la intermedia. Error dos: tiempos de asignación de perfiles. Los perfiles de Intune no llegan a los dispositivos de forma instantánea. En una gran infraestructura, los perfiles pueden tardar entre 15 y 30 minutos en propagarse después de la asignación. No realice pruebas inmediatamente después de crear los perfiles. Utilice el botón Sincronizar en el portal de Intune para forzar un registro y luego espere. Además, los perfiles de certificado de cliente deben desplegarse y confirmarse antes de que se aplique el perfil de WiFi; si el perfil de WiFi hace referencia a un certificado que aún no existe, el perfil fallará silenciosamente en algunas plataformas. Error tres: revocación de certificados en BYOD. Cuando un dispositivo se desvincula de Intune (ya sea porque un empleado se va o porque el dispositivo se pierde), necesita un proceso para revocar el certificado. Si utiliza SCEP con ADCS, configure correctamente el punto de distribución de la Lista de Revocación de Certificados y asegúrese de que su servidor RADIUS verifique la CRL u OCSP en cada autenticación. Este es un requisito de cumplimiento bajo marcos como PCI-DSS, que exige que los mecanismos de control de acceso se revoquen de inmediato cuando ya no sean necesarios. En cuanto al cumplimiento: si opera dentro del alcance de PCI-DSS (por ejemplo, en entornos de pago minoristas), la autenticación 802.1X basada en certificados es su control más sólido para el acceso a la red inalámbrica. Cumple con el Requisito 1.3 de PCI-DSS sobre controles de acceso a la red y con el Requisito 8.6 sobre factores de autenticación. Documente su proceso de gestión del ciclo de vida de los certificados como parte de sus evidencias de cumplimiento. Para entornos regulados por el GDPR, particularmente en el sector hotelero y el sector público, la separación entre su red corporativa 802.1X y su red de WiFi para invitados es fundamental. Su red corporativa administrada por Intune debe estar en una VLAN y un SSID completamente independientes de cualquier red de invitados o visitantes. La plataforma de WiFi para invitados de Purple se encarga del lado que da al visitante (el captive portal, la captura de consentimiento y la analítica), mientras que su red corporativa administrada por Intune gestiona los dispositivos del personal y operativos. Estas dos redes nunca deben compartir la infraestructura de autenticación. [PREGUNTAS Y RESPUESTAS RÁPIDAS - aproximadamente 1 minuto] Permítame repasar algunas preguntas que surgen con regularidad. ¿Puedo utilizar Intune Cloud PKI en lugar de ADCS local? Sí. Intune Cloud PKI de Microsoft, lanzado en 2024, proporciona una CA totalmente administrada en Azure. Elimina el requisito del servidor NDES para SCEP y simplifica significativamente la configuración del conector. Para implementaciones nuevas o empresas sin una infraestructura ADCS existente, es el camino recomendado. ¿Funciona esto para dispositivos macOS e iOS? Sí. Intune admite perfiles de certificados para Windows, iOS, iPadOS, Android y macOS. Los tipos de perfil y las opciones de configuración varían ligeramente según la plataforma, pero la arquitectura principal (raíz de confianza, certificado de cliente y perfil de WiFi) es consistente. ¿Qué pasa con los dispositivos personales en un programa BYOD? SCEP es su aliado en este caso. Con las políticas de cumplimiento de dispositivos de Intune, puede exigir que un dispositivo cumpla con los estándares mínimos de seguridad antes de que se emita un certificado. Si el dispositivo deja de cumplir con las normas (sin bloqueo de pantalla, sistema operativo desactualizado), el certificado se puede revocar y el acceso a la red se puede eliminar de forma automática. ¿Puede Purple integrarse con esta arquitectura? Absolutamente. La plataforma de Purple se ubica en el lado de la red de invitados, gestionando la autenticación del captive portal, la gestión del consentimiento y la analítica. La red corporativa 802.1X y el WiFi para invitados de Purple operan en paralelo (misma infraestructura física, diferentes SSIDs y VLANs), lo que le brinda una separación completa entre la conectividad del personal y la interacción con los visitantes. [RESUMEN Y PRÓXIMOS PASOS - aproximadamente 1 minuto] Para concluir: implementar certificados de WiFi a través de Intune es un proceso de cinco pasos (configuración de la CA, implementación de la raíz de confianza, perfil de certificado de cliente, perfil de WiFi y asignación de grupo). Elija SCEP para entornos de alta seguridad y BYOD; elija PKCS para flotas propiedad de la empresa que sean más sencillas. Asegúrese de realizar la secuencia de manera correcta, gestione el requisito de mapeo de certificados de NPS y cree un flujo de trabajo de revocación de certificados desde el primer día. El caso de negocio es claro: elimina las contraseñas de WiFi compartidas, obtiene registros de autenticación por dispositivo y por usuario, cumple con los requisitos de seguridad inalámbrica de PCI-DSS e ISO 27001, y reduce la carga de trabajo de TI que implica gestionar credenciales de WiFi en un gran patrimonio corporativo. Si está planeando un despliegue y desea entender cómo la plataforma de analíticas y WiFi para invitados de Purple se integra con la arquitectura de su red corporativa, visite purple.ai. Contamos con guías detalladas sobre la integración con Azure Entra ID, la arquitectura 802.1X y el diseño de redes de invitados para entornos hoteleros, comerciales y del sector público. Gracias por escuchar. Hasta la próxima.