Ejemplo de Configuración de Admisiones IP ISR y LDAP para Redirección Web a ScanSafe/Cloud Web Security

Introducción

Este documento describe cómo configurar los routers de servicios integrados (ISR) de la serie G2 de Cisco. Si bien la configuración de IP Admission y LDAP (protocolo ligero de acceso a directorios) se puede utilizar simplemente para el proxy de autenticación en el ISR, normalmente se utiliza junto con la función de redirección de Cisco Cloud Web Security (CWS). Como tal, este documento se pretende ser una referencia para complementar la configuración de redirección de CWS y la documentación de Troubleshooting en ISR.

Prerequisites

Requirements

Cisco recomienda que su sistema cumpla estos requisitos antes de intentar las configuraciones que se describen en este documento:

• El ISR debe ejecutar el código versión 15.2(1)T1 o posterior.
  
  
• El sistema debe tener las imágenes con licencia del conjunto de funciones de seguridad (SEC) disponibles en Cisco IOS^® (universal).
  
  
• La estación de trabajo cliente en el dominio de Active Directory (AD) debe tener la capacidad de realizar la autenticación activa a través de un navegador web.
  
  
• Debe tener una suscripción a CWS.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Internet Explorer, Google Chrome, Mozilla Firefox (requiere configuración adicional para la autenticación transparente de NT LAN Manager (NTLM))
  
  
• ISR de las series G2 800, 1900, 2900 y 3900 de Cisco. 
  
  
• Controlador de dominio AD de Microsoft Windows (ADDC)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Nota: Los routers de las series Cisco G1 1800, 2800 y 3800 no son compatibles.

Antecedentes

Muchos administradores que instalan los ISR de la serie G2 de Cisco que no tienen dispositivos de seguridad adaptable (ASA) de Cisco en sus redes optan por utilizar la funcionalidad de redirección de ISR CWS (anteriormente ScanSafe) para aprovechar la solución CWS para el filtrado web. Como parte de esa solución, la mayoría de los administradores también desean utilizar la infraestructura de AD actual para enviar información de identidad de usuario a las torres de CWS con fines de aplicación de políticas basadas en usuarios o grupos para las políticas de filtrado web en el portal de CWS.

El concepto general es similar a la integración entre ASA y Context Directory Agent (CDA), con algunas diferencias. La diferencia más notable es que el ISR no mantiene en realidad una base de datos de asignación pasiva de usuario a IP, por lo que los usuarios deben pasar algún tipo de autenticación para transitar el ISR y enviar información de usuario o grupo al portal CWS.

Consejo: Consulte la sección Métodos de Autenticación de este documento para obtener más información sobre las diferencias entre los diversos métodos de autenticación disponibles.

Si bien la parte de redirección de CWS de la configuración que se describe en este documento es relativamente sencilla, algunos administradores pueden encontrar dificultades con los intentos de configurar la parte de autenticación. Esta parte funciona con el comando ip import que hace referencia a los servidores LDAP y a las sentencias de autenticación, autorización y contabilidad (AAA) que también deben configurarse. El propósito de este documento es proveer a los operadores de red con una fuente de referencia completa para configurar o resolver problemas de las porciones IP Admission y LDAP de esta configuración en los ISR de la serie G2 de Cisco.

Configurar

Utilice la información que se describe en esta sección para configurar Cisco ISR.

Nota: Use la Command Lookup Tool (clientes registrados solamente) para obtener más información sobre los comandos usados en esta sección.

Diagrama de la red

Configurar LDAP

Complete estos pasos para configurar las propiedades LDAP de los servidores AAA:

1. Configure un mapa de atributos LDAP para forzar el nombre de usuario que ingresa el usuario a que coincida con la propiedad sAMAccountName en el AD:
   

   C-881(config)#ldap attribute-map ldap-username-map map type sAMAccountName
    username
   C-881(config-attr-map)#map type sAMAccountName username
   
   

   Nota: Esta configuración es necesaria porque el atributo sAMAccountName es un valor único en AD, a diferencia del atributo Common Name (CN), que se utiliza de otra manera para coincidir de forma predeterminada. Por ejemplo, puede haber varias instancias de John Smith en AD, pero sólo puede haber un usuario con el AMAccountName de jsmith, que también es el inicio de sesión de la cuenta de usuario. Otras cuentas John Smith tienen AMAccountNames como jsmith1 o jsmith2.

   
   El comando show ldap Attributes también se puede utilizar para ver una lista de los atributos LDAP y los atributos AAA asociados.
   
   
