Cómo configurar SCEP para el registro automatizado de certificados WiFi empresariales
Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi empresariales, cubriendo toda la arquitectura desde PKI y NDES hasta el despliegue de perfiles MDM y la validación RADIUS. Está dirigida a directores de TI, arquitectos de red y directores de tecnología de hoteles, cadenas de retail, estadios, centros de conferencias y organizaciones del sector público que necesitan ir más allá de las claves precompartidas e implementar una autenticación scalable 802.1X EAP-TLS basada en la identidad. La plataforma de superposición en la nube de Purple, que es independiente del hardware, se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que coexiste con la red del personal autenticada por certificado.
Video overview
Escuchar esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de seguridad de WiFi empresarial →
Resumen ejecutivo
Para espacios empresariales - ya sea un hotel de 200 habitaciones, una cadena de tiendas con 50 ubicaciones o un gran centro de conferencias - depender de claves precompartidas para el WiFi de los empleados es un riesgo de seguridad y un cuello de botella operativo. Una sola contraseña filtrada expone toda la red. La autenticación basada en certificados a través de IEEE 802.1X y EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina por completo ese riesgo. Cada dispositivo demuestra su identidad de forma criptográfica antes de que el punto de acceso le conceda acceso a la red.
El desafío radica en la distribución. Implementar manualmente certificados de cliente exclusivos en miles de dispositivos Windows, iOS y Android no es viable. El SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 por la IETF en 2020, resuelve este problema. Automatiza el proceso de solicitud, emisión e instalación de certificados digitales en dispositivos gestionados a través de su plataforma MDM - sin ninguna interacción del usuario.
Esta guía abarca toda la arquitectura: qué hace el SCEP, cómo se integra con Microsoft Intune, Jamf y otras plataformas MDM, la secuencia exacta de implementación que la mayoría de los equipos realiza de forma incorrecta y los problemas operativos que causan interrupciones del servicio. También analizamos dos escenarios reales de implementación en hostelería y retail, y explicamos dónde encaja la plataforma de Guest WiFi de Purple junto a su red de empleados autenticada por certificado.
Escuche el podcast informativo complementario:
Análise técnica detalhada: SCEP, PKI e 802.1X
O que o SCEP realmente faz
O SCEP não substitui a sua Public Key Infrastructure (PKI). É a camada de registo automatizada que se posiciona sobre ela. A sua PKI - normalmente uma hierarquia de dois níveis com uma CA raiz offline e uma CA emissora online - continua a ser a âncora de confiança. O SCEP automatiza a etapa em que um dispositivo solicita um certificado a essa CA, eliminando a necessidade de geração manual de CSR e instalação de certificados.
No contexto da autenticação WiFi, o protocolo de destino é o EAP-TLS. Este é o método de autenticação 802.1X que exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados X.509 válidos. Nenhuma das partes confia na outra sem prova criptográfica. Esse modelo de autenticação mútua elimina o roubo de credenciais e protege contra ataques de "evil twin", em que um atacante cria um ponto de acesso falso para recolher nomes de utilizador e palavras-passe.
Para uma análise detalhada do handshake EAP-TLS, consulte o nosso guia sobre WiFi Certificate Authentication: Secure Network Access.
O fluxo de registo SCEP, passo a passo
A cadeia de registo completa funciona da seguinte forma. A sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerido. Esse payload contém duas coisas: o URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado.
O dispositivo gera o seu próprio par de chaves pública e privada localmente. Esta é a propriedade de segurança crítica do SCEP: a chave privada é gerada no dispositivo, armazenada no enclave seguro ou chip TPM, e nunca é transmitida pela rede. O dispositivo cria então um Certificate Signing Request (CSR) e envia-o para o gateway SCEP. O gateway valida a palavra-passe de desafio, encaminha o CSR para a sua Autoridade de Certificação (CA), e a CA assina-o e devolve o certificado público ao dispositivo.
A partir desse momento, quando o dispositivo se liga ao seu SSID de WiFi, apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua cadeia de confiança da CA, verifica a Lista de Revogação de Certificados (CRL) para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o utilizador.
SCEP vs. PKCS: qual utilizar para WiFi
Las plataformas MDM como Intune admiten dos mecanismos de entrega de certificados: SCEP y PKCS (Public Key Cryptography Standards). La diferencia arquitectónica es significativa.
Con SCEP, la clave privada se genera en el dispositivo y nunca sale de él. Con PKCS, la Autoridad de Certificación genera la clave pública y la privada de forma centralizada, y el conector de certificados envía el par de claves al dispositivo a través de la red. Esto significa que la clave privada se transmite, lo que introduce una superficie de ataque teórica.
PKCS es adecuado para casos de uso en los que se requiere la custodia de claves, como el cifrado de correo electrónico S/MIME. Para la autenticación WiFi, SCEP es la opción correcta. La clave privada permanece en el dispositivo.
| Propiedad | SCEP | PKCS |
|---|---|---|
| Generación de clave privada | En el dispositivo (TPM/Secure Enclave) | Centralizada (CA) |
| Transmisión de clave privada | Nunca | A través de la red |
| Servidor NDES requerido | Sí (o gateway en la nube) | No |
| Recomendado para WiFi | Sí | No |
| Recomendado para S/MIME | No | Sí |
Compatibilidad de hardware
SCEP y EAP-TLS son estándares independientes del proveedor. Funcionan en puntos de acceso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Su configuración RADIUS - ya sea Windows NPS, FreeRADIUS o un servicio RADIUS-as-a-Service - es donde se define la política de validación de certificados y la asignación dinámica de VLAN.
La asignación dinámica de VLAN es la forma en que se segmenta la red a través de la identidad del dispositivo. Un dispositivo de un empleado recibe la VLAN 10 con acceso a sistemas internos. El dispositivo de un contratista recibe la VLAN 20 solo con acceso a internet. Un terminal de punto de venta recibe la VLAN 30 solo con acceso a sistemas de procesamiento de pagos. Todo esto se gestiona mediante atributos de certificado y la política RADIUS, sin ninguna intervención manual por dispositivo.
Para obtener más información sobre cómo se integra el análisis de datos de red con la segmentación de red basada en la identidad, consulte nuestra descripción general de la plataforma de analytics en WiFi Analytics.
Guia de implementación: la secuencia de despliegue
La configuración exitosa de SCEP para WiFi empresarial requiere el cumplimiento estricto de una secuencia de despliegue específica. Las plataformas MDM imponen dependencias de perfil: un perfil de WiFi que hace referencia a un certificado SCEP no se puede aplicar hasta que dicho certificado exista en el dispositivo. La violación de esta secuencia es la causa más común de fallos en la implementación.
La secuencia es: primero la Raíz de Confianza (Trusted Root), segundo el perfil SCEP, tercero el perfil WiFi. Este orden no es negociable.
Paso 1: implementar el perfil de Certificado de Raíz de Confianza (Trusted Root)
Antes de que cualquier dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, debe confiar en la Autoridad de Certificación (CA) emisora. Exporte su certificado de CA Raíz - y cualquier certificado de CA Intermedia - como archivos .cer. En su centro de administración MDM, cree un perfil de Certificado de Confianza, cargue el archivo .cer y despliéguelo en su grupo de dispositivos de destino.
Si tiene una jerarquía PKI de dos niveles (recomendado), debe desplegar tanto el certificado de la CA raíz como el de la CA emisora como perfiles de Certificado de Confianza independientes, o como una cadena en un único perfil, dependiendo de su plataforma MDM.
Paso 2: configurar el perfil de Certificado SCEP
Una vez establecida la confianza, configure el perfil SCEP para indicar a los dispositivos cómo obtener su certificado de cliente.
Cree un nuevo perfil de configuración y seleccione el tipo de perfil de certificado SCEP. Configure el formato del Nombre del Sujeto (Subject name). Para la autenticación basada en el usuario, CN={{UserPrincipalName}} es el estándar. Para la autenticación de dispositivos (dispositivos compartidos, IoT, terminales POS), utilice CN={{AAD_Device_ID}}. Establezca el Uso de la clave (Key usage) para Firma digital y Cifrado de clave. Establezca el Uso de Clave Extendida (Extended Key Usage) para Autenticación de Cliente (OID: 1.3.6.1.5.5.7.3.2). Vincule este perfil al perfil de certificado de Raíz de Confianza creado en el Paso 1. Proporcione la URL externa de su servidor NDES. Para el caso específico de Microsoft Intune, el servidor NDES debe publicarse a través del proxy de aplicaciones de Azure AD para permitir que los dispositivos remotos se registren antes de conectarse en local. No exponga el NDES directamente a internet.
Paso 3: implementar el perfil de WiFi 802.1X
El paso final consiste en enviar la configuración de WiFi que asocia los certificados al SSID de la red. Cree un perfil de configuración de WiFi. Introduzca el Nombre de la red (SSID) exactamente igual a como lo transmiten sus puntos de acceso. Seleccione WPA2 o WPA3 como el tipo de seguridad. Establezca el tipo de EAP en EAP-TLS. En los ajustes de autenticación, seleccione el perfil de certificado SCEP creado en el Paso 2 como el certificado de autenticación de cliente. Especifique el certificado Trusted Root para la validación del servidor; esto garantiza que el dispositivo solo se conecte a su servidor RADIUS legítimo y no a un punto de acceso no autorizado.
Integración del proveedor de identidad
Los atributos del certificado SCEP - específicamente el Subject Alternative Name (SAN) - pueden contener el nombre principal del usuario de Microsoft Entra ID, Okta o Google Workspace. Esto asocia el certificado a una identidad específica. Cuando desactiva una cuenta en Entra ID y el MDM elimina el registro del dispositivo, el certificado se revoca y el acceso al WiFi se corta automáticamente. Esta revocación automatizada es la historia de seguridad que las claves precompartidas no pueden igualar.
Para saber más sobre EAP Method WiFi: A Guide to Secure Network Access, incluidos los caminos de migración PEAP-MSCHAPv2, consulte nuestra guía dedicada.
-
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.
Buenas prácticas y estándares del sector
Ubicación del servidor NDES
El servidor NDES debe estar accesible desde internet para que los dispositivos se puedan registrar antes de llegar a las instalaciones. Publique la URL del NDES a través de Azure AD Application Proxy. Esto proporciona un acceso remoto seguro sin abrir puertos de firewall de entrada y le permite aplicar políticas de Acceso Condicional al flujo de registro. Nunca exponga el NDES directamente a internet.
Para redes con más de 500 dispositivos gestionados, considere una pasarela SCEP en la nube en lugar de un NDES local. Las pasarelas en la nube eliminan el punto único de fallo del NDES, escalan horizontalmente y, normalmente, se integran directamente con servicios RADIUS en la nube.
Disponibilidad de la CRL
Su servidor RADIUS verifica la Lista de Revocación de Certificados (CRL) cada vez que un dispositivo se autentica. Si su Punto de Distribución de CRL (CDP) no está disponible - porque un servidor está caído o la URL ha cambiado - la autenticación falla para todos los dispositivos de la red simultáneamente. Configure su servidor NPS o RADIUS para imponer una verificación estricta de la CRL y haga que sus endpoints de CRL sean altamente disponibles. Pruebe la revocación antes de entrar en producción.
El Requisito 8.6 de PCI-DSS 4.0 exige autenticación multifactor en la capa de red para entornos de datos de titulares de tarjetas. El EAP-TLS con certificados provistos por SCEP satisface este requisito para redes inalámbricas en entornos de Retail y Hospitality.
Compatibilidad con WPA3
El EAP-TLS es totalmente compatible con WPA3-Enterprise. WPA3-Enterprise con la suite de seguridad de 192 bits (Suite B) exige EAP-TLS y es la combinación recomendada por la Wi-Fi Alliance para redes gubernamentales, financieras y de salud. Si está realizando la implementación en entornos de Saúde o Transportes con requisitos de cumplimiento estrictos, WPA3-Enterprise con EAP-TLS es la arquitectura de destino correcta.
BYOD y WiFi de invitados
SCEP requiere la inscripción en el MDM para enviar el payload del certificado. No cubre dispositivos BYOD no gestionados o de invitados. Para esos casos de uso, necesita un SSID independiente con un Captive Portal y verificación de identidad. La plataforma de Purple gestiona esa capa de forma limpia, coexistiendo con su red de empleados autenticada por certificado. Nuestra plataforma de Guest WiFi admite opciones de participación consciente, captura de datos de primera mano (first-party) e integración con Microsoft Entra ID, Okta y Google Workspace para la verificación de identidad.
-
Resolución de problemas y mitigación de riesgos
Fallo en la aplicación del perfil de WiFi
Síntoma: El dispositivo recibe los certificados Trusted Root y SCEP, pero el perfil de WiFi se muestra como Error o No Aplicable en el MDM.
Causa raíz: Incompatibilidad de segmentación de grupo. Si el perfil SCEP está dirigido a un grupo de Usuarios y el perfil de WiFi está dirigido a un grupo de Dispositivos, el MDM no puede resolver la dependencia.
Solución: Audite sus asignaciones. Asegúrese de que los perfiles Trusted Root, SCEP y WiFi estén dirigidos exactamente al mismo grupo de directorio.
Errores NDES 403 Forbidden
Síntoma: Los dispositivos no pueden obtener el certificado SCEP. Los registros de IIS de NDES muestran errores HTTP 403.
Causa raíz: La cuenta de servicio del MDM Certificate Connector no tiene permisos de Lectura e Inscripción (Read and Enroll) en la plantilla de certificado, o el filtrado de URLs del firewall está bloqueando los parámetros de query string de SCEP.
Solución: Verifique que la cuenta del conector tenga permisos de Lectura e Inscripción en la plantilla de la CA. Revise los registros del firewall para asegurarse de que las URLs que contienen ?operation=GetCACaps no estén bloqueadas.
Fallo de autenticación masiva tras la expiración de la CRL
Síntoma: Todos los dispositivos de la red fallan en la autenticación de forma simultánea.
Causa raíz: La CRL ha expirado o la URL del CDP no está accesible. El servidor RADIUS no puede confirmar si los certificados son válidos y falla por defecto (fails closed).
Solución: Configure la monitorización y las alertas de CRL. Publique las CRL con un periodo de validez significativamente superior al intervalo de publicación. Pruebe la accesibilidad del CDP desde el servidor RADIUS antes del lanzamiento.
Expiración de certificado causando fallos silenciosos
Síntoma: Dispositivos individuales fallan en la conexión de forma intermitente, sin un patrón claro.
Causa raíz: Los certificados de cliente han expirado y el MDM no los ha renovado correctamente.
Solución: Configure la renovación del certificado para que se active al 80% de la vida útil del certificado. Monitorice los informes de estado de inscripción del MDM para detectar dispositivos con errores de certificado. Defina periodos de validez de certificado adecuados para el ciclo de actualización de sus dispositivos; por lo general, de uno a dos años para endpoints gestionados.
-
ROI e impacto empresarial
La transición a la autenticación por certificado 802.1X basada en SCEP proporciona retornos mensurables en términos de seguridad, operaciones y cumplimiento.
Reducción de tickets de soporte: El WiFi basado en contraseña genera un volumen significativo de tickets de soporte - expiración de contraseñas, bloqueos y errores de escritura. La autenticación basada en certificado es invisible para el usuario. Las organizaciones registran típicamente una reducción del 70-80% en el volumen de soporte relacionado con WiFi tras la migración.
Postura de seguridad: El EAP-TLS elimina la recopilación de credenciales y los ataques Man-in-the-Middle. Esto respalda directamente el cumplimiento de la norma PCI-DSS 4.0 para redes de retail y hostelería, así como los requisitos del Artículo 32 del GDPR para medidas técnicas de seguridad adecuadas.
Revocación automatizada: Cuando un empleado deja la empresa, la desactivación de su cuenta en Microsoft Entra ID activa la revocación automática del certificado y la desvinculación del MDM. El acceso al WiFi se corta sin ninguna intervención manual por parte del equipo de red.
Segmentación de red: La asignación dinámica de VLAN a través de atributos de certificado RADIUS le ofrece una segmentación de red aplicada de forma criptográfica. Los dispositivos entran en el segmento de red correcto según las propiedades del certificado, y no por la selección de SSID o el filtrado de direcciones MAC - ambos fácilmente eludibles.
Purple opera en más de 80.000 ubicaciones activas con un 99,999% de tiempo de actividad, y nuestra plataforma cuenta con las certificaciones ISO 27001, GDPR, CCPA y Cyber Essentials. Nuestra capa de red en la nube agnóstica de hardware se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet - para que su red de empleados autenticada por certificado y nuestra capa de WiFi de invitados funcionen desde la misma infraestructura.
Para obtener más información sobre cómo la analítica de comportamiento (Behavioral Analytics: Insights for WiFi Networks) puede complementar su implementación de red segura, consulte nuestra guía de analítica.
Referencias
[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council
Definiciones clave
SCEP (Simple Certificate Enrollment Protocol)
Un protocolo formalizado en RFC 8894 que permite a los dispositivos gestionados solicitar y recibir automáticamente certificados digitales X.509 de una Entidad de Certificación a través de HTTP, utilizando una contraseña de desafío compartida para la autenticación inicial. La clave privada se genera en el dispositivo y nunca se transmite.
El mecanismo estándar utilizado por plataformas MDM como Microsoft Intune y Jamf para desplegar certificados de autenticación WiFi en endpoints gestionados a escala.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
El método de autenticación 802.1X más seguro, que requiere tanto al dispositivo cliente como al servidor RADIUS presentar certificados X.509 válidos. La autenticación mutua significa que ninguna de las partes confía en la otra sin una prueba criptográfica.
El protocolo de autenticación de destino para WiFi empresarial. Obligatorio o fuertemente recomendado por PCI-DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) y HIPAA para redes inalámbricas que manejan datos sensibles.
NDES (Network Device Enrollment Service)
Un rol de Microsoft Windows Server que actúa como una Autoridad de Registro (RA) entre dispositivos compatibles con SCEP y una Entidad de Certificación. Valida las contraseñas de desafío y reenvía las CSR a la CA en nombre de los dispositivos que carecen de credenciales de dominio.
Infraestructura requerida para el despliegue de SCEP con Microsoft Intune. Debe publicarse a través de Azure AD Application Proxy en lugar de exponerse directamente a internet.
PKI (Public Key Infrastructure)
La jerarquía de Entidades de Certificación, políticas y procedimientos utilizados para emitir, gestionar y revocar certificados digitales. Una PKI de dos niveles consta de una CA raíz fuera de línea (el ancla de confianza maestra) y una CA emisora en línea (que gestiona la emisión diaria de certificados).
El prerrequisito no negociable para el despliegue de EAP-TLS y SCEP. La CA raíz debe mantenerse aislada (air-gapped); su clave privada es la base de toda su cadena de confianza de certificados.
CSR (Certificate Signing Request)
Un mensaje generado por un dispositivo que contiene su clave pública e información de identidad, enviado a una Entidad de Certificación para solicitar un certificado digital firmado. En SCEP, la CSR se genera en el dispositivo y se envuelve en un sobre PKCS antes de la transmisión.
Generada automáticamente por el dispositivo durante el flujo de inscripción SCEP. La clave privada utilizada para firmar la CSR nunca sale del dispositivo.
CRL (Certificate Revocation List)
Una lista publicada por la Entidad de Certificación que contiene los números de serie de los certificados que han sido revocados antes de su fecha de caducidad. Los servidores RADIUS comprueban la CRL en cada intento de autenticación para garantizar que los certificados revocados no puedan acceder a la red.
La disponibilidad del punto de distribución de la CRL (CDP) es fundamental. Si el servidor RADIUS no puede acceder a la CRL, se bloquea por seguridad y deniega toda autenticación, lo que provoca una caída de toda la red.
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona autenticación, autorización y contabilidad (AAA) centralizadas para el acceso a la red. En redes WiFi con 802.1X, el servidor RADIUS valida los certificados de los clientes, comprueba la CRL y devuelve un mensaje Access-Accept o Access-Reject al punto de acceso.
El servidor de autenticación en el modelo suplicante-autenticador-servidor de 802.1X. Las implementaciones habituales incluyen Windows NPS, FreeRADIUS y servicios RADIUS en la nube.
Asignación dinámica de VLAN
Una función de RADIUS que sitúa un dispositivo autenticado en una VLAN específica en función de los atributos del certificado o de la pertenencia a un grupo del directorio, en lugar de depender de la selección de SSID o del filtrado de direcciones MAC. Aplica la segmentación de red por identidad de dispositivo.
Permite que un único SSID sirva a múltiples tipos de dispositivos con diferentes niveles de acceso a la red. Un dispositivo de un empleado obtiene la VLAN 10 (acceso interno); el de un contratista obtiene la VLAN 20 (solo internet); un terminal de punto de venta obtiene la VLAN 30 (solo sistemas de pago).
MDM (Mobile Device Management)
Software utilizado por los equipos de TI para registrar, configurar, proteger y gestionar teléfonos inteligentes, tabletas y ordenadores portátiles. Las plataformas MDM como Microsoft Intune y Jamf utilizan perfiles SCEP para enviar instrucciones de registro de certificados a los dispositivos gestionados sin interacción del usuario.
El requisito previo para el despliegue de certificados basado en SCEP. Los dispositivos deben estar registrados en el MDM antes de poder recibir perfiles SCEP y de WiFi. Los dispositivos BYOD no gestionados requieren un enfoque de registro independiente.
Ejemplos prácticos
Un hotel Premier Inn de 200 habitaciones necesita proteger su WiFi de personal para las tablets de punto de venta y los smartphones del servicio de limpieza. Actualmente utilizan una clave precompartida que se ha filtrado a contratistas externos. Gestionan los dispositivos a través de Microsoft Intune y disponen de una combinación de dispositivos iOS y Android. El establecimiento utiliza puntos de acceso HPE Aruba.
- Desplegar una PKI interna de dos niveles de Microsoft AD CS. Configurar NDES en un Windows Server dedicado y publicarlo a través de Azure AD Application Proxy.
- En Intune, crear un perfil de Certificado de Entidad de Certificación Raíz de Confianza que contenga los certificados de la CA raíz y la CA emisora. Desplegarlo en un grupo de Azure AD llamado "Dispositivos del personal del establecimiento".
- Crear un perfil de Certificado SCEP en Intune que apunte a la URL externa de NDES. Configurar el formato del nombre de sujeto como CN={{AAD_Device_ID}}, ya que se trata de dispositivos compartidos. Establecer el uso de clave en Firma Digital y Cifrado de Clave, y el uso extendido de clave en Autenticación de Cliente. Desplegarlo en "Dispositivos del personal del establecimiento".
- Crear un perfil de WiFi para el SSID del personal, configurando WPA2-Enterprise y EAP-TLS. Seleccionar el perfil SCEP para la autenticación del cliente y la CA raíz para la validación del servidor. Desplegarlo en "Dispositivos del personal del establecimiento".
- Configurar los ajustes de RADIUS de HPE Aruba para que apunten a Windows NPS. En NPS, configurar una política de red que requiera EAP-TLS y asigne la VLAN 10 para los dispositivos del personal.
- Una vez que los dispositivos reciban los perfiles y se conecten correctamente, renovar la PSK en el antiguo SSID y programar su retirada del servicio.
Una cadena de retail con 50 ubicaciones desea desplegar 802.1X para portátiles corporativos en todos sus centros. Utilizan puntos de acceso Cisco Meraki y Microsoft Intune. No desean desplegar ni mantener servidores NDES locales o infraestructura de AD CS en cada ubicación ni en su centro de datos.
- Implemente un servicio de puerta de enlace SCEP y PKI basado en la nube que se integre con Intune a través del protocolo SCEP. La CA de la nube emite certificados; la puerta de enlace SCEP de la nube gestiona la validación de la CSR.
- Configure el servicio RADIUS de la nube (proporcionado por el proveedor de PKI) dentro del panel de Cisco Meraki en Wireless > Access Control para el SSID corporativo. Establezca la seguridad en WPA2-Enterprise y dirija el RADIUS al servicio de la nube.
- En Intune, cree un perfil de Certificado raíz de confianza que contenga el certificado raíz de la CA de la nube. Despliegue en el grupo de dispositivos "Corporate Laptops".
- Cree un perfil de certificado SCEP que apunte a la URL de la puerta de enlace SCEP de la nube. Establezca el Nombre del sujeto en CN={{UserPrincipalName}} para la autenticación basada en usuarios. Despliegue en "Corporate Laptops".
- Cree un perfil de WiFi para el SSID corporativo con EAP-TLS, haciendo referencia al perfil SCEP y a la raíz de la CA de la nube. Despliegue en "Corporate Laptops".
- Cuando los portátiles se inscriben en Intune, solicitan automáticamente certificados a la CA de la nube a través de la puerta de enlace SCEP de la nube. No se requiere infraestructura local en ninguna de las 50 ubicaciones.
Preguntas de práctica
Q1. Su organización está migrando de PEAP-MSCHAPv2 a EAP-TLS. Ha desplegado correctamente los perfiles de raíz de confianza y SCEP en su grupo de Azure AD 'Corporate Users' en Intune. Despliega el perfil de WiFi en 'All Corporate Devices'. Los usuarios informan de que no pueden conectarse y el perfil de WiFi aparece como No aplicable.
Sugerencia: Compruebe las dependencias de los perfiles y las reglas de asignación de grupos. Intune resuelve las dependencias de los perfiles en función del grupo asignado.
Ver respuesta modelo
El problema se debe a un error de asignación de grupos. El perfil de WiFi depende del perfil SCEP, que se asignó a un grupo de usuarios ('Corporate Users'). El perfil de WiFi se asignó a un grupo de dispositivos ('All Corporate Devices'). Intune no puede resolver la dependencia entre diferentes tipos de grupos. La solución consiste en cambiar las tres asignaciones de perfiles - raíz de confianza, SCEP y WiFi - para que se dirijan al mismo grupo. Decida si va a utilizar un grupo de usuarios o un grupo de dispositivos en función de su modelo de autenticación (basado en usuarios frente a basado en dispositivos) y aplíquelo de forma coherente en los tres perfiles.
Q2. Una auditoría de seguridad revela que cuando se rescinde el contrato de un empleado y se deshabilita su cuenta de Microsoft Entra ID, su teléfono inteligente corporativo todavía puede conectarse a la red WiFi del personal hasta una semana después del despido.
Sugerencia: Piense en cómo determina el servidor RADIUS si un certificado sigue siendo válido una vez que la cuenta se ha deshabilitado. ¿Cuál es el mecanismo para comunicar el estado de revocación?
Ver respuesta modelo
El servidor RADIUS no está realizando una comprobación estricta de la Lista de Revocación de Certificados, o bien la CRL se publica de forma poco frecuente. Cuando se rescinde el contrato de un empleado, el MDM debería desvincular el dispositivo y la CA debería revocar el certificado. Sin embargo, si el servidor RADIUS no comprueba la CRL en cada intento de autenticación, o si la CRL solo se publica semanalmente, el certificado revocado se sigue aceptando. La solución implica tres pasos: configurar el servidor RADIUS para aplicar una comprobación estricta de la CRL en cada autenticación; configurar la CA para publicar la CRL con un intervalo más corto (diario o más frecuente); y garantizar que el MDM esté configurado para activar la revocación del certificado cuando se desvincule un dispositivo.
Q3. Debe proporcionar acceso WiFi seguro para dispositivos IoT sin pantalla (termostatos inteligentes, reproductores de señalización digital) que no pueden ejecutar un agente MDM ni mostrar un Captive Portal. ¿Puede utilizar SCEP para estos dispositivos? Si no es así, ¿cuál es la alternativa recomendada?
Sugerencia: Considere los requisitos previos para el registro SCEP y qué alternativas existen para los dispositivos que no se pueden registrar en un MDM o que no pueden interactuar con un navegador.
Ver respuesta modelo
No se puede utilizar SCEP para estos dispositivos. SCEP requiere un agente MDM para recibir la URL de registro y la contraseña de desafío, generar el par de claves e instalar el certificado resultante. Los dispositivos IoT sin pantalla que no pueden ejecutar un agente MDM no pueden participar en el flujo de registro de SCEP. Las alternativas recomendadas son: (1) MAC Authentication Bypass (MAB) combinado con una segmentación estricta de VLAN - el servidor RADIUS permite el dispositivo en función de su dirección MAC y lo ubica en una VLAN de IoT aislada sin acceso a los sistemas corporativos; (2) si el dispositivo lo admite, EST (Enrolment over Secure Transport, RFC 7030) puede aprovisionar certificados en dispositivos que admiten HTTPS pero no MDM; (3) para dispositivos con una interfaz de gestión, algunos proveedores admiten el registro SCEP directamente a través del firmware del dispositivo sin necesidad de un agente MDM. En cualquier caso, los dispositivos IoT deben aislarse en una VLAN dedicada independientemente del método de autenticación utilizado.
Continúe leyendo esta serie
Cómo segmentar de forma segura las redes WiFi de empleados y de invitados: mejores prácticas para LAN empresariales
Esta guía proporciona a los directores de TI y arquitectos de red un modelo técnico e independiente del proveedor para proteger las LAN empresariales mediante la segmentación correcta del tráfico de las redes WiFi de empleados e invitados. Abarca la autenticación 802.1X, RADIUS en la nube, el aislamiento de VLAN y la gestión del ciclo de vida de las credenciales necesaria para eliminar las contraseñas compartidas y proteger los activos corporativos.
La mejor filtración DNS: una guía completa para empresas
Esta guía de referencia técnica explica cómo la filtración DNS empresarial protege las redes públicas al bloquear dominios maliciosos en la capa de resolución - antes de que se establezca una conexión. Proporciona a los directores de TI, arquitectos de redes y equipos de operaciones de las instalaciones la arquitectura de despliegue, la configuración del firewall y el contexto de cumplimiento normativo que necesitan para proteger el WiFi de invitados en entornos de hostelería, comercio minorista y sector público. Purple Shield bloquea el malware, las botnets y el contenido inapropiado a nivel de DNS en más de 80.000 instalaciones activas.
Comprensión de Cisco SUDI: Identidad con Anclaje por Hardware en el Control de Acceso Seguro a la Red
Esta guía explica cómo Cisco SUDI proporciona una identidad con anclaje por hardware y criptográficamente segura para la infraestructura de red empresarial. Aprenda a sustituir las direcciones MAC suplantables por certificados 802.1AR inmutables para proteger el control de acceso a la red de su recinto.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.