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

CÓMO UTILIZAR MICROSOFT INTUNE PARA DISTRIBUIR CERTIFICADOS WIFI A DISPOSITIVOS Un informe de inteligencia de WiFi corporativa de Purple [INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto] Bienvenidos de nuevo. Hoy hablo en nombre de Purple, la plataforma de inteligencia de WiFi corporativa, y este episodio es un informe enfocado en una de las capacidades más prácticas - y sinceramente, más infravaloradas - de la caja 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 patrimonio 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 corporativa de forma automática y segura, sin que los usuarios tengan que introducir contraseñas y sin que el departamento 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 distribució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 en los que caen 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 el estándar IEEE 802.1X, el control de acceso a redes basado en puertos que ha sido el pilar de la seguridad WiFi corporativa 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. El proceso 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 mediante certificados: el dispositivo presenta un certificado para demostrar su identidad y el servidor RADIUS presenta un certificado para demostrar la suya. Sin contraseñas de por medio. Sin credenciales que puedan ser objeto de phishing. Este es nuestro objetivo. El desafío siempre ha sido instalar esos certificados en los dispositivos a gran escala. Ahí es donde entra Microsoft Intune. Intune admite dos mecanismos de distribució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 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, recomiendo SCEP para entornos de BYOD y dispositivos mixtos, y PKCS cuando se dispone de 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 despliegue, porque el orden importa y equivocarse es la causa más común de los fallos en la implementación. 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 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: 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 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 Subject Alternative Name debe incluir el User Principal Name para los certificados de usuario, o el AAD Device ID 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 se 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 dispositivos o usuarios. Utilice los informes integrados de Intune para supervisar el estado del despliegue de los perfiles. Un despliegue correcto muestra los tres perfiles como correctos en la lista de perfiles de configuración del dispositivo. Un punto crítico sobre la configuración de NPS para entornos 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é rellenado con la huella digital del certificado. Esto no ocurre de forma automática - necesita un script o un flujo de trabajo para gestionarlo, normalmente activado cuando la CA emite un nuevo certificado. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos] Permítame detallar los tres errores comunes que veo con más frecuencia 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 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. Segundo error: 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 una comprobación 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. Tercer error: revocación de certificados BYOD. Cuando un dispositivo se desvincula de Intune - ya sea 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 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 en un entorno dentro del alcance de PCI-DSS - por ejemplo, entornos de pago de retail - 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 sus evidencias de cumplimiento. Para entornos regulados por el GDPR, especialmente en la hostelería 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 gestionada 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 de la parte de cara al visitante (el Captive Portal, la captura de consentimiento y la analítica), mientras que su red corporativa gestionada por Intune se encarga del personal y de 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 rápidamente 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 considerablemente la configuración del conector. Para despliegues nuevos o empresas que no dispongan de una infraestructura ADCS existente, es el camino recomendado. ¿Funciona esto para dispositivos macOS e iOS? Sí. Intune admite perfiles de certificado 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 coherente. ¿Qué pasa con los dispositivos personales en un programa BYOD? SCEP es su mejor 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 los requisitos (sin bloqueo de pantalla, sistema operativo desactualizado, etc.), el certificado puede revocarse y el acceso a la red se retirará 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 la analítica. 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 total 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 de 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 BYOD y entornos 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 argumento empresarial 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 indirectos de TI que supone gestionar las 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 su red corporativa, visite purple.ai. Disponemos de guías detalladas sobre la integración con Microsoft Entra ID, la arquitectura 802.1X y el diseño de redes de invitados para entornos de hostelería, retail y sector público. Gracias por escucharnos. Hasta la próxima.