Problema

Muchas organizaciones están migrando parte de su infraestructura a la nube, pero siguen manteniendo servidores locales para archivos, impresoras y aplicaciones legadas. El desafío surge cuando se necesita una única fuente de autenticación para usuarios y dispositivos que acceden a la red cableada o inalámbrica mediante 802.1X.

En un entorno híbrido aparecen preguntas como:

  • ¿Cómo combinar un controlador de dominio on‑premise con Azure AD/Entra ID sin duplicar políticas?
  • ¿Quién emite los certificados para EAP‑TLS y cómo se distribuyen a laptops, teléfonos y BYOD?
  • ¿Dónde encaja Cisco ISE cuando ya se usa Intune y Entra ID para gestión de dispositivos?
  • ¿Qué protocolos deben estar activos (RADIUS, LDAP, SAML, OAuth) y cómo se sincronizan?

El síntoma típico es una red que funciona parcialmente: los equipos unidos al dominio local se autentican, pero los dispositivos gestionados por Intune no pueden obtener acceso 802.1X, o los APs y switches siguen requiriendo configuraciones manuales de RADIUS que no se actualizan con los cambios de Azure AD.

Causa

  1. División de autoridad de identidad
    AD sigue siendo la autoridad de Kerberos y de los grupos de seguridad locales, mientras que Entra ID gestiona usuarios cloud‑only y políticas de Conditional Access. Sin una capa que unifique ambas fuentes, los servidores RADIUS (NPS o ISE) sólo consultan una de ellas, generando incongruencias.

  2. CA fragmentada
    En muchos laboratorios se mantiene una CA de AD para emitir certificados de máquina. Cuando los dispositivos son enrolados por Intune, la CA on‑premise no recibe la solicitud, por lo que el certificado nunca llega al endpoint móvil.

  3. Falta de sincronización de atributos
    Azure AD Connect replica usuarios y grupos, pero no replica atributos de certificado ni de políticas de red. Los dispositivos que dependen de atributos como msDS-DeviceID para la autorización en ISE quedan sin información.

  4. Configuración de RADIUS aislada
    Cisco ISE y NPS pueden operar simultáneamente, pero si cada uno está configurado con una base de datos distinta, los cambios de grupo en AD no se reflejan en ISE y viceversa. El resultado es que un usuario que se mueve de “Staff” a “Guest” sigue teniendo acceso a recursos críticos.

Solución

1. Arquitectura de referencia

[Device] ──► [Cisco ISE / NPS] ──► [AD Domain Controllers]  
   │                                 ▲  
   │                                 │  
   └─► [Azure AD Connect] ◄─────────┘  
        ▲            │  
        │            ▼  
   [Intune]      [Entra ID]

  • Cisco ISE actúa como punto único de RADIUS. Configura dos Identity Sources:
    – AD (para equipos unidos al dominio y para grupos de seguridad tradicionales).
    – Azure AD / Entra ID mediante el conector Azure AD LDAP que expone los usuarios cloud como objetos LDAP.

  • NPS puede permanecer como respaldo para servicios que solo aceptan Kerberos o para entornos donde ISE no está disponible.

  • Azure AD Connect sincroniza usuarios, grupos y atributos de userPrincipalName. Habilita la opción Password Hash Sync o Pass‑Through Authentication según la política de contraseñas.

  • Intune despliega los certificados de cliente. Usa la CA híbrida (Azure AD Certificate Services o una CA on‑premise expuesta mediante AD CS Web Enrollment). La plantilla de certificado incluye Subject Alternative Name con el UPN del usuario, lo que permite que ISE valide el certificado contra AD o Entra ID.

2. Implementar una CA híbrida

  1. Instala AD CS en un controlador de dominio dedicado.
  2. Publica el servicio mediante IIS con certificado SSL público.
  3. En Azure, crea un Azure AD Application que tenga permiso CertificateAuthority.ReadWrite.All.
  4. Configura Intune → Device Configuration → Certificates → SCEP o PKCS #12 apuntando a la URL pública de la CA.

Los dispositivos reciben automáticamente el certificado al completar el enrolamiento en Intune. La CA on‑premise firma los certificados, pero la publicación pública permite que ISE los valide sin necesidad de túneles VPN.

3. Configurar Cisco ISE para EAP‑TLS con fuentes híbridas

  • Identity Sources → Active Directory: agrega el dominio, habilita “Enable LDAP over SSL (LDAPS)”.
  • Identity Sources → Azure AD (LDAP): usa el conector de Microsoft (Azure AD LDAP) con la URL ldaps://ldap.azure.com.
  • Authentication Policy: crea una regla “EAP‑TLS – AD + Azure AD” que evalúe primero la presencia de certificado válido y luego busque al usuario en AD y, si no existe, en Azure AD.
  • Authorization Policy: asigna VLAN o ACL según los grupos de AD (Network-Admins, Staff, Guest). En Azure AD, usa los Dynamic Groups con la misma nomenclatura para que ISE los reconozca.

4. Flujo de autenticación típico

  1. El dispositivo inicia 802.1X y envía su certificado cliente.
  2. ISE verifica la cadena de confianza contra la CA híbrida.
  3. ISE extrae el UPN del certificado y busca al usuario primero en AD, después en Azure AD vía LDAP.
  4. Si el usuario pertenece a un grupo autorizado, ISE devuelve la autorización (VLAN, ACL).
  5. En caso de fallo, ISE registra el evento en Syslog y envía una alerta a Azure Monitor.

5. Gestión de dispositivos móviles

  • iOS/Android: Intune despliega perfiles Wi‑Fi con EAP‑TLS y referencia al certificado almacenado en el llavero del dispositivo.
  • Windows 10/11: Política de grupo (o MDM) configura el perfil de red con EAP‑TLS y habilita la validación de certificado contra la CA híbrida.

6. Automatización de sincronización de grupos

Utiliza Azure AD PowerShell para replicar grupos críticos de AD a Azure AD:

Connect-AzureAD
$adGroups = Get-ADGroup -Filter 'Name -like "*Network*"'
foreach ($g in $adGroups) {
    New-AzureADGroup -DisplayName $g.Name -MailEnabled $false -SecurityEnabled $true -MailNickname $g.SamAccountName
}

Luego, habilita Dynamic Membership en Azure AD para que los usuarios que tengan el atributo extensionAttribute1 = "Network" se añadan automáticamente al grupo correspondiente. ISE consumirá esos grupos vía LDAP.

Cuándo aplicar esta solución

  • Entornos híbridos con al menos 30 % de dispositivos gestionados por Intune o Azure AD.
  • Redes corporativas que requieren 802.1X en switches y APs y no pueden depender solo de VPN para acceso remoto.
  • Políticas de Zero Trust donde la autenticación de dispositivo y usuario deben estar vinculadas a certificados y a grupos de seguridad.

No es necesario si:

  • Toda la infraestructura está en la nube y no existen controladores de dominio on‑premise.
  • La organización usa exclusivamente WPA2‑Personal o MAC‑based authentication.

Código

# Azure AD Connect sync (full sync)
Start-ADSyncSyncCycle -PolicyType Initial

# Publicar CA Web Enrollment (IIS) - una sola línea para crear el sitio
Import-Module ServerManager
Add-WindowsFeature Web-Server, Web-Common-Http, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Dir-Browsing, Web-Http-Redirect, Web-Health, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Stat-Compression, Web-Dyn-Compression, Web-Filtering, Web-Mgmt-Tools, Web-Mgmt-Console

Verificación

  1. Certificado en dispositivo: abre el administrador de certificados y verifica que el certificado emitido por la CA híbrida tenga el UPN correcto.
  2. Prueba de autenticación: conecta una laptop a la red Wi‑Fi o al puerto de switch configurado para 802.1X. En ISE, revisa la sesión en Live Monitoring → Authentication y confirma que la fuente de identidad sea “AD” o “Azure AD”.
  3. Log de autorización: busca en el syslog del ISE la línea Authorization Granted con el nombre del grupo.
  4. Sincronización de grupos: en Azure Portal, verifica que los grupos dinámicos contengan los mismos miembros que los grupos de AD correspondientes.

Notas adicionales

  • LDAPS: asegúrate de que los puertos 636 estén abiertos entre ISE y los controladores de dominio. Un certificado expirado en el controlador romperá la búsqueda de usuarios.
  • Renovación de certificados: configura la plantilla de certificado con una validez de 1 año y habilita la renovación automática en Intune (RenewalThresholdPercentage = 80).
  • Fallback a NPS: mantén una regla de autorización en NPS que permita acceso a dispositivos que no pueden validar contra ISE (por ejemplo, equipos de laboratorio).
  • Auditoría: habilita Azure AD Sign‑in logs y envíalos a Log Analytics; correlaciona con los logs de ISE para detectar intentos de autenticación fallidos que provengan de credenciales comprometidas.

Con esta arquitectura, la autenticación 802.1X se vuelve una capa única que combina la robustez de AD con la flexibilidad de Entra ID y la gestión de dispositivos de Intune, mientras que Cisco ISE sigue proporcionando la orquestación de políticas de red que los switches y APs necesitan.