2. Configure el grupo de servidores LDAP:
   

   C-881(config)#aaa group server ldap LDAP_GROUP
   C-881(config-ldap-sg)#server DC01

3. Configure los servidores LDAP:
   

   C-881(config)#ldap server DC01
   C-881(config-ldap-server)# ipv4 10.10.10.150
   C-881(config-ldap-server)#attribute map ldap-username-map
   C-881(config-ldap-server)# bind authenticate root-dn CN=Csco_Service,CN=Users,
    DC=lab,DC=cisco,DC=com password Cisco12345!
   
   C-881(config-ldap-server)#base-dn DC=lab,DC=cisco,DC=com
   C-881(config-ldap-server)#search-filter user-object-type top
   C-881(config-ldap-server)#authentication bind-first

Esta configuración generalmente no requiere modificación, a menos que sea necesario implementar un filtro de búsqueda personalizado. Sólo los administradores con una buena experiencia en LDAP y que sepan cómo introducir correctamente esta información deben utilizar filtros de búsqueda personalizados. Si no está seguro del filtro de búsqueda que se debe utilizar, simplemente utilice el filtro descrito; localiza a los usuarios en un entorno AD normal.

Otra parte de la configuración LDAP que también requiere una atención cuidadosa a los detalles es la de los Nombres Distinguidos (DNs) que se requieren en los comandos bind-authenticate-root-dn y base-dn. Estos deben ingresarse exactamente como aparecen en el servidor LDAP, o las consultas LDAP fallan. Además, el comando base-dn debe ser la parte más baja del árbol LDAP, donde residen todos los usuarios autenticados.

Considere la situación en la que se modifica el comando base-dn en la configuración anterior, como esta:

base-dn OU=TestCompany,DC=lab,DC=cisco,DC=com

En este caso, la consulta de los usuarios incluidos en el CN=Users,DC=lab,DC=cisco,DC=com no arroja resultados, ya que el servidor LDAP sólo busca en la unidad organizativa TestCompany (OU) y en los objetos secundarios que contiene. Como resultado, la autenticación siempre falla para esos usuarios hasta que se mueven a TestCompany OU o a su subárbol, o si el comando base-dn se modifica para incluirlo en la consulta. 

Consejo: Refiérase a la sección Determinar los Objetos DN en la sección AD - ADSI Edit de este documento para obtener detalles sobre cómo determinar los DN adecuados para los comandos base y raíz.

Configuración de AAA

Ahora que los servidores LDAP están configurados, debe hacer referencia a ellos en las sentencias AAA correspondientes que son utilizadas por el proceso de admisión IP:

C-881(config)#aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
C-881(config)#aaa authorization network SCANSAFE_AUTH group LDAP_GROUP

Nota: Si estos comandos no están disponibles, entonces el comando aaa new-model podría ser ingresado para habilitar esta funcionalidad AAA porque no está habilitada de manera predeterminada.

Configuración de la Admisión IP

La parte Admisión IP activa un proceso que solicita al usuario la autenticación (o realiza la autenticación transparente) y luego realiza consultas LDAP basadas en las credenciales del usuario y los servidores AAA definidos en la configuración. Si los usuarios se autentican correctamente, la información de identidad del usuario se extrae mediante el proceso de escaneo de contenido y se envía a las torres CWS, junto con el flujo redirigido. El proceso de Admisión IP no se activa hasta que el comando de admisión de IP name se ingresa en la interfaz de ingreso del router. Por lo tanto, esta parte de la configuración se puede implementar sin ningún impacto en el tráfico.

C-881(config)#ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY
C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm
C-881(config)#ip admission name SCANSAFE_ADMISSION method-list authentication
 SCANSAFE_AUTH authorization SCANSAFE_AUTH

Activar admisión IP

Esta es la configuración que se utiliza para habilitar la admisión IP:

