Despliegue de certificados WiFi de Microsoft Intune mediante SCEP y PKCS

El despliegue de certificados WiFi con Intune utiliza tres perfiles: un certificado raíz de confianza, un certificado de cliente SCEP o PKCS y un perfil WiFi 802.1X configurado en EAP-TLS. Despliéguelos en ese orden, todos asignados al mismo grupo de Microsoft Entra ID. SCEP crea la clave privada en el dispositivo, mientras que PKCS la crea de forma centralizada. Para WiFi en Windows, iOS y Android, elija SCEP.

¿Qué hace realmente el despliegue de certificados WiFi con Intune?

Intune otorga a cada dispositivo gestionado su propia identidad mediante certificado y los ajustes de WiFi para presentarla. De este modo, el dispositivo se conecta a la red de su personal sin que nadie tenga que introducir una contraseña.

El mecanismo es IEEE 802.1X, el estándar para el control de acceso a la red basado en puertos. Bajo 802.1X, el punto de acceso mantiene el dispositivo fuera de la red hasta que un servidor de autenticación lo aprueba. Ese servidor es un servidor RADIUS, el servicio que sus puntos de acceso consultan antes de permitir la entrada a un dispositivo.

El método de autenticación es EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definido en RFC 5216. Ambas partes demuestran su identidad mediante certificados:

• El dispositivo presenta un certificado de cliente.
• El servidor RADIUS presenta un certificado de servidor.
• Cada parte comprueba que el certificado de la otra remite a una autoridad de certificación (CA) en la que confía.

No se introduce, almacena ni expone ninguna contraseña al phishing.

Esto cobra mayor importancia cada año. Microsoft documenta que Windows Defender Credential Guard bloquea el inicio de sesión único para métodos 802.1X basados en contraseña como PEAP-MSCHAPv2. PEAP (Protected EAP) envía una contraseña dentro de un túnel cifrado. Credential Guard está activado de forma predeterminada en las compilaciones recientes de Windows 11 Enterprise, y Microsoft recomienda utilizar autenticación basada en certificados en su lugar.

Intune distribuye la red WiFi basada en certificados a través de tres perfiles de configuración:

• Perfil de certificado de confianza. Instala su CA raíz y cualquier CA intermedia. A continuación, el dispositivo puede confiar en su propia cadena de certificados y en su servidor RADIUS.
• Perfil de certificado SCEP o PKCS. Emite un certificado de cliente único para cada dispositivo.
• Perfil WiFi. Establece el SSID (el nombre de la red emitida), el tipo de seguridad y el método EAP. También nombra el certificado que se debe presentar y el servidor en el que confiar.

Para los operadores de recintos, esta es la parte de la red destinada al personal. Portátiles, dispositivos portátiles y tabletas del personal en sectores como Hoteles, Comercio minorista y Sector sanitario necesitan acceso a sistemas a los que los huéspedes, compradores y pacientes nunca deben acceder. Su solución de Guest WiFi mantiene su Captive Portal, la página de inicio de sesión que ven los visitantes. Los dispositivos del personal se autentican de forma silenciosa en un SSID y una VLAN independientes, un segmento de red aislado lógicamente.

SCEP o PKCS: ¿qué perfil de certificado debería utilizar?

Ambos perfiles instalan un certificado de cliente en el dispositivo. La diferencia radica en dónde se crea la clave privada.

SCEP (Simple Certificate Enrolment Protocol, RFC 8894) hace que el dispositivo genere su propio par de claves. El dispositivo envía una solicitud de firma de certificado a través de un servidor Network Device Enrolment Service (NDES), o a través de Microsoft Cloud PKI. La CA firma la solicitud y devuelve el certificado. La clave privada nunca sale del dispositivo. En Windows, el perfil SCEP puede colocar esa clave en el Trusted Platform Module (TPM), el chip de seguridad por hardware.

Los perfiles PKCS utilizan el Certificate Connector for Microsoft Intune para solicitar el certificado a su CA. El par de claves se crea fuera del dispositivo. A continuación, Intune entrega el certificado y la clave privada al dispositivo de forma encriptada. Se evita la ejecución de NDES, pero la clave privada ha existido en otro lugar que no es el dispositivo.

Un tercer tipo, los certificados importados PKCS, entrega certificados que ya posee. Su función habitual es la encriptación de correo electrónico S/MIME, donde las claves se custodian en un depósito de garantía. Es la herramienta incorrecta para WiFi.

	SCEP a través de NDES y AD CS	SCEP a través de Microsoft Cloud PKI	PKCS a través de conector y AD CS
