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 Un informe de inteligencia de Purple Enterprise WiFi [INTRODUCCIÓN Y CONTEXTO — aproximadamente 1 minuto] Bienvenidos de nuevo. Hoy hablo en nombre de Purple, la plataforma de inteligencia de WiFi empresarial, y este episodio es un informe enfocado en una de las capacidades más prácticas —y, sinceramente, más infravaloradas— del conjunto de herramientas de Microsoft Intune: la implementación automatizada de certificados para la autenticación WiFi 802.1X. Si gestiona el WiFi en un complejo hotelero, una cadena de tiendas, un estadio o un entorno del sector público, conocerá el problema que voy a describir. Tiene cientos o miles de dispositivos gestionados. Quiere que se conecten a su WiFi corporativo de forma automática y segura, sin que los usuarios tengan que introducir contraseñas y sin que el equipo de TI tenga que tocar cada uno de los dispositivos. Y quiere que esa conexión sea criptográficamente sólida, no solo una contraseña compartida que alguien ya ha 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, le 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 el primer intento. [ANÁLISIS TÉCNICO DETALLADO — 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 el pilar de la seguridad WiFi empresarial durante más de dos décadas. Cuando un dispositivo se conecta a su WiFi, el estándar 802.1X requiere que se autentique antes de obtener cualquier acceso a la red. La conversación de autenticación se produce entre tres partes: el dispositivo (llamado suplicante), su punto de acceso WiFi (que actúa como 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 la 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 lo que buscamos. 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 de inscripción de certificados simple) 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 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 servidor NDES), pero la clave privada transita a través del conector, lo cual es un factor a tener en cuenta para su postura de seguridad. Para la mayoría de los despliegues empresariales, recomendaría SCEP para entornos BYOD y de dispositivos mixtos, y PKCS cuando se disponga de una flota homogénea de dispositivos Windows propiedad de la empresa y se desee minimizar la complejidad de la infraestructura. Ahora, hablemos de la secuencia de despliegue, porque el orden importa y equivocarse es la causa más común de fallos en la implementación. 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 Intune de Microsoft ya está disponible de forma generalizada 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: despliegue 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 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: despliegue 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 los certificados de usuario, o el ID de dispositivo de AAD para los 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 propia máquina, lo que significa que el dispositivo puede conectarse a la WiFi antes de que un usuario inicie sesión, algo muy ú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, introduzca 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, el certificado de cliente y los perfiles de WiFi a los mismos grupos de usuarios o dispositivos. Utilice los informes integrados de Intune para supervisar el estado del despliegue de los perfiles. Un despliegue correcto muestra los tres perfiles con el estado Correcto 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 ha endurecido 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é cumplimentado 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 detallar los tres errores más frecuentes que veo en los despliegues empresariales. Primer error: lagunas 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 desplegar tanto la raíz como la intermedia en los dispositivos. He visto despliegues fallar durante semanas porque alguien desplegó la raíz pero no la intermedia. Segundo error: tiempos de asignación de perfiles. Los perfiles de Intune no llegan a los dispositivos de forma instantánea. En un parque de dispositivos grande, los perfiles pueden tardar de 15 a 30 minutos en propagarse tras su 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 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. Tercer error: revocación de certificados BYOD. Cuando un dispositivo se da de baja de Intune (porque un empleado se marcha o porque 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 compruebe 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 normativo: si opera dentro del alcance de PCI DSS (entornos de pago minoristas, 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 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 pruebas de cumplimiento.Para entornos regulados por el GDPR, especialmente en el sector de la hostelería y el sector público, la separación entre su red corporativa 802.1X y su red WiFi de invitados es fundamental. Su red corporativa gestionada por Intune debe estar en una VLAN y un SSID completamente independientes de cualquier red de invitados o visitantes. La plataforma de WiFi de invitados de Purple se encarga de la parte de cara al visitante (Captive Portal, captura de consentimiento, analíticas), mientras que su red corporativa gestionada por Intune se encarga del 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 utilizar Intune Cloud PKI en lugar de ADCS local? Sí. Intune Cloud PKI de Microsoft, lanzado en 2024, proporciona una CA totalmente gestionada en Azure. Elimina el requisito del servidor NDES para SCEP y simplifica significativamente la configuración del conector. Para despliegues desde cero o para organizaciones sin una infraestructura ADCS existente, es la vía recomendada. ¿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 coherente. ¿Qué ocurre 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 unos 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 sitúa en el lado de la red de invitados, gestionando la autenticación del Captive Portal, la gestión del consentimiento y las analíticas. La red corporativa 802.1X y el WiFi de invitados de Purple funcionan en paralelo (misma infraestructura física, diferentes SSIDs y VLANs), lo que le ofrece 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: el despliegue de certificados WiFi a través de Intune es un proceso de cinco pasos: configuración de la CA, despliegue 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 más sencillas propiedad de la empresa. Asegúrese de que la secuencia sea la correcta, gestione el requisito de asignación 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 los costes de TI derivados de la gestión de credenciales de WiFi en un gran parque de dispositivos. Si está planificando un despliegue y desea comprender cómo encaja la plataforma de analítica y WiFi para invitados de Purple junto con la arquitectura de red de su empresa, visite purple.ai. Disponemos de 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 hostelería, comercio minorista y sector público. Gracias por escucharnos. Hasta la próxima.