Nota: Esto obliga a los usuarios a ser autenticados, lo que provoca la interrupción del flujo de tráfico si falla la autenticación.

C-881(config)#int vlan301 (internal LAN-facing interface)
C-881(config-if)#ip admission SCANSAFE_ADMISSION

Exención de la Autenticación de los Hosts Internos

Algunos administradores podrían desear eximir algunos hosts internos del proceso de autenticación por varias razones. Por ejemplo, podría no ser deseable que los servidores internos o los dispositivos que no son capaces de NTLM o autenticación básica se vean afectados por el proceso de admisiones IP. En estos casos, se puede aplicar una lista de control de acceso (ACL) a la configuración de admisión IP para evitar que IP o subredes de host específicas activen la admisión IP.

En este ejemplo, el host interno 10.10.10.150 está exento del requisito de autenticación, mientras que la autenticación sigue siendo necesaria para todos los otros hosts:

C-881(config)#ip access-list extended NO_ADMISSION
C-881(config-ext-nacl)#deny ip host 10.10.10.150 any
C-881(config-ext-nacl)#permit ip any any
C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm list NO_ADMISSION

Habilitar el servidor HTTP en el ISR

Se requiere que habilite el servidor HTTP para interceptar las sesiones HTTP e iniciar el proceso de autenticación:

Ip http server
Ip http secure-server 

Nota: El servidor seguro Ip http sólo se necesita si se requiere redirección a HTTPS para la autenticación.

Configurar redirección CWS

Esta es una configuración de resumen básica para la redirección de CWS:

parameter-map type content-scan global
 server scansafe primary name proxy139.scansafe.net port http 8080 https 8080
 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080
 license 0 DE749585HASDH83HGA94EA8C369
 source interface Vlan302
 user-group DEFAULT_GROUP username DEFAULT_USER
 server scansafe on-failure allow-all

interface Vlan302 (egress interface towards Internet)
 content-scan out

Ejemplo de Configuración Completo

Esta sección proporciona configuraciones de ejemplo completas para las secciones anteriores.

LDAP

aaa group server ldap LDAP_GROUP
 server DC01
ldap attribute-map ldap-username-map
 map type sAMAccountName username
ldap server DC01
 ipv4 10.10.10.150
 attribute map ldap-username-map
 bind authenticate root-dn CN=Csco_Service,CN=Users,DC=lab,DC=cisco,DC=com
  password Cisco12345!
 base-dn dc=lab,dc=cisco,dc=com
 search-filter user-object-type top
 authentication bind-first

AAA

aaa new-model
aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
aaa authorization network SCANSAFE_AUTH group LDAP_GROUP

Admisión IP

ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY
ip admission name SCANSAFE_ADMISSION ntlm
ip admission name SCANSAFE_ADMISSION method-list authentication
 SCANSAFE_AUTH authorization SCANSAFE_AUTH

interface Vlan301
 ip admission SCANSAFE_ADMISSION

Servidor HTTP

ip http server

Análisis de contenido y CWS

parameter-map type content-scan global
 server scansafe primary name proxy139.scansafe.net port http 8080 https 8080
 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080
 license 0 DE13621993BD87B306B5A5607EA8C369
 source interface Vlan302
 user-group DEFAULT_GROUP username DEFAULT_USER
 server scansafe on-failure allow-all

interface Vlan302
 content-scan out

Determinar los objetos DN en la edición AD - ADSI

Si es necesario, es posible examinar una estructura AD para buscar DNs para usarlos con la base de búsqueda de usuario o grupo. Los administradores pueden utilizar una herramienta llamada ADSI Edit integrada en los controladores de dominio AD. Para abrir ADSI Edit, elija Start > Run en el controlador de dominio AD e ingrese adsiedit.msc.

Una vez que ADSI Edit esté abierto, haga clic con el botón derecho del ratón en cualquier objeto, como un OU, grupo o usuario, y elija Properties para ver el DN de ese objeto. La cadena DN se puede copiar y pegar fácilmente en la configuración del router para evitar errores tipográficos. Esta imagen ilustra el proceso:

 

Métodos de autenticación

