Despliegue de certificados WiFi de Microsoft Intune a través de SCEP y PKCS

La implementación de certificados WiFi de 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. Impleméntelos en ese orden, todos asignados al mismo grupo de Microsoft Entra ID. SCEP crea la llave privada en el dispositivo, mientras que PKCS la crea de forma centralizada. Para WiFi en Windows, iOS y Android, elija SCEP.

¿Qué hace realmente la implementación de certificados WiFi de Intune?

Intune le otorga a cada dispositivo administrado su propia identidad de certificado y los ajustes de WiFi para presentarla. Luego, el dispositivo se conecta a la red de su personal sin que nadie tenga que escribir 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 al dispositivo fuera de la red hasta que un servidor de autenticación lo apruebe. Ese servidor es un servidor RADIUS, el servicio que sus puntos de acceso consultan antes de permitir la entrada de un dispositivo.

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

• El dispositivo presenta un certificado de cliente.
• El servidor RADIUS presenta un certificado de servidor.
• Cada lado verifica que la cadena del certificado del otro corresponda a una autoridad certificadora (CA) en la que confía.

No se escribe, 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 los métodos 802.1X basados en contraseñas, como PEAP-MSCHAPv2. PEAP (Protected EAP) envía una contraseña dentro de un túnel cifrado. Credential Guard está activado por defecto en las versiones recientes de Windows 11 Enterprise, y Microsoft recomienda la autenticación basada en certificados en su lugar.

Intune ofrece 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. El dispositivo puede entonces confiar en su propia cadena de certificados y en su servidor RADIUS.
• Perfil de certificado SCEP o PKCS. Emite a cada dispositivo un certificado de cliente único.
• Perfil WiFi. Configura el SSID (el nombre de la red transmitida), el tipo de seguridad y el método EAP. También nombra el certificado que se presentará y el servidor en el que se debe confiar.

Para los operadores de inmuebles, este es el lado de la red destinado al personal. Las computadoras portátiles, dispositivos portátiles y tabletas del personal en Hotels, Retail y Healthcare necesitan acceso a sistemas que los huéspedes, compradores y pacientes nunca deben alcanzar. Su Guest WiFi conserva 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 debe utilizar?

Ambos perfiles dejan un certificado de cliente en el dispositivo. La diferencia radica en dónde se crea la llave 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 mediante 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 de 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. Intune entrega entonces 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 usted ya posee. Su función habitual es el cifrado de correo electrónico S/MIME, donde las claves se custodian. Es la herramienta incorrecta para WiFi.

	SCEP mediante NDES y AD CS	SCEP mediante Microsoft Cloud PKI	PKCS mediante conector y AD CS
Dónde se crea la clave privada	En el dispositivo	En el dispositivo	Fuera del dispositivo, luego se entrega
Autoridad de certificación	Su CA empresarial Active Directory Certificate Services (AD CS)	CAs alojadas por Microsoft, o su propia raíz	Su CA empresarial AD CS
Servidores locales que opera	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 punto final SCEP	Ninguno: el conector solo se conecta de forma saliente
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: CAs 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 orientados a 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 desde 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 opera AD CS pero no puede publicar un punto final NDES a 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 omisión 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 inscritos. Los dispositivos Windows están unidos a Microsoft Entra ID, a menudo a través de Windows Autopilot. Los dispositivos iOS e iPadOS se inscriben a través de la inscripción automatizada de dispositivos de Apple Business Manager. Los dispositivos Android utilizan Android Enterprise. Microsoft ha finalizado la administración del administrador de dispositivos para dispositivos con Google Mobile Services, por lo que debe planificar con 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 extendido de clave de autenticación de cliente.
• Infraestructura de conectores. SCEP en AD CS necesita un servidor NDES y el Certificate Connector para Microsoft Intune. PKCS solo necesita el conector.
• Un servidor RADIUS compatible con EAP-TLS. Su certificado de servidor debe vincularse a una raíz que implementará. Registre el nombre exacto en ese certificado, porque el perfil de WiFi lo necesita.
• Revocación accesible. Su servidor RADIUS debe alcanzar la lista de revocación de certificados (CRL) o 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 apuntado 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 usuarios 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 emiten tabletas al personal de a bordo deben aprovisionarlas en el depósito, 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 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 de 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 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, porque determina todo lo demás.

• Certificados de dispositivo. Se adaptan a dispositivos compartidos, quioscos y computadoras 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}}.
• Los certificados basados en personas son ideales para teléfonos y laptops asignados a un miembro específico del personal. Utilice CN={{UserPrincipalName}} en el asunto. Agregue el mismo valor como un nombre alternativo del sujeto, ya que muchos servidores RADIUS leen la identidad desde ahí.

Luego configure los campos restantes:

• Uso de clave: firma digital y cifrado de clave.
• Uso extendido de clave: Client Authentication, OID 1.3.6.1.5.5.7.3.2.
• Tamaño de clave: 2048 bits como mínimo.
• Validez: no mayor a lo que permite su plantilla de CA.
• 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, ingrese la URL externa de NDES o su URI de SCEP de Cloud PKI. Para PKCS, ingrese el nombre de la CA y el nombre de la plantilla en su lugar.

Si utiliza Microsoft NPS (Network Policy Server) con identidades híbridas, lea el artículo KB5014754 de Microsoft sobre el mapeo seguro de certificados. Microsoft documenta una URI de nombre alternativo del sujeto que porta el identificador de seguridad local exactamente para este caso.

Paso 3: implementar el perfil de WiFi 802.1X

Cree un perfil de WiFi empresarial con los siguientes ajustes:

• Ingrese el SSID exactamente como lo transmiten sus puntos de acceso.
• Configure el tipo de seguridad como WPA2-Enterprise, o WPA3-Enterprise donde sus puntos de acceso y la plataforma lo admitan.
• Configure el tipo de EAP como EAP-TLS.
• Ingrese nombres de servidor de certificado que coincidan con el nombre en su certificado de 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 entre Windows, iOS y Android?

• Windows se conecta con un certificado de dispositivo antes de que alguien inicie sesión. Un certificado basado en persona se conecta solo después del inicio de sesión, lo que interrumpe el primer inicio de sesión en laptops compartidas.
• iOS y iPadOS confían en el servidor RADIUS al coincidir los nombres de servidor de certificado que ingrese. Un error de coincidencia genera un fallo 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 eliminaron la opción de omitir la validación del servidor.

¿Qué sucede cuando se inscribe un nuevo dispositivo?

Esta es la secuencia de implementación del certificado en un dispositivo recién inscrito:

1. El dispositivo se inscribe y queda ubicado en su grupo asignado de Entra ID.
2. Intune entrega los perfiles de certificado raíz e intermedio de confianza.
3. El dispositivo solicita su certificado de cliente. Bajo SCEP, genera un par de claves y envía una solicitud de firma con un desafío de un solo uso. El conector valida dicho desafío con Intune antes de que la CA emita algo. Bajo PKCS, el conector solicita el certificado e Intune lo entrega.
4. El dispositivo reporta el certificado instalado a Intune.
5. El perfil de WiFi, que depende de ambos perfiles de certificado, se aplica.
6. El dispositivo presenta su certificado al SSID. RADIUS valida la cadena, verifica la revocación y acepta el dispositivo. Luego puede asignar una VLAN a través de atributos RADIUS.
7. Intune renueva el certificado cuando alcanza el umbral de renovación. Intune lo revoca cuando retira o limpia el dispositivo, siempre que el conector tenga derechos de revocación en la CA.

¿Cómo verificar que los certificados de WiFi de Intune están funcionando?

Pruebe con un piloto de 10 a 20 dispositivos por plataforma antes de ampliar las asignaciones. Revise cuatro lugares.

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

Luego, pruebe la revocación intencionalmente. Retire un dispositivo piloto en Intune y confirme que el certificado aparezca como revocado en la CA. Publique la CRL y confirme que RADIUS deniegue la siguiente autenticación.

¿Qué sale mal con los perfiles de WiFi de Intune y cómo solucionarlo?

El perfil de WiFi muestra Error o No aplicable

Los certificados llegaron, pero el perfil de WiFi falló. La causa habitual es la asignación a grupos mixtos. Por ejemplo, el perfil SCEP está asignado a un grupo de personas mientras que el perfil de WiFi se dirige a un grupo de dispositivos. Intune no puede resolver la dependencia. La solución es 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. Verifique que la cuenta de servicio del conector tenga permisos de Lectura e Inscripción en la plantilla de certificado. Verifique que su firewall, proxy inverso o proxy de aplicaciones no esté eliminando cadenas de consulta SCEP como operation=GetCACaps. Luego confirme que la URL externa de NDES se resuelva desde fuera de su red.

El dispositivo tiene un certificado, pero RADIUS lo rechaza

Analice cuatro causas en 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 actual.
4. La aplicación del mapeo seguro de NPS bajo KB5014754 rechaza certificados sin un mapeo seguro.

El código de motivo de NPS señala la causa correcta.

Las comprobaciones de revocación causan 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 rechazan todos los certificados. Publique las CRL en una ubicación HTTP de alta disponibilidad a la que su servidor RADIUS pueda acceder. Monitoree el tiempo de la próxima actualización de la CRL.

Los dispositivos se siguen conectando a la red anterior

Una clave precompartida heredada o un perfil PEAP que aún permanezca en el dispositivo tendrá prioridad. Elimine el perfil antiguo a través de Intune una vez que el nuevo informe un estado exitoso, y luego retire el SSID anterior.

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

Los dos escenarios a continuación son ejemplos prácticos basados en el comportamiento documentado de Microsoft. Describen tipos de recintos, no implementaciones con nombres específicos.

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

Situación. Un grupo de 12 hoteles, cada uno con alrededor de 200 habitaciones, opera un SSID para el personal con una clave precompartida. La clave se comparte entre 840 dispositivos: PC de recepción, iPhones de personal de limpieza y dispositivos portátiles Android en alimentos y bebidas. La red está conectada al entorno de datos de cuentahabientes. Por lo tanto, el requisito 2.3.2 de PCI-DSS v4.0 exige cambiar la clave cada vez que una persona que la conoce deja la empresa. Con la rotación de personal en recepción, cada cambio deja dispositivos desconectados hasta que alguien vuelve a ingresar la clave.

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

Resultado medible. Después de 12 semanas, los 840 dispositivos se autentican con EAP-TLS y el SSID con clave precompartida se desactiva. El número de claves compartidas a rotar se reduce de una en 12 sitios a cero. El acceso de una persona que deja la empresa ahora termina cuando su dispositivo se retira y la CRL se vuelve a publicar, no en la siguiente rotación de claves.

Una cadena comercial de 150 tiendas con dispositivos portátiles compartidos

Situación. Cada tienda opera cuatro dispositivos portátiles Android compartidos y dos laptops Windows en la oficina posterior, 900 dispositivos en total. Los dispositivos portátiles se transfieren entre el personal en cada turno, por lo que los certificados basados en personas no tienen sentido. El servicio RADIUS en la nube de la cadena no puede acceder a una CRL publicada únicamente en la red interna.

Qué se hizo. La cadena registra los dispositivos portátiles como dispositivos dedicados de Android Enterprise y emite certificados de dispositivo a través de SCEP. Un solo perfil de WiFi por plataforma atiende a todas las tiendas, ya que el SSID es idéntico en todas partes. La CRL se mueve a un punto de distribución HTTP accesible por internet.

Resultado medible. Ningún dispositivo portátil compartido almacena una contraseña de WiFi. El personal de la tienda deja de pedir la clave después de cada cambio. Un dispositivo portátil perdido se desconecta al retirarlo en Intune, y su certificado falla en la siguiente autenticación una vez que la CRL se actualiza.

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

Lo que cuesta

• Licencias. La mayoría de las empresas ya cuentan con Intune a través de Microsoft 365 o Enterprise Mobility + Security, por lo que no hay un nuevo costo por usuario.
• Servidores. AD CS, NDES y NPS son roles 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, también incluido en Microsoft Intune Suite. Evalúe su costo frente a la creación y el mantenimiento de una CA y NDES local.
• Esfuerzo. El trabajo se centra en el diseño de PKI, la publicación de NDES y la prueba piloto. Los tres perfiles toman 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 expempleados que puede revocar. Al desincorporar un dispositivo en Intune se puede revocar su certificado, por lo que el acceso a la red 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 ser objeto de phishing. Un certificado vinculado a un TPM no se puede ingresar en una página de inicio de sesión falsa.
• Sin vencimiento de contraseñas. Los certificados se renuevan automáticamente antes de vencer, lo que elimina el restablecimiento de contraseñas como causa de tickets de soporte de WiFi.

Planifique el manejo del GDPR desde el principio. Los sujetos del certificado que contienen el nombre de usuario de un empleado son datos personales en sus registros RADIUS. Establezca un período de retención y restrinja el acceso a esos registros.

Purple opera WiFi para personal y WiFi para invitados simultáneamente en más de 80,000 sedes activas (datos de Purple). La plataforma es independiente del hardware y funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks y Fortinet. Purple cuenta con la certificación ISO 27001. Nuestras redes basadas en 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 el lado de los visitantes, WiFi Analytics genera informes 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, y en Enterprise Mobility + Security E3 y E5. Active Directory Certificate Services y NDES son roles de Windows Server, por lo que solo requieren su licenciamiento existente de Windows Server. La excepción es Microsoft Cloud PKI, un complemento de pago que también se incluye en Microsoft Intune Suite. Presupuestelo únicamente si desea evitar la operación de una CA en sus instalaciones.

¿Funcionará el acceso WiFi basado en certificados de Intune con sus puntos de acceso actuales?

Sí, siempre que sus puntos de acceso puedan transmitir 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 Networks y Fortinet. Conserve el hardware que ya posee y cambie únicamente 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 anterior, o configure su servidor RADIUS para aceptar tanto PEAP como EAP-TLS durante la transición. Implemente primero los tres perfiles de Intune en un grupo piloto. Confirme las autenticaciones EAP-TLS exitosas en sus registros de RADIUS y, luego, amplíe la asignación por fases. Elimine el perfil de WiFi heredado únicamente después de que el nuevo reporte éxito y, a continuación, retire el SSID anterior.

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

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

¿Aún necesita un servidor NDES?

Solo para SCEP con una CA de Active Directory Certificate Services local. Microsoft Cloud PKI proporciona un endpoint SCEP alojado, por lo que no necesita ejecutar ningún servidor NDES, conector ni CA local. Los perfiles PKCS también evitan NDES, porque el Certificate Connector para 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.

¿Qué tan rápido finaliza el acceso a 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, el 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 verificación OCSP. Acorte el intervalo de publicación de la CRL, o use OCSP, si la eliminación en la misma hora es importante. Deshabilitar la cuenta por sí solo puede no detener un certificado válido a menos que RADIUS también verifique 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 cuentahabientes cambien cada vez que alguien que las conozca deje la empresa. Los certificados por dispositivo significan que no existe una clave compartida que rotar. Para GDPR, trate los sujetos de certificados que contengan el nombre de inicio de sesión de un colaborador como datos personales. Establezca un período de retención para los registros de RADIUS, restrinja el acceso a ellos y registre el procesamiento.