Dónde se crea la clave privada	En el dispositivo	En el dispositivo	Fuera del dispositivo, luego entregada
Autoridad de certificación	Su CA empresarial de Active Directory Certificate Services (AD CS)	CA alojadas por Microsoft, o su propia raíz	Su CA empresarial de AD CS
Servidores locales que ejecuta	CA, servidor NDES, Certificate Connector	Ninguno	CA, Certificate Connector
Componente orientado a Internet	URL de NDES, publicada a través del proxy de aplicaciones de Microsoft Entra ID	Ninguno: Microsoft aloja el extremo SCEP	Ninguno: el conector solo se conecta de salida
Licencia adicional	Ninguna más allá de Windows Server	Complemento Cloud PKI o Microsoft Intune Suite	Ninguna más allá de Windows Server
Esfuerzo de configuración	El más alto: CA, NDES, conector y publicación de proxy	El más bajo: CA creadas en el centro de administración de Intune	Medio: CA y conector, sin NDES
A quién se adapta	Entornos con AD CS que desean mantener las claves en el dispositivo	Entornos centrados en la nube sin PKI local	Entornos con AD CS que no pueden publicar NDES

Para WiFi, elija SCEP a menos que no pueda satisfacer sus necesidades de infraestructura. Una clave que nunca sale del dispositivo no se puede copiar de un servidor ni interceptar en tránsito. Elija Microsoft Cloud PKI si no tiene una PKI local y no desea construir una. Elija PKCS si ejecuta AD CS pero no puede publicar un extremo NDES en Internet.

¿Qué necesita antes de implementar certificados WiFi con Intune?

Confirme cada elemento antes de crear un solo perfil. La mayoría de las implementaciones fallidas se deben a una carencia en esta lista.

• Licenciamiento. Cada persona necesita una licencia de Intune. Intune está incluido en Microsoft 365 E3, E5 y Business Premium, y en Enterprise Mobility + Security E3 y E5.
• Dispositivos registrados. Los dispositivos Windows se unen a Microsoft Entra ID, a menudo a través de Windows Autopilot. Los dispositivos iOS e iPadOS se inscriben mediante la inscripción automatizada de dispositivos de Apple Business Manager. Los dispositivos Android utilizan Android Enterprise. Microsoft ha dejado de admitir la administración de administradores de dispositivos para dispositivos con Google Mobile Services, por lo que debe planificar su migración a Android Enterprise.
• Una autoridad de certificación. Esto significa una CA empresarial de AD CS, Microsoft Cloud PKI o una CA de terceros compatible con Intune.
• Una plantilla de certificado. En AD CS, publique una plantilla con el uso mejorado de clave Autenticación de cliente.
• Infraestructura de conectores. SCEP en AD CS necesita un servidor NDES y el Certificate Connector para Microsoft Intune. PKCS solo requiere el conector.
• Un servidor RADIUS compatible con EAP-TLS. Su certificado de servidor debe vincularse a una raíz que vaya a implementar. Anote el nombre exacto de ese certificado, ya que el perfil de WiFi lo necesita.
• Revocación accesible. Su servidor RADIUS debe poder acceder a la lista de revocación de certificados (CRL) o a un respondedor OCSP (Protocolo de estado de certificados en línea). Si no puede, la autenticación fallará.
• SSID empresariales. Sus puntos de acceso deben emitir un SSID WPA2-Enterprise o WPA3-Enterprise orientado a su servidor RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet son todos compatibles con 802.1X.
• Grupos de Entra ID. Cree un grupo piloto y un grupo de producción. Decida ahora si incluirán personas o dispositivos.
• Una red de arranque (bootstrap). Un dispositivo necesita acceso a internet para recopilar su certificado antes de poder unirse al SSID 802.1X. Proporcione acceso por cable, datos móviles o un SSID de incorporación aislado. Los operadores de trenes que entregan tabletas al personal de a bordo deben aprovisionarlas en la cochera, antes de que las tabletas salgan a ruta.

¿Cómo se configuran los certificados WiFi SCEP o PKCS en Intune?

La documentación de Intune de Microsoft contiene los pasos detallados campo por campo para cada plataforma. La secuencia y las decisiones a continuación son las que determinan el éxito. Cree un conjunto de perfiles por plataforma: Windows, iOS/iPadOS y Android Enterprise.

Paso 1: implementar el perfil de certificado raíz de confianza

