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

CÓMO USAR MICROSOFT INTUNE PARA ENVIAR CERTIFICADOS DE WIFI A DISPOSITIVOS Una sesión informativa de Purple Enterprise WiFi Intelligence [INTRODUCCIÓN Y CONTEXTO — aproximadamente 1 minuto] Bienvenidos de nuevo. Hoy hablo en nombre de Purple, la plataforma de WiFi intelligence empresarial, y este episodio es una sesión informativa enfocada en una de las capacidades más prácticas —y, sinceramente, más subestimadas— del kit de herramientas de Microsoft Intune: la implementación automatizada de certificados para la autenticación WiFi 802.1X. Si gestionas WiFi en un complejo hotelero, una cadena de tiendas, un estadio o un entorno del sector público, conocerás el problema que estoy a punto de describir. Tienes cientos o miles de dispositivos gestionados. Quieres que se conecten a tu 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 configurar cada dispositivo de forma individual. Y quieres que esa conexión sea criptográficamente sólida, no solo una contraseña compartida que alguien ya haya enviado 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, te 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 IEEE 802.1X, el estándar de control de acceso a la red basado en puertos que ha sido la columna vertebral de la seguridad WiFi empresarial durante más de dos décadas. Cuando un dispositivo se conecta a tu WiFi, el estándar 802.1X requiere que se autentique antes de obtener cualquier acceso a la red. La conversación de autenticación ocurre entre tres partes: el dispositivo (llamado suplicante), tu punto de acceso WiFi (que actúa como el autenticador) y tu 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 de certificados: el dispositivo presenta un certificado para demostrar su identidad y el servidor RADIUS presenta un certificado para demostrar la suya. No hay contraseñas de por medio. No hay credenciales que puedan ser objeto de phishing. Esto es a lo que aspiramos. El desafío siempre ha sido llevar esos certificados a los dispositivos a gran 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 tu 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 Entidad de Certificación genera el par de claves, y el Intune Certificate Connector entrega la clave privada y el certificado al dispositivo. Es más sencillo de configurar —no requiere un servidor NDES— pero la clave privada 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 entornos BYOD y de dispositivos mixtos, y PKCS cuando se tiene una flota homogénea de dispositivos Windows propiedad de la empresa y se desea minimizar la complejidad de la infraestructura. Ahora, hablemos de la secuencia de implementación —porque el orden importa y equivocarse es la causa más común de fallas en los despliegues. Paso uno: configure su Entidad de Certificación. Necesita una plantilla de certificado en su instancia de Active Directory Certificate Services —o si es totalmente nativo de la nube, Cloud PKI de Microsoft Intune ya está disponible de forma 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 de cualquier perfil de WiFi o perfil de certificado de cliente. Si se equivoca en la secuencia, los dispositivos rechazarán el servidor RADIUS y pasará la tarde analizando el Event ID 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 Entidad de Certificación. El Nombre Alternativo del Sujeto debe incluir el Nombre Principal de Usuario 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 WiFi antes de que un usuario inicie sesión —útil para escenarios de unión a dominios y despliegues 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 de 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 la implementación del perfil. 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 sobre la configuración de NPS para entornos de Windows Server: desde principios de 2024, Microsoft endureció los requisitos de mapeo 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 la computadora en Active Directory esté poblado con la huella digital del certificado. Esto no ocurre automáticamente; necesita un script o un flujo de trabajo para manejarlo, que normalmente se activa cuando la CA emite un nuevo certificado. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos] Permítame presentarle los tres errores comunes que veo con más frecuencia en las implementaciones 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 implementaciones 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 infraestructura grande, los perfiles pueden tardar de 15 a 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 implementarse y confirmarse antes de aplicar 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 BYOD. Cuando un dispositivo se desvincula de Intune (porque un empleado se va o se pierde un dispositivo), se 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 o el 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 (entornos de pago minorista, por ejemplo), la autenticación 802.1X basada en certificados es su control más sólido para el acceso a redes inalámbricas. Cumple con el Requisito 1.3 de PCI DSS sobre controles de acceso a la red y 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 su evidencia de cumplimiento. Para entornos regulados por el GDPR, particularmente en el sector público y de hospitalidad, la separación entre su red corporativa 802.1X y su red de guest WiFi es crítica. Su red corporativa administrada por Intune debe estar en una VLAN y SSID completamente separados de cualquier red de invitados o visitantes. La plataforma de guest WiFi de Purple maneja el lado del visitante (Captive Portal, captura de consentimiento, analíticas), mientras que su red corporativa administrada por Intune maneja al personal y los dispositivos 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 usar 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, perfil de WiFi) es consistente. ¿Qué pasa con los dispositivos personales en un programa BYOD? SCEP es su aliado aquí. Con las políticas de cumplimiento de dispositivos de Intune, puede requerir 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 eliminará automáticamente. ¿Puede Purple integrarse con esta arquitectura? Absolutamente. La plataforma de Purple se ubica del lado de la red de invitados, manejando la autenticación del Captive Portal, la gestión del consentimiento y las analíticas. La red corporativa 802.1X y el guest WiFi 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 resumir: 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 grupos. Elija SCEP para entornos BYOD y de alta seguridad; PKCS para flotas corporativas más sencillas. Asegúrese de que la secuencia sea la correcta, maneje el requisito de mapeo de certificados NPS y cree un flujo de trabajo de revocación de certificados desde el primer día. El caso de negocio es sencillo: 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 al administrar las credenciales de WiFi en una gran infraestructura.Si estás planeando una implementación y deseas comprender cómo la plataforma de analíticas y WiFi para invitados de Purple se integra con la arquitectura de tu red corporativa, visita 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 de hotelería, retail y el sector público. Gracias por escucharnos. Hasta la próxima.