Hay cuatro tipos diferentes de métodos de autenticación disponibles que utilizan IP Admission, y a menudo se malinterpretan, especialmente la diferencia entre NTLM transparente y pasivo. Las secciones siguientes describen las diferencias entre estos tipos de autenticación.

NTLM activo

El método de autenticación NTLM activo solicita a los usuarios la autenticación cuando falla la autenticación NTLM transparente. Esto se debe normalmente al hecho de que el navegador cliente no admite la autenticación integrada de Microsoft Windows o porque el usuario se conectó a la estación de trabajo con credenciales locales (no de dominio). La autenticación NTLM activa realiza consultas LDAP al controlador de dominio para asegurarse de que las credenciales proporcionadas sean correctas.

Nota: Con todos los tipos de autenticación NTLM, las credenciales no se pasan a través de texto sin formato. Sin embargo, NTLM versión 1 (NTLMv1) presenta vulnerabilidades bien documentadas. El ISR es compatible con NTLMv2, aunque, de forma predeterminada, las versiones anteriores de Microsoft Windows pueden negociar mediante NTLMv1. Este comportamiento depende de las políticas de autenticación de AD.

NTLM transparente

La autenticación NTLM transparente se produce cuando un usuario inicia sesión en la estación de trabajo con credenciales de dominio, y el explorador pasa esas credenciales de forma transparente al router IOS. El router IOS luego realiza una consulta LDAP para validar las credenciales del usuario. Esta es generalmente la forma de autenticación más deseada para esta función.

Autenticación básica (mediante HTTP en texto sin formato)

Esta forma de autenticación se utiliza normalmente como mecanismo de reserva cuando falla la autenticación NTLM o no es posible para clientes como Macintosh, dispositivos basados en Linux o dispositivos móviles. Con este método, si el servidor HTTP Secure no está habilitado, estas credenciales se pasan a través de HTTP en texto sin formato (muy inseguro).

NTLM pasivo

La autenticación NTLM pasiva solicita las credenciales de los usuarios pero no autentica al usuario en el controlador de dominio. Aunque esto puede evitar problemas relacionados con LDAP donde las consultas fallan en el controlador de dominio, también expone a los usuarios en el entorno a un riesgo de seguridad. Si la autenticación transparente falla o no es posible, se le solicitarán las credenciales a los usuarios. Sin embargo, el usuario puede introducir las credenciales que elija, que se pasan a la torre CWS. Por consiguiente, es posible que las políticas no se apliquen adecuadamente.

Por ejemplo, el usuario A puede utilizar Firefox (que de forma predeterminada no permite NTLM transparente sin configuración adicional) e introducir el nombre de usuario del usuario B con cualquier contraseña, y las políticas para el usuario B se aplican al usuario A. La exposición al riesgo puede mitigarse si todos los usuarios se ven obligados a utilizar exploradores que admiten la autenticación NTLM transparente, pero en la mayoría de los casos no se recomienda el uso de la autenticación pasiva.

Secuencia de mensajes para la autenticación NTLM activa

Esta es la secuencia de mensajes completa para el método de autenticación NTLM activo:

Browser -->  ISR : GET / google.com
Browser <--  ISR : 302 Page moved http://1.1.1.1/login.html
Browser -->  ISR : GET /login.html 1.1.1.1
Browser <--  ISR : 401 Unauthorized..Authenticate using NTLM
Browser -->  ISR : GET /login.html + NTLM Type-1 msg
ISR     -->  AD  : LDAP Bind Request + NTLM Type-1 msg

El ISR copia el mensaje de tipo 1 de HTTP a LDAP, byte a byte, sin ninguna modificación de datos.

ISR     <--  AD  : LDAP Bind Response + NTLM Type-2 msg
Browser <--  ISR : 401 Unauthorized + NTLM Type-2 msg

El mensaje de tipo 2 también se copia byte por byte de LDAP a HTTP. Así pues, en el PCAP parece originarse a partir de 1.1.1.1, pero el contenido real es del AD.

Browser -->  ISR : GET /login.html + NTLM Type-3 msg
ISR     -->  AD  : LDAP Bind Request + NTLM Type-3 msg
ISR     <--  AD  : LDAP Bind response - Success
Browser <--  ISR : 200OK + redirect to google.com