Exporte su certificado CA raíz como un archivo .cer. Cree un perfil de certificado de confianza que lo contenga. Cada perfil de certificado de confianza contiene un solo certificado, por lo que debe crear perfiles independientes para la raíz y para cada CA intermedia.

En Windows, envíe la raíz al almacén de raíces del equipo y las intermedias al almacén intermedio. Si una CA diferente firmó el certificado de su servidor RADIUS, implemente también esa raíz. Sin ella, los dispositivos no podrán validar el servidor.

Paso 2: implementar el perfil de certificado SCEP o PKCS

Comience con el tipo de certificado, ya que de él depende todo lo demás.

• Los certificados de dispositivo son adecuados para dispositivos de mano compartidos, quioscos y portátiles que deben conectarse en la pantalla de inicio de sesión de Windows. Utilice un nombre de sujeto creado a partir del identificador del dispositivo, como CN={{AAD_Device_ID}}.
• Certificados basados en personas: indicados para teléfonos y portátiles asignados a un miembro de la plantilla. Utilice CN={{UserPrincipalName}} en el asunto. Añada el mismo valor como un nombre alternativo del sujeto, ya que muchos servidores RADIUS leen la identidad desde ahí.

A continuación, configure los campos restantes:

• Uso de clave: firma digital y cifrado de clave.
• Uso mejorado de clave: Autenticación de cliente, OID 1.3.6.1.5.5.7.3.2.
• Tamaño de clave: 2048 bits como mínimo.
• Validez: no superior a lo que permita su plantilla de entidad de certificación.
• Umbral de renovación: el valor predeterminado de Microsoft es el 20% del tiempo de vida restante del certificado.
• Certificado raíz: seleccione el perfil de certificado de confianza del paso 1.
• Almacenamiento de claves en Windows: elija la opción TPM para claves respaldadas por hardware.

Para SCEP, introduzca la URL externa de NDES o su URI de SCEP de PKI en la nube. Para PKCS, introduzca el nombre de la entidad de certificación y el nombre de la plantilla en su lugar.

Si utiliza Microsoft NPS (Network Policy Server) con identidades híbridas, consulte el artículo KB5014754 de Microsoft sobre la asignación sólida de certificados. Microsoft documenta un URI de nombre alternativo del sujeto que contiene el identificador de seguridad local exactamente para este caso.

Paso 3: desplegar el perfil de WiFi 802.1X

Cree un perfil de WiFi para empresas con estas configuraciones:

• Introduzca el SSID exactamente como lo emiten sus puntos de acceso.
• Establezca el tipo de seguridad en WPA2-Enterprise, o WPA3-Enterprise cuando sus puntos de acceso y la plataforma lo admitan.
• Establezca el tipo de EAP en EAP-TLS.
• Introduzca nombres de servidor de certificados que coincidan con el nombre del certificado de su servidor RADIUS. Esto evita que los dispositivos entreguen su identidad a un punto de acceso no autorizado.
• Seleccione el perfil del paso 1 como el certificado raíz para la validación del servidor.
• Seleccione el perfil del paso 2 como el certificado de autenticación de cliente.

¿Qué cambia en Windows, iOS y Android?

• Windows se conecta con un certificado de dispositivo antes de que alguien inicie sesión. Un certificado basado en personas solo se conecta tras iniciar sesión, lo que interrumpe el primer inicio de sesión en portátiles compartidos.
• iOS e iPadOS confían en el servidor RADIUS haciendo coincidir los nombres de servidor de certificados que introduzca. Una discrepancia genera un error de confianza, no una alternativa silenciosa.
• Android Enterprise requiere un nombre de dominio de servidor RADIUS y un certificado raíz para la validación. Las versiones recientes de Android han eliminado la opción de omitir la validación del servidor.

¿Qué ocurre cuando se inscribe un nuevo dispositivo?

Esta es la secuencia de despliegue de certificados en un dispositivo recién inscrito:

1. El dispositivo se inscribe y pasa a su grupo asignado en Microsoft Entra ID.
2. Intune entrega los perfiles intermedios y de raíz de confianza.
3. El dispositivo solicita su certificado de cliente. Con SCEP, genera un par de claves y envía una solicitud de firma con un desafío de un solo uso. El conector valida ese desafío con Intune antes de que la entidad de certificación emita nada. Con PKCS, el conector solicita el certificado e Intune lo entrega.
4. El dispositivo notifica el certificado instalado a Intune.
5. Se aplica el perfil de WiFi, que depende de ambos perfiles de certificado.
6. El dispositivo presenta su certificado al SSID. RADIUS valida la cadena, comprueba la revocación y acepta el dispositivo. A continuación, puede asignar una VLAN mediante atributos RADIUS.
7. Intune renueva el certificado cuando alcanza el umbral de renovación. Intune lo revoca cuando retira o borra el dispositivo, siempre que el conector tenga derechos de revocación en la CA.

