Introducción a Identity Service Engine y Active Directory

Introducción

Este documento describe cómo Identity Service Engine (ISE) y Active Directory (AD) se comunican, los protocolos que se utilizan, los filtros de AD y los flujos.

---

Prerequisites

Requirements

Cisco recomienda que tenga conocimientos básicos sobre:

• Autenticación de identidad externa en ISE
• ISE 2.x e integración de Active Directory

---

Componentes Utilizados

• ISE 2.x 
• Windows Server (Active Directory) 

---

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

---

Protocolos AD

Protocolo Kerberos  

Los tres jefes de Kerberos incluyen el Centro de distribución de claves (KDC), el usuario cliente y el servidor al que se va a acceder. El KDC se instala como parte del controlador de dominio (DC) y realiza dos funciones de servicio: El Servicio de autenticación (AS) y el Servicio de concesión de notificaciones (TGS).

---

Cuando el cliente accede inicialmente a un recurso del servidor, se realizan tres intercambios:

1. AS Exchange
2. TGS Exchange
3. Intercambio cliente/servidor (CS)

---

---

• Controlador de dominio = KDC (AS + TGS)
• Autentique a AS (el portal de SSO) con su contraseña
• Obtener un vale para la concesión de un vale (TGT) (una cookie de sesión)
• Solicitud de conexión a un servicio (SRV01)
• SRV01 le redirige a KDC
• Show TGT to KDC - (Ya estoy autenticado)
• KDC le ofrece TGS para SRV01
• Redirigir a SRV01
• Muestra el vale de servicio para SRV01
• SRV01 comprueba/confía en el vale de servicio
• El ticket de servicio tiene toda mi información
• El SRV01 me conecta

---

Cuando inician sesión inicialmente en una red, los usuarios deben negociar el acceso y proporcionar un nombre de inicio de sesión y una contraseña para que los verifique la parte de AS de un KDC dentro de su dominio. El KDC tiene acceso a la información de cuenta de usuario de Active Directory. Una vez autenticado, se concede al usuario un vale de concesión de vale (TGT) válido para el dominio local. El TGT tiene una duración predeterminada de 10 horas y se renueva durante la sesión de inicio de sesión del usuario sin que este tenga que volver a introducir la contraseña. El TGT se almacena en la memoria caché de la máquina local en el espacio de memoria volátil y se utiliza para solicitar sesiones con servicios en toda la red.

---

El usuario presenta el TGT a la parte TGS del KDC cuando se necesita acceso a un servicio de servidor. El TGS en el KDC autentica al usuario TGT y crea un ticket y una clave de sesión tanto para el cliente como para el servidor remoto. Esta información (el vale de servicio) se almacena localmente en la memoria caché del equipo cliente. El TGS recibe el cliente TGT y lee con su propia clave. Si el TGS aprueba la solicitud del cliente, se genera un ticket de servicio tanto para el cliente como para el servidor de destino. El cliente lee su parte con la clave de sesión TGS recuperada anteriormente de la respuesta AS. El cliente presenta la parte del servidor de la respuesta de TGS al servidor de destino en el siguiente intercambio cliente/servidor.

---

Ejemplo:

---

Capturas de paquetes de ISE para un usuario autenticado:

---

AS-REQ contiene el nombre de usuario. Si la contraseña es correcta, el servicio AS proporciona una TGT cifrada con la contraseña del usuario. A continuación, se proporciona al TGT el servicio TGT para recibir un vale de sesión. La autenticación se realiza correctamente cuando se recibe un vale de sesión.

---

Este es un ejemplo donde la contraseña dada por el cliente es incorrecta:

---

Si la contraseña es incorrecta, la solicitud de AS falla y no se recibe el TGT:

---

En el siguiente ejemplo, estos son registros en el archivo ad_agent.log cuando la contraseña es incorrecta:

2020-01-14 13:36:05,442 DEBUG ,140574072981248,krb5: Solicitud enviada (276 bytes) a RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Error recibido de KDC: -1765328360/Error de autenticación previa,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Preauth tryagain input types: 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 ADVERTENCIA,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] Código de error KRB5: -1765328360 (Mensaje: Error en la autenticación previa),LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892

2020-01-14 13:36:05,444 DEBUG ,140574072981248,[LwKrb5InitializeUserLoginCredentials()] Código de error: 40022 (símbolo: LW_ERROR_PASSWORD_MISMATCH),LwKrb5InitializeUserLoginCredentials(),lwadvapi/threaded/lwkrb5.c:1453

---

Protocolo MS-RPC

ISE utiliza MS-RPC sobre SMB, y SMB proporciona la autenticación y no requiere una sesión independiente para encontrar dónde se encuentra un servicio RPC determinado. Utiliza un mecanismo llamado "named pipe" para comunicarse entre el cliente y el servidor.

---

• Crear una conexión de sesión SMB
• Transporte de mensajes RPC a través del puerto SMB/CIFS.TCP 445 como transporte 
• La sesión SMB identifica qué puerto ejecuta un servicio RPC determinado y gestiona la autenticación de usuario
• Conectar a recurso compartido oculto IPC$ para la comunicación entre procesos
• Abra una canalización con nombre adecuada para el recurso/función RPC deseado
• Transacción del intercambio RPC a través de SMB

---

---

La línea negotiate protocol request/response negocia el dialecto de SMB y la session setup request/response realiza la autenticación. La solicitud y la respuesta de conexión de árbol se conectan al recurso solicitado. Está conectado a un recurso compartido especial IPC$. Este recurso compartido de comunicación entre procesos proporciona los medios de comunicación entre los hosts y también como transporte para las funciones de MSRPC.

---

El paquete 77 es el Create Request File y el nombre del archivo es el nombre del servicio conectado (el servicio de inicio de sesión de red en este ejemplo).

Los paquetes 83 y 86 son la solicitud NetLogonSamLogonEX, que consiste en enviar el nombre de usuario para la autenticación del cliente en ISE al AD en el campo Network_INFO. El paquete de respuesta NetLogonSamLogonEX responde con los resultados.

---

Algunos valores de indicadores para la respuesta NetLogonSamLogonEX:

0xc000006a es STATUS_WRONG_PASSWORD
0x00000000 es STATUS_SUCCESS
0x00000103 es STATUS_PENDING

---

Integración de ISE con Active Directory (AD)

ISE utiliza LDAP, KRB y MSRBC para comunicarse con AD durante el proceso de unión/ausencia y autenticación. Las siguientes secciones proporcionan los protocolos, el formato de búsqueda y los mecanismos utilizados para conectarse a un DC específico en AD y la autenticación de usuario en ese DC. Si el DC se desconecta por cualquier motivo, ISE conmuta por error al siguiente DC disponible y el proceso de autenticación no se ve afectado.

---

Un servidor de catálogo global (GC) es un controlador de dominio que almacena copias de todos los objetos de Active Directory del bosque. Almacena una copia completa de todos los objetos del directorio del dominio y una copia parcial de todos los objetos de todos los demás dominios de bosque. El catálogo global permite a los usuarios y las aplicaciones buscar objetos en cualquier dominio del bosque actual con una búsqueda de atributos incluidos en el GC. El catálogo global contiene un conjunto básico (pero incompleto) de atributos para cada objeto de bosque de cada dominio (juego de atributos parcial, PAT).

GC recibe datos de todas las particiones de directorio de dominio del bosque y se copian con el servicio de replicación de AD estándar.

---

Incorporación de ISE a AD

Prerrequisitos de las integraciones de Active Directory e ISE.

1. Compruebe que dispone de privilegios de superadministrador o administrador del sistema en ISE.
2. Utilice la configuración del servidor de protocolo de tiempo de la red (NTP) para sincronizar la hora entre el servidor de Cisco y Active Directory. La diferencia de tiempo máxima permitida entre ISE y AD es de 5 minutos.
3. El DNS configurado en ISE debe responder a las consultas de SRV para DC, GC y KDC con o sin información adicional del sitio.
4. Asegúrese de que todos los servidores DNS puedan responder a consultas DNS inversas y de reenvío para cualquier dominio DNS de Active Directory posible.
5. AD debe tener al menos un servidor de catálogo global operativo y accesible para Cisco, para el dominio al que planea unirse con Cisco.

---

Unirse al dominio AD

ISE aplica la detección de dominios para obtener información sobre el dominio de unión en tres fases:

1. Consulta dominios unidos: detecta dominios de su bosque y dominios de confianza externa para el dominio unido.
2. Consulta los dominios raíz de su bosque: establece confianza con el bosque.
3. Consulta dominios raíz en bosques de confianza: detecta dominios de los bosques de confianza.

Además, Cisco ISE detecta nombres de dominio DNS (sufijos UPN), sufijos UPN alternativos y nombres de dominio NTLM.

---

ISE aplica una detección de DC para obtener toda la información sobre los DC y GC disponibles.

1. El proceso de unión comienza con las credenciales de entrada de un superadministrador en AD que existen en el propio dominio. Si existe en un dominio o subdominio diferente, el nombre de usuario debe indicarse en una notación UPN (username@domain).
2. ISE envía una consulta DNS para todos los registros de DC, GC y KDC. Si la respuesta DNS no recibe una respuesta, la integración falla con un error relacionado con DNS.
3. ISE utiliza el ping CLDAP para detectar todos los DC y GC a través de las solicitudes CLDAP enviadas a los DC que corresponden a sus prioridades en el registro SRV. Se utiliza la primera respuesta de DC e ISE se conecta a ese DC.

Un factor utilizado para calcular la prioridad DC es el tiempo que tarda el DC en responder a los pings CLDAP; una respuesta más rápida recibe una prioridad más alta.

---

---

4. ISE recibe TGT con las credenciales de 'usuario de unión'.
5. Genere el nombre de cuenta del equipo ISE con el MSRPC (SAM y SPN).
6. Busque AD por SPN si la cuenta del equipo ISE ya existe. Si el equipo ISE no existe, ISE crea uno nuevo.
7. Abra la cuenta de equipo, establezca la contraseña de la cuenta de equipo ISE y compruebe que se puede acceder a la cuenta de equipo ISE.
8. Establezca los atributos de cuenta de la máquina ISE (SPN, dnsHostname, etc.).
9. Reciba TGT con credenciales de equipo ISE con KRB5 y descubra todos los dominios de confianza.
10. Una vez completada la unión, el nodo ISE actualiza sus grupos AD y los SID asociados e inicia automáticamente el proceso de actualización de SID. Verifique que este proceso pueda completarse en el lado de AD.

---

Abandonar dominio AD

Cuando ISE abandona, el AD debe tener en cuenta lo siguiente:

1. Utilice un usuario administrador de AD completo para realizar los procesos de abandono. Esto verifica que la cuenta del equipo ISE se haya eliminado de la base de datos de Active Directory.
2. Si AD se queda sin credenciales, la cuenta de ISE no se elimina de AD y debe eliminarse manualmente.
3. Cuando se restablece la configuración de ISE desde la CLI o se restaura la configuración después de una copia de seguridad o actualización, se realiza una operación de ausencia y se desconecta el nodo de ISE del dominio de Active Directory. Sin embargo, si se une, la cuenta de nodo de ISE no se elimina del dominio de Active Directory.
4. Se recomienda realizar una operación de ausencia desde el portal de administración con las credenciales de Active Directory, ya que también quita la cuenta de nodo del dominio de Active Directory. Esto también se recomienda cuando cambia el nombre de host de ISE.

---

DC Failover

Cuando el DC conectado a ISE se desconecta o se vuelve inalcanzable por cualquier motivo, la conmutación por fallo del DC se activa automáticamente en ISE. La conmutación por fallo del DC se puede activar en las siguientes condiciones:

1. El conector AD detecta que el DC seleccionado actualmente no estaba disponible durante algún intento de comunicación CLDAP, LDAP, RPC o Kerberos. En estos casos, el conector AD inicia la selección de DC y conmuta por error al DC recién seleccionado.
2. El DC está activo y responde al ping CLDAP; sin embargo, el conector AD no puede comunicarse con él por alguna razón (por ejemplo, el puerto RPC está bloqueado, el DC está en estado de "replicación interrumpida", el DC no se ha retirado correctamente).

---

En estos casos, el conector de AD inicia la selección de DC con una lista bloqueada ("malo" DC se coloca en la lista bloqueada) e intenta comunicarse con el DC seleccionado. El DC seleccionado en la lista de bloqueados no se almacena en caché.

El conector AD debe completar la conmutación por error en un período de tiempo razonable (o fallar si no es posible). Por esta razón, el conector de AD intenta un número limitado de DC durante la conmutación por fallas. ISE bloquea los controladores de dominio de AD si hay un error irrecuperable de red o de servidor para evitar que ISE use un DC incorrecto. El DC no se agrega a la lista de bloqueados si no responde a los pings CLDAP. ISE solo reduce la prioridad del DC si no responde.

---

Comunicación de ISE-AD a través de LDAP

ISE busca un equipo o usuario en AD con uno de estos formatos de búsqueda. Si la búsqueda fue para un equipo, ISE agrega "$" al final del nombre del equipo. Esta es una lista de tipos de identidad que se utiliza para identificar a un usuario en AD:

---

• Nombre SAM: Nombre de usuario o nombre de equipo sin ningún marcado de dominio, este es el nombre de inicio de sesión del usuario en AD. Ejemplo: sajeda o sajeda$

• CN: Este es el nombre para mostrar del usuario en AD; no debe ser igual que el SAM. Ejemplo: sajeda Ahmed

• Nombre principal de usuario (UPN): Se trata de una combinación del nombre SAM y el nombre de dominio (SAM_NAME@domian). Ejemplo: sajeda@cisco.com o sajeda$@cisco.com

• UPN alternativo: Se trata de sufijos UPN adicionales o alternativos que se configuran en AD con excepción del nombre de dominio. Esta configuración se agrega globalmente en AD (no se configura por usuario) y no es necesario para ser un sufijo de nombre de dominio real.
  • Cada AD puede tener varios sufijos UPN (@alt1.com,@alt2.com, etc.). Por ejemplo, UPN principal (sajeda@cisco.com), UPN alternativo :sajeda@domain1, sajeda@domain2

• Nombre con prefijo NetBIOS: Este es el nombre de dominio/nombre de usuario del nombre de equipo. Por ejemplo, CISCO\sajeda o CISCO\equipo$

• Host/prefijo con una máquina no calificada: Esto se utiliza para la autenticación de máquina cuando el nombre de máquina sólo se utiliza y es el nombre de máquina/host solamente. Por ejemplo, host/máquina.

• Host/Prefijo con Máquina Completamente Calificada: Se utiliza para la autenticación de equipo cuando se utiliza el FQDN de equipo, normalmente en el caso de la autenticación de certificados. Es el host/FQDN de la máquina. Por ejemplo, host/machine.cisco.com.

• Nombre de SPN: El nombre que un cliente identifica de forma exclusiva a una instancia de un servicio (por ejemplo, HTTP, LDAP, SSH) que se utiliza sólo para el equipo.

---

Autenticación de usuario frente al flujo de AD:

1. Resolver identidad y determinar tipo de identidad: SAM, UPN, SPN. Si ISE recibe la identidad solo como nombre de usuario, busca una cuenta SAM asociada en AD. Si ISE recibe la identidad como un username@domain, busca un UPN o correo coincidente en AD. En ambos casos, ISE utiliza filtros adicionales para el equipo o un nombre de usuario. 
2. Busque el dominio o el bosque (en función del tipo de identidad).
3. Conservar información sobre todas las cuentas asociadas (JP, DN, UPN, dominio).
4. Si no se encuentra ninguna cuenta asociada, AD responde con un usuario desconocido.
5. Realice la autenticación MS-RPC (o Kerberos) para cada cuenta asociada.
6. Si sólo una cuenta coincide con la identidad y la contraseña introducidas, la autenticación es correcta.
7. Si varias cuentas coinciden con la identidad entrante, ISE utiliza la contraseña para resolver la ambigüedad, y la cuenta con una contraseña asociada se autentica mientras que las otras cuentas aumentan el contador de contraseñas incorrectas en 1.
8. Si ninguna cuenta coincide con la identidad y la contraseña entrantes, AD responde con una contraseña incorrecta.

---

Filtros de búsqueda de ISE

Los filtros se utilizan para identificar una entidad para comunicarse con AD. ISE siempre busca una entidad en el grupo de usuarios y equipos. Ejemplos de filtros de búsqueda:

1. Búsqueda SAM: Si ISE recibe una identidad como nombre de usuario únicamente sin ninguna marca de dominio, trata el nombre de usuario como un SAM y busca en AD todos los usuarios o equipos que tengan la identidad como un nombre SAM.
2. Si el nombre SAM no es único, ISE utiliza la contraseña para diferenciar entre usuarios e ISE está configurado para utilizar un protocolo sin contraseña como EAP-TLS.
3. No existen otros criterios para localizar el usuario correcto, por lo que ISE no supera la autenticación y se produce un error de "identidad ambigua". Sin embargo, si el certificado de usuario está presente en Active Directory, Cisco ISE utiliza una comparación binaria para resolver la identidad.

---

---

2. Búsqueda de UPN o MAIL: Si ISE recibe una identidad como username@domain, ISE busca una coincidencia con la identidad de UPN o la identidad de correo "identity=match UPN or email" en el catálogo global de bosque. Si existe una coincidencia única, Cisco ISE continúa con el flujo AAA. Si hay varios puntos de unión con el mismo UPN y una contraseña, o el mismo UPN y correo, Cisco ISE falla la autenticación con un error de "identidad ambigua".

---

---

3. Búsqueda de NetBIOS: Si ISE recibe una identidad con un prefijo de dominio NetBIOS (por ejemplo, CISCO\sajedah), ISE busca el dominio NetBIOS en los bosques. Una vez encontrado, busca el nombre SAM proporcionado (sajeda por ejemplo).

---

---

4. Búsqueda de base de máquina: Si ISE recibe una autenticación de equipo con una identidad de host/prefijo, ISE busca en el bosque un atributo servicePrincipalName coincidente. Si se ha especificado un sufijo de dominio completo en la identidad, como host/machine.domain.com. Cisco ISE busca en el bosque donde existe el dominio. Si la identidad se encuentra en forma de host/máquina, Cisco ISE busca el nombre principal del servicio en todos los bosques. Si hay más de una coincidencia, Cisco ISE falla la autenticación con un error de "identidad ambigua".

---

Nota: Se ven los mismos filtros en los archivos ad-agent.log de ISE.

Nota: parche 4, parche 2.3, parche 1 de ISE 2.2 y usuarios identificados anteriormente con los atributos SAM, CN o ambos. Cisco ISE, versión 2.2 Parche 5 y posterior, y 2.3 Parche 2 y posterior, utilizan únicamente el atributo sAMAccountName como atributo predeterminado.

---

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
3.0	04-Aug-2026	Actualización de Introducción, Título, ortografía, gramática, líneas horizontales insertadas para separar secciones/legibilidad, texto alternativo actualizado.
2.0	03-Aug-2022	Gramática, estructura, traducción automática, estilo, formato
1.0	06-Feb-2020	Versión inicial