Cuando se configura NTLM activo, el ISR no interfiere durante el intercambio NTLM. Sin embargo, si se configura NTLM pasivo, el ISR genera su propio mensaje de tipo 2.

Verificación

Actualmente, no hay un procedimiento de verificación disponible para esta configuración.

Troubleshoot

En esta sección se brinda información que puede utilizar para resolver problemas en su configuración.

Comandos show

Nota: La herramienta de interpretación de información de salida (disponible para clientes registrados únicamente) admite ciertos comandos show. Utilice la herramienta para ver una análisis de información de salida del comando show.

Puede utilizar estos comandos show para resolver problemas de su configuración:

• show ip input cache
• show ip mission Status
• show ip mission statistics
• show ldap server all

Comandos de Debug

Nota: Consulte Información Importante sobre Comandos de Debug antes de usar un comando debug.

Estos son algunos comandos de depuración útiles que puede utilizar para resolver problemas de su configuración:

• debug ldap all - Este comando se puede utilizar para descubrir la razón por la que falla la autenticación.
  
  
• debug ip input detail - Este comando es muy detallado e intensivo en la CPU. Cisco recomienda que lo utilice únicamente con clientes de prueba únicos que activen la admisión IP.
  
  
• debug ip import ntlm - Este comando se puede utilizar para descubrir la razón por la que se activa el proceso de admisión IP.
  
  
• debug ip import httpd
  
  
• debug ip http Transaction
  
  
• debug aaa authentication debug aaa authorization

Problemas comunes

Esta sección describe algunos problemas comunes que se encuentran con la configuración descrita en este documento.

La Admisión IP no Intercepta Solicitudes HTTP

Este problema se hace evidente cuando se ve la salida del comando show ip import statistics. El resultado no muestra la intercepción de ninguna solicitud HTTP:

C-881#show ip admission statistics
Webauth HTTPd statistics:

  HTTPd process 1
    Intercepted HTTP requests: 0

Posibles soluciones

Hay dos soluciones posibles para este problema. La primera es verificar que el servidor ip http esté habilitado. 

Si el servidor HTTP para el ISR no está habilitado, la Admisión IP activa pero nunca intercepta la sesión HTTP. Por lo tanto, solicita autenticación. En esta situación, no hay salida para el comando show ip import cache, pero muchas recurrencias de estas líneas se ven en la salida del comando debug ip input detail:

*Jan 30 20:49:35.726: ip_admission_det:proceed with process path authentication
*Jan 30 20:49:35.726: AUTH-PROXY auth_proxy_find_conn_info :
         find srcaddr - 10.10.10.152, dstaddr - 192.168.1.1
                 ip-srcaddr 10.20.10.1
                 pak-srcaddr 10.10.10.152

La segunda solución a este problema es verificar que la dirección IP del usuario no esté exenta de la ACL en la configuración de Admisión IP.

Los usuarios reciben un error 404 no encontrado

Este problema se observa cuando se redirige a los usuarios para la autenticación y se produce un error 404 no encontrado en el explorador.

Soluciones posibles

Asegúrese de que el nombre en el host virtual ISR_PROXY 1.1.1 virtual-ip de admisión virtual pueda resolverse correctamente con el servidor del sistema de nombres de dominio (DNS) del cliente. En este caso, el cliente realiza una consulta DNS para ISR_PROXY.lab.cisco.com ya que lab.cisco.com es el nombre de dominio completamente calificado (FQDN) del dominio al que se une la estación de trabajo. Si la consulta DNS falla, el cliente envía una consulta de resolución de nombres de multidifusión local de enlaces (LLMNR), seguida de una consulta NETBIOS que se transmite a la subred local. 

Si todos estos intentos de resolución fallan, se muestra en el explorador un error 404 Not Found o Internet Explorer Can Display the webpage. 

La Autenticación De Usuario Falla Cuando Se Le Solicita

Esto puede ser causado por varias razones pero generalmente está relacionado con la configuración LDAP en el ISR, o la comunicación entre el ISR y el servidor LDAP. En el ISR, el síntoma se observa generalmente cuando los usuarios se atascan en el estado INIT una vez que se activa la Admisión IP:

C-881(config)#do show ip admi cac
Authentication Proxy Cache
 Client Name N/A, Client IP 10.10.10.152, Port 56674, timeout 60,
  Time Remaining 2, state INIT

Causas comunes

Estas son las causas comunes de este problema:

• El usuario ingresa un nombre de usuario y/o contraseña no válidos para la autenticación activa.
  
  
• En la configuración de LDAP se utiliza una base-dn no válida, lo que da lugar a búsquedas que no devuelven resultados.
  
  
• Se configura una autenticación de enlace no válida root-dn para el nombre de usuario o la contraseña, lo que hace que el enlace LDAP falle.
  
  
• La comunicación entre el ISR y el servidor LDAP falla. Verifique que el servidor LDAP escucha en el puerto TCP especificado para la comunicación LDAP y que todos los firewalls entre los dos permiten el tráfico.
  
  
• Un filtro de búsqueda no válido no produce resultados para la búsqueda LDAP.

Troubleshooting de LDAP

La mejor manera de determinar la razón por la que falla la autenticación es utilizar los comandos de depuración LDAP en el ISR. Tenga en cuenta que las depuraciones pueden ser costosas y peligrosas para ejecutarse en un ISR si hay una salida excesiva, y pueden hacer que el router se cuelgue y requiera un ciclo de alimentación duro. Esto es especialmente cierto en el caso de las plataformas de gama baja. 

Para resolver problemas, Cisco recomienda que aplique una ACL a la regla de admisión IP para someter solamente una estación de trabajo de prueba única en la red a la autenticación. De esta manera, las depuraciones se pueden habilitar con un riesgo mínimo de impacto negativo en la capacidad del router para pasar tráfico.

Consejo: Consulte la sección Exención de Hosts Internos de la Autenticación de este documento para obtener más información sobre la aplicación de una ACL a la configuración de Admisiones IP.

Cuando resuelve problemas relacionados con LDAP, es útil comprender los pasos en los que LDAP procesa las solicitudes del ISR. 

Pasos de alto nivel para la autenticación LDAP

Estos son los pasos de alto nivel para la autenticación LDAP:

1. Abra la conexión con el servidor LDAP en el puerto especificado. El puerto predeterminado es TCP 389.
   
   
2. Enlazar al servidor LDAP con el usuario y la contraseña root-dn de autenticación de enlace.
   
   
3. Realice la búsqueda LDAP, con el uso de base-dn y los filtros de búsqueda definidos en la configuración LDAP, para el usuario que intenta autenticar.
   
   
4. Obtenga los resultados de LDAP del servidor LDAP y cree una entrada de caché de admisión IP para el usuario si la autenticación es exitosa, o vuelva a solicitar las credenciales en caso de una falla de autenticación.

Análisis de salida de depuración LDAP

Estos procesos se pueden ver en la salida del comando debug ldap all. Esta sección proporciona un ejemplo del resultado de la depuración LDAP para una autenticación que falla debido a una base-dn no válida.  Revise el resultado de la depuración y los comentarios asociados, que describen las porciones del resultado que muestran dónde podrían encontrarse fallas los pasos mencionados.

*Jan 30 20:51:50.818: LDAP: LDAP: Queuing AAA request 23 for processing
*Jan 30 20:51:50.818: LDAP: Received queue event, new AAA request
*Jan 30 20:51:50.818: LDAP: LDAP authentication request
*Jan 30 20:51:50.818: LDAP: Username sanity check failed
*Jan 30 20:51:50.818: LDAP: Invalid hash index 512, nothing to remove
*Jan 30 20:51:50.818: LDAP: New LDAP request
*Jan 30 20:51:50.818: LDAP: Attempting first  next available LDAP server
*Jan 30 20:51:50.818: LDAP: Got next LDAP server :DC01
*Jan 30 20:51:50.818: LDAP: Free connection not available. Open a new one.
*Jan 30 20:51:50.818: LDAP: Opening ldap connection
 ( 10.10.10.150, 389 )ldap_open 

La parte del resultado que se muestra en negrita indica que no se trata de un problema de capa de red, ya que la conexión se ha abierto correctamente.

*Jan 30 20:51:50.822: LDAP: Root Bind on CN=Csco_Service,CN=Users,DC=lab,
 DC=cisco,DC=com initiated.
*Jan 30 20:51:51.330: LDAP: Ldap Result Msg: SUCCESS, Result code =0
*Jan 30 20:51:51.330: LDAP: Root DN bind Successful on :CN=Csco_Service,
 CN=Users,DC=lab,DC=cisco,DC=com

El Bind authenticate-dn es correcto en este resultado. Si la configuración es incorrecta para esto, se observan fallas de enlace. 

*Jan 30 20:51:51.846: LDAP: Received Bind Responseldap_parse_sasl_bind_result
*Jan 30 20:51:51.846: LDAP: Ldap SASL Result Msg: SUCCESS, Result code =14
 sasLres_code =14
*Jan 30 20:51:51.846: LDAP: SASL NTLM authentication do not require
 further tasks
*Jan 30 20:51:51.846: LDAP: Next Task: All authentication task completed
*Jan 30 20:51:51.846: LDAP: Transaction context removed from list
 [ldap reqid=14]
*Jan 30 20:51:51.846: LDAP: * * AUTHENTICATION COMPLETED SUCCESSFULLY * *
*Jan 30 20:51:51.846: LDAP: Notifying AAA: REQUEST CHALLENGED

La parte del resultado que se muestra en negrita indica que todas las operaciones de enlace son correctas y procede a buscar al usuario real.

*Jan 30 20:51:51.854: LDAP: SASL NTLM authentication done..Execute search
*Jan 30 20:51:51.854: LDAP: Next Task: Send search req
*Jan 30 20:51:51.854: LDAP: Transaction context removed from list[ldap reqid=15]
*Jan 30 20:51:51.854: LDAP: Dynamic map configured
*Jan 30 20:51:51.854: LDAP: Dynamic map found for aaa type=username
*Jan 30 20:51:51.854: LDAP: Ldap Search Req sent
                    ld          2293572544
                    base dn     dc=lab1,dc=cisco,dc=comscope       2
                    filter      (&(objectclass=top)(sAMAccountName=testuser5))
                                 ldap_req_encode
put_filter "(&(objectclass=top)(sAMAccountName=testuser5))"
put_filter: AND
put_filter_list "(objectclass=top)(sAMAccountName=testuser5)"
put_filter "(objectclass=top)"
put_filter: simple
put_filter "(sAMAccountName=testuser5)"
put_filter: simple
Doing socket write
*Jan 30 20:51:51.854: LDAP: lctx conn index = 2

La primera línea (mostrada en negrita) indica que comienza el resultado de depuración de búsqueda LDAP. Además, observe que el controlador de dominio base-dn debe configurarse para laboratorio, no lab1.

*Jan 30 20:51:52.374: LDAP: LDAP Messages to be processed: 1
*Jan 30 20:51:52.374: LDAP: LDAP Message type: 101
*Jan 30 20:51:52.374: LDAP: Got ldap transaction context from reqid
 16ldap_parse_result
*Jan 30 20:51:52.374: LDAP: resultCode:    10     (Referral)
*Jan 30 20:51:52.374: LDAP: Received Search Response resultldap_parse_result
 ldap_err2string
*Jan 30 20:51:52.374: LDAP: Ldap Result Msg: FAILED:Referral, Result code =10 
*Jan 30 20:51:52.374: LDAP: LDAP Search operation result : failedldap_msgfree
*Jan 30 20:51:52.374: LDAP: Closing transaction and reporting error to AAA
*Jan 30 20:51:52.374: LDAP: Transaction context removed from list
 [ldap reqid=16]
*Jan 30 20:51:52.374: LDAP: Notifying AAA: REQUEST FAILED

La parte del resultado que se muestra en negrita indica que la búsqueda no devolvió ningún resultado, lo que en este caso se debe a una base-dn no válida.

RFC 4511

RFC 4511 (protocolo ligero de acceso a directorios (LDAP): El Protocolo) proporciona información sobre los mensajes de código de resultado para LDAP y otra información relacionada con el protocolo LDAP, a la que se puede hacer referencia a través del sitio web IETF.

Historial de revisiones