¿Cómo comprobar si los certificados de WiFi de Intune funcionan correctamente?

Haga una prueba piloto con un grupo de 10 a 20 dispositivos por plataforma antes de ampliar las asignaciones. Revise estos cuatro puntos.

1. Estado del perfil de Intune. Cada uno de los tres perfiles debe figurar como Correcto para todos los dispositivos del grupo piloto. Un estado de Pendiente, Error o No aplicable en cualquiera de ellos bloquea el perfil de WiFi.
2. El propio dispositivo. En Windows, abra el almacén de certificados personales y confirme la finalidad de Autenticación de cliente y su CA emisora. En iOS y Android, confirme que el certificado y el perfil de WiFi aparecen en el perfil de gestión y en las credenciales del perfil de trabajo.
3. Registros de RADIUS. Busque autenticaciones EAP-TLS correctas con el nombre de sujeto esperado. En NPS, el ID de evento 6272 registra el acceso concedido y el 6273 registra el acceso denegado, incluyendo un código de motivo.
4. Registros del conector y de NDES. El Certificate Connector escribe en el registro de eventos de Windows. Las solicitudes NDES aparecen en los registros de IIS.

A continuación, pruebe la revocación intencionadamente. Retire un dispositivo del grupo piloto en Intune y confirme que el certificado aparece como revocado en la CA. Publique la CRL y confirme que RADIUS deniega la siguiente autenticación.

¿Qué errores pueden surgir con los perfiles de WiFi de Intune y cómo solucionarlos?

El perfil de WiFi muestra Error o No aplicable

Los certificados han llegado, pero el perfil de WiFi ha fallado. La causa habitual es la asignación a grupos mixtos. Por ejemplo, si el perfil SCEP está asignado a un grupo de usuarios mientras que el perfil de WiFi se dirige a un grupo de dispositivos, Intune no puede resolver la dependencia. La solución consiste en asignar los tres perfiles al mismo grupo o, al menos, al mismo tipo de grupo.

El certificado SCEP nunca llega

Los registros de IIS de NDES muestran respuestas HTTP 403 o 500. Compruebe que la cuenta de servicio del conector tiene permisos de Lectura e Inscripción en la plantilla de certificado. Verifique que su firewall, proxy inverso o proxy de aplicaciones no esté eliminando las cadenas de consulta SCEP como operation=GetCACaps. A continuación, confirme que la URL externa de NDES se resuelve desde fuera de su red.

El dispositivo tiene un certificado, pero RADIUS lo rechaza

Revise estas cuatro causas por orden:

1. Los nombres de servidor de certificados en el perfil de WiFi no coinciden con el certificado del servidor RADIUS.
2. El servidor RADIUS no confía en la CA que emitió el certificado de cliente.
3. El servidor RADIUS no puede descargar una CRL actualizada.
4. La aplicación del asignado seguro de NPS según la KB5014754 rechaza los certificados sin un asignado seguro.

El código de motivo de NPS le indicará la causa correcta.

Las comprobaciones de revocación provocan una interrupción del servicio

Si el punto de distribución de la CRL queda fuera de línea o la CRL expira, los servidores RADIUS estrictos rechazarán todos los certificados. Publique las CRL en una ubicación HTTP de alta disponibilidad a la que su servidor RADIUS pueda acceder. Monitorice la hora de la próxima actualización de la CRL.

Los dispositivos se siguen conectando a la red antigua

Un perfil PEAP o con clave compartida antiguo que aún permanezca en el dispositivo tiene prioridad. Elimine el perfil antiguo a través de Intune una vez que el nuevo notifique un resultado correcto y, a continuación, retire el SSID antiguo.

¿Cómo funciona el WiFi basado en certificados de Intune en un entorno real?

Los dos escenarios siguientes son ejemplos prácticos basados en el comportamiento documentado de Microsoft. Describen tipos de recintos, no implementaciones con nombres reales.

Un grupo de 12 hoteles que retira una contraseña de personal compartida

Situación. Un grupo de 12 hoteles, de unas 200 habitaciones cada uno, opera un SSID de personal con una clave compartida. La clave la comparten 840 dispositivos: PC de recepción, iPhone de limpieza y terminales de mano Android en restauración. La red está conectada al entorno de datos de tarjetahabientes. Por lo tanto, el requisito 2.3.2 de PCI-DSS v4.0 exige cambiar la clave cada vez que se marcha alguien que la conoce. Con la rotación de personal de atención al público, cada cambio deja dispositivos desconectados hasta que alguien vuelve a introducir la clave.

Qué se hizo. El equipo implementa SCEP a través de NDES, publicado con Microsoft Entra Application Proxy. Los PC de recepción reciben certificados de dispositivo para conectarse en la pantalla de inicio de sesión. Los teléfonos reciben certificados vinculados a personas. Se realiza un piloto con 20 dispositivos en un hotel durante dos semanas. Después de eso, se migra un hotel por semana, manteniendo el SSID antiguo en paralelo.

Resultado medible. Transcurridas 12 semanas, los 840 dispositivos se autentican con EAP-TLS y se desactiva el SSID de la clave compartida. El número de claves compartidas a rotar pasa de una en 12 ubicaciones a cero. El acceso de un empleado saliente finaliza cuando su dispositivo se retira y se vuelve a publicar la CRL, no en la siguiente rotación de claves.

Una cadena minorista de 150 tiendas con terminales de mano compartidos

Situación. Cada tienda utiliza cuatro terminales de mano Android compartidos y dos portátiles de oficina Windows, lo que suma 900 dispositivos en total. Los terminales de mano pasan de un empleado a otro en cada turno, por lo que los certificados basados en personas no tienen sentido. El servicio RADIUS-as-a-Service en la nube de la cadena no puede acceder a una CRL publicada solo en la red interna.

Qué se hizo. La cadena registra los terminales de mano como dispositivos dedicados de Android Enterprise y emite certificados de dispositivo mediante SCEP. Un único perfil WiFi por plataforma da servicio a todas las tiendas, ya que el SSID es idéntico en todas partes. La CRL se traslada a un punto de distribución HTTP accesible desde Internet.

Resultado medible. Ningún terminal de mano compartido almacena una contraseña WiFi. El personal de tienda deja de pedir la clave tras cada cambio. Un terminal de mano perdido se bloquea retirándolo en Intune, y su certificado falla en la siguiente autenticación una vez que se actualiza la CRL.

¿Cuánto cuesta la implementación de certificados WiFi con Intune y qué beneficio se obtiene?

Cuánto cuesta

• Licencias. La mayoría de las organizaciones ya poseen Intune a través de Microsoft 365 o Enterprise Mobility + Security, por lo que no hay un nuevo coste por usuario.
• Servidores. AD CS, NDES y NPS son funciones de Windows Server que no requieren una licencia independiente más allá de Windows Server.
• PKI en la nube. Microsoft Cloud PKI es un complemento de pago, incluido también en Microsoft Intune Suite. Evalúe su coste frente a la creación y el mantenimiento de una CA y NDES locales.
• Esfuerzo. El trabajo se centra en el diseño de PKI, la publicación de NDES y la prueba piloto. La configuración de los tres perfiles lleva horas, no semanas.

Lo que obtiene a cambio

• Sin claves WiFi compartidas. Esto elimina la rotación de claves que el requisito 2.3.2 de PCI-DSS impone a las redes inalámbricas conectadas al entorno de datos de tarjetas de pago.
• Acceso de bajas que puede revocar. Al retirar un dispositivo en Intune se puede revocar su certificado, por lo que el acceso WiFi sigue su proceso de altas, cambios y bajas (JML).
• Compatibilidad con Credential Guard. EAP-TLS sigue funcionando donde Windows bloquea el inicio de sesión único 802.1X basado en contraseñas.
• Sin credenciales que puedan sufrir phishing. Un certificado vinculado a un TPM no se puede introducir en una página de inicio de sesión falsa.
• Sin caducidad de contraseñas. Los certificados se renuevan automáticamente antes de caducar, lo que elimina los restablecimientos de contraseña como causa de incidencias de WiFi.

Planifique el tratamiento del GDPR desde el principio. Los sujetos de los certificados que contienen el nombre de usuario de un empleado son datos personales en sus registros RADIUS. Establezca un periodo de conservación y restrinja el acceso a dichos registros.

Purple ejecuta Staff WiFi y Guest WiFi de forma simultánea en más de 80.000 instalaciones activas (datos de Purple). La plataforma es independiente del hardware en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Purple cuenta con la certificación ISO 27001. Nuestras redes basadas en la identidad funcionan con Microsoft Entra ID, Okta y Google Workspace, por lo que el acceso del personal sigue la misma fuente de identidad que su entorno de Intune. Por parte de los visitantes, WiFi Analytics informa sobre las conexiones de invitados de forma independiente al tráfico del personal.

Preguntas frecuentes

¿Necesita licencias adicionales para implementar certificados WiFi a través de Intune?

No, no para SCEP a través de NDES ni para PKCS. Intune está incluido en Microsoft 365 E3, E5 y Business Premium, así como en Enterprise Mobility + Security E3 y E5. Active Directory Certificate Services y NDES son funciones de Windows Server, por lo que solo necesitan sus licencias existentes de Windows Server. La excepción es Microsoft Cloud PKI, un complemento de pago incluido también en Microsoft Intune Suite. Inclúyalo en el presupuesto solo si desea evitar la ejecución de una CA local.

¿Funcionará la conexión WiFi basada en certificados de Intune con sus puntos de acceso actuales?

Sí, siempre que sus puntos de acceso puedan emitir un SSID WPA2-Enterprise o WPA3-Enterprise. EAP-TLS se ejecuta entre el dispositivo y el servidor RADIUS, y el punto de acceso solo lo retransmite bajo IEEE 802.1X. Purple es independiente del hardware y funciona en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Mantendrá el hardware que ya posee y solo cambiará la configuración de seguridad del SSID.

¿Puede migrar de PEAP o una contraseña compartida a EAP-TLS sin tiempo de inactividad?

Sí. Ejecute el nuevo SSID 802.1X junto al antiguo o configure su servidor RADIUS para que acepte tanto PEAP como EAP-TLS durante la transición. Despliegue primero los tres perfiles de Intune en un grupo piloto. Confirme las autenticaciones EAP-TLS correctas en sus registros RADIUS y, a continuación, amplíe la asignación por fases. Elimine el perfil de WiFi heredado solo después de que el nuevo informe un resultado favorable y, después, retire el antiguo SSID.

¿Debería elegir SCEP o PKCS para el WiFi del personal?

Elija SCEP. Con SCEP, el dispositivo genera su propia clave privada, que nunca sale de él, y Windows puede almacenar esa clave en el TPM. PKCS crea la clave fuera del dispositivo y la entrega. Esto elimina el servidor NDES, pero amplía los lugares en los que la clave ha existido. Elija PKCS solo cuando ejecute Active Directory Certificate Services y no pueda publicar NDES, o utilice Microsoft Cloud PKI para SCEP sin NDES.

¿Sigue necesitando un servidor NDES?

Solo para SCEP con un CA de Active Directory Certificate Services local. Microsoft Cloud PKI proporciona un punto de conexión SCEP alojado, por lo que no necesita ejecutar ningún servidor NDES, conector o CA local. Los perfiles PKCS también evitan NDES, ya que Certificate Connector for Microsoft Intune solicita certificados a su CA a través de conexiones salientes. Las autoridades de certificación de terceros compatibles con Intune también pueden emitir certificados SCEP sin NDES.

¿Con qué rapidez finaliza el acceso WiFi cuando alguien deja la empresa?

Tan rápido como lo permita su proceso de revocación. Cuando retira o borra un dispositivo en Intune, Certificate Connector puede revocar su certificado en su CA. El acceso finaliza cuando su servidor RADIUS detecta esa revocación a través de una CRL actualizada o una comprobación OCSP. Reduzca el intervalo de publicación de la CRL o utilice OCSP si la revocación en la misma hora es prioritaria. Deshabilitar la cuenta por sí solo puede no detener un certificado válido a menos que RADIUS también consulte el directorio.

¿El WiFi basado en certificados ayuda con PCI-DSS y GDPR?

Sí. El requisito 2.3.2 de PCI-DSS v4.0 exige que las claves inalámbricas en las redes conectadas al entorno de datos de tarjetas de pago se cambien cada vez que alguien que las conozca abandone la empresa. Los certificados por dispositivo implican que no existe ninguna clave compartida que rotar. Para GDPR, trate los sujetos de los certificados que contengan el nombre de usuario de un empleado como datos personales. Establezca un periodo de retención para los registros RADIUS, restrinja el acceso a ellos y registre el tratamiento de datos.