Exemplo de configuração de Admissões IP ISR e LDAP para Redirecionamento Web para ScanSafe/Cloud Web Security

Introduction

Este documento descreve como configurar os Cisco G2 Series Integrated Services Routers (ISRs). Embora a configuração de IP Admission e Lightweight Diretory Access Protocol (LDAP) possa ser usada simplesmente para proxy de autenticação no ISR, geralmente é usada em conjunto com o recurso de redirecionamento Cisco Cloud Web Security (CWS). Como tal, este documento deve ser uma referência para complementar a configuração de redirecionamento do CWS e a documentação de solução de problemas em ISRs.

Prerequisites

Requirements

A Cisco recomenda que seu sistema atenda a esses requisitos antes de tentar as configurações descritas neste documento:

• O ISR deve executar o código versão 15.2(1)T1 ou posterior.
  
  
• O sistema deve ter as imagens com licença SEC (security feature set, conjunto de recursos de segurança) disponíveis no Cisco IOS^® (universal).
  
  
• A estação de trabalho do Cliente no domínio do Ative Diretory (AD) deve ter a capacidade de executar a autenticação ativa através de um navegador da Web.
  
  
• Você deve ter uma assinatura do CWS.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Internet Explorer, Google Chrome, Mozilla Firefox (requer configuração adicional para autenticação NTLM (NT LAN Manager) transparente)
  
  
• ISRs Cisco G2 séries 800, 1900, 2900 e 3900. 
  
  
• Controlador de Domínio do Microsoft Windows AD (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.

Note: Os roteadores Cisco G1 séries 1800, 2800 e 3800 não são suportados.

Informações de Apoio

Muitos administradores que instalam os Cisco G2 Series ISRs que não têm Cisco Adaptive Security Appliances (ASAs) em suas redes optam por utilizar a funcionalidade de redirecionamento ISR CWS (anteriormente ScanSafe) para aproveitar a solução CWS para filtragem da Web. Como parte dessa solução, a maioria dos administradores também deseja utilizar a infraestrutura atual do AD para enviar informações de identidade de usuário às torres do CWS para fins de aplicação de política baseada em usuário ou grupo para as políticas de filtragem da Web no portal do CWS.

O conceito geral é semelhante à integração entre o ASA e o CDA (Context Diretory Agent), com algumas diferenças. A diferença mais notável é que o ISR na verdade não mantém um banco de dados de mapeamento passivo de usuário para IP, portanto os usuários devem passar por algum tipo de autenticação para transitar pelo ISR e enviar informações de usuário ou grupo para o portal do CWS.

Tip: Consulte a seção Métodos de Autenticação deste documento para obter mais informações sobre as diferenças entre os vários métodos de autenticação disponíveis.

Embora a parte de redirecionamento do CWS da configuração descrita neste documento seja relativamente simples, alguns administradores podem encontrar dificuldades com tentativas de configurar a parte de autenticação. Esta parte funciona com o comando ip Admission que faz referência aos servidores LDAP e às instruções de autenticação Authentication, Authorization, and Accounting (AAA) que também devem ser configuradas. A finalidade deste documento é fornecer aos operadores de rede uma fonte de referência abrangente para configurar ou solucionar problemas de IP Admissions e partes LDAP desta configuração nos Cisco G2 Series ISRs.

Configurar

Use as informações descritas nesta seção para configurar o Cisco ISR.

Note: Use a Command Lookup Tool ( somente clientes registrados) para obter mais informações sobre os comandos usados nesta seção.

Diagrama de Rede

Configurar LDAP

Conclua estes passos para configurar as propriedades LDAP dos servidores AAA:

1. Configure um mapa de atributos LDAP para forçar o nome de usuário inserido pelo usuário a corresponder à propriedade sAMAccountName no AD:
   

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

   Note: Esta configuração é necessária porque o atributo sAMAccountName é um valor exclusivo no AD, ao contrário do atributo Common Name (CN), que é usado de outra forma para corresponder por padrão. Por exemplo, pode haver várias instâncias de John Smith no AD, mas só pode haver um usuário com o sAMAccountName de jsmith, que também é o login da conta de usuário. Outras contas John Smith têm sAMAccountNames como jsmith1 ou jsmith2.

   
   O comando show ldap attribute também pode ser usado para exibir uma lista dos atributos LDAP e dos atributos AAA associados.
   
   
2. Configure o grupo de servidores LDAP:
   

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

3. Configure os 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

Essa configuração geralmente não exige modificação, a menos que haja necessidade de implementar um filtro de pesquisa personalizado. Somente os administradores que são bem versados no LDAP e sabem como inserir corretamente essas informações devem utilizar filtros de pesquisa personalizados. Se você não tiver certeza sobre o filtro de pesquisa que deve ser usado, basta usar o filtro descrito; ele localiza os usuários em um ambiente normal de AD.

Outra parte da configuração LDAP que também exige atenção cuidadosa aos detalhes são os Nomes Distintos (DNs - Distinguished Names) que são necessários nos comandos bind-authenticate-root-dn e base-dn. Eles devem ser inseridos exatamente como aparecem no servidor LDAP ou as consultas LDAP falham. Além disso, o comando base-dn deve ser a parte mais baixa da árvore LDAP, onde todos os usuários autenticados residem.

Considere o cenário no qual o comando base-dn na configuração anterior é modificado, como este:

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

Nesse caso, a consulta para os usuários incluídos na CN=Users,DC=lab,DC=cisco,DC=com não retorna nenhum resultado, já que o servidor LDAP pesquisa somente a unidade organizacional da TestCompany (OU) e os objetos filho dentro dela. Como resultado, a autenticação sempre falha para esses usuários até que sejam movidos para a OU da TestCompany ou para sua subárvore, ou se o comando base-dn for alterado para incluí-lo na consulta. 

Tip: Consulte a seção Determine os Objetos DN no AD - ADSI Edit deste documento para obter detalhes sobre como determinar os DNs apropriados para os comandos base e root.

Configurar AAA

Agora que os servidores LDAP estão configurados, você deve referenciá-los nas instruções AAA correspondentes usadas pelo processo de admissão de IP:

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

Note: Se esses comandos não estiverem disponíveis, o comando aaa new-model pode precisar ser inserido para habilitar essa funcionalidade AAA porque ela não está habilitada por padrão.

Configurar Admissão IP

A parte Admissão de IP aciona um processo que solicita a autenticação do usuário (ou executa a autenticação transparente) e, em seguida, executa consultas LDAP com base nas credenciais do usuário e nos servidores AAA definidos na configuração. Se os usuários forem autenticados com êxito, as informações de identidade do usuário serão obtidas pelo processo de análise de conteúdo e enviadas às torres do CWS, juntamente com o fluxo redirecionado. O processo de admissão de IP não é ativado até que o comando de nome de admissão de IP seja inserido na interface de entrada do roteador. Portanto, essa parte da configuração pode ser implementada sem nenhum impacto no tráfego.

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

Habilitar admissão de IP

Esta é a configuração usada para habilitar a Admissão IP:

Note: Isso força os usuários a serem autenticados, o que causa interrupção de fluxo de tráfego se a autenticação falhar.

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

Isento de Hosts Internos da Autenticação

Alguns administradores podem desejar isentar alguns hosts internos do processo de autenticação por vários motivos. Por exemplo, pode ser indesejável que servidores internos ou dispositivos que não são capazes de NTLM ou autenticação básica sejam afetados pelo processo de Admissão IP. Nesses casos, uma ACL (Access Control List, lista de controle de acesso) pode ser aplicada à configuração de Admissão IP para evitar que IPs ou sub-redes de host específicos disparem a Admissão IP.

Neste exemplo, o host interno 10.10.10.150 está isento do requisito de autenticação, enquanto a autenticação ainda é necessária para todos os outros 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

Ative o servidor HTTP no ISR

É necessário habilitar o servidor HTTP para interceptar as sessões HTTP e iniciar o processo de autenticação:

Ip http server
Ip http secure-server 

Note: O Ip http secure-server só é necessário se o redirecionamento para HTTPS para autenticação for necessário.

Configurar o redirecionamento CWS

Aqui está uma configuração básica de resumo para o redirecionamento 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

Exemplo de configuração completa

Esta seção fornece configurações de exemplo completas para as seções 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

Admissão de 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

Content-Scan e 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

Determine os Objetos DN na Edição AD - ADSI

Se necessário, é possível navegar em uma estrutura do AD para procurar DNs para uso com a base de pesquisa do usuário ou grupo. Os administradores podem usar uma ferramenta chamada ADSI Edit incorporada nos controladores de domínio do AD. Para abrir ADSI Edit, escolha Start > Run no controlador de domínio do AD e digite adsiedit.msc.

Depois que ADSI Edit estiver aberta, clique com o botão direito do mouse em qualquer objeto, como um OU, grupo ou usuário, e escolha Properties para exibir o DN desse objeto. A string DN pode ser facilmente copiada e colada na configuração do roteador para evitar erros tipográficos. Esta imagem ilustra o processo:

 

Métodos de autenticação

Há quatro tipos diferentes de métodos de autenticação disponíveis que usam a IP Admission e eles são frequentemente mal compreendidos, especialmente a diferença entre o NTLM transparente e passivo. As próximas seções descrevem as diferenças entre esses tipos de autenticação.

NTLM ativo

O método de autenticação NTLM ativa solicita aos usuários a autenticação quando a autenticação NTLM transparente falha. Isso geralmente ocorre porque o navegador do cliente não oferece suporte à autenticação integrada do Microsoft Windows ou porque o usuário fez logon na estação de trabalho com credenciais locais (não de domínio). A autenticação NTLM ativa executa consultas LDAP ao controlador de domínio para garantir que as credenciais fornecidas estejam corretas.

Note: Com todos os tipos de autenticação NTLM, as credenciais não são passadas através de texto claro. No entanto, o NTLM Versão 1 (NTLMv1) tem vulnerabilidades bem documentadas. O ISR é compatível com NTLMv2, embora, por padrão, versões mais antigas do Microsoft Windows possam negociar via NTLMv1. Esse comportamento depende das políticas de autenticação do AD.

NTLM transparente

A autenticação NTLM transparente ocorre quando um usuário está conectado à estação de trabalho com credenciais de domínio, e essas credenciais são passadas de forma transparente pelo navegador para o roteador IOS. O roteador IOS executa então uma consulta LDAP para validar as credenciais do usuário. Essa é geralmente a forma de autenticação mais desejada para esse recurso.

Autenticação básica (via HTTP em texto claro)

Essa forma de autenticação é normalmente usada como um mecanismo de fallback quando a autenticação NTLM falha ou não é possível para clientes como Macintosh, dispositivos baseados em Linux ou dispositivos móveis. Com esse método, se o servidor HTTP Seguro não estiver habilitado, essas credenciais serão passadas via HTTP em texto claro (muito inseguro).

NTLM passivo

A autenticação NTLM passiva solicita credenciais de usuários, mas não autentica o usuário no controlador de domínio. Embora isso possa evitar problemas relacionados ao LDAP em que as consultas falham em relação ao controlador de domínio, também expõe os usuários no ambiente a um risco de segurança. Se a autenticação transparente falhar ou não for possível, os usuários serão solicitados a fornecer credenciais. No entanto, o usuário pode inserir as credenciais que escolher, que são passadas para a torre do CWS. Como resultado, as políticas podem não ser aplicadas adequadamente.

Por exemplo, o Usuário A pode usar o Firefox (que por padrão não permite NTLM transparente sem configuração adicional) e digitar o nome de usuário B com qualquer senha, e as políticas para o usuário B são aplicadas ao Usuário A. A exposição ao risco pode ser atenuada se todos os usuários forem forçados a usar navegadores que suportem autenticação NTLM transparente, mas, na maioria dos casos, o uso de autenticação passiva não é recomendado.

Sequência de Mensagens para Autenticação NTLM Ativa

Esta é a sequência de mensagens completa para o método de autenticação NTLM ativa:

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

O ISR copia a mensagem Tipo 1 de HTTP para o LDAP, byte por byte sem qualquer alteração de dados.

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

A mensagem Tipo 2 também é copiada byte por byte do LDAP para HTTP. Assim, na PCAP, parece ter origem em 1.1.1.1, mas o conteúdo real é da 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

Quando o NTLM ativo é configurado, o ISR não interfere durante a troca do NTLM. No entanto, se o NTLM passivo estiver configurado, o ISR gera sua própria mensagem tipo 2.

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshoot

Esta seção disponibiliza informações para a solução de problemas de configuração.

comandos show

Note: A ferramenta Output Interpreter (exclusiva para clientes registrados) é compatível com alguns comandos de exibição.. Use a ferramenta Output Interpreter para visualizar uma análise do resultado gerado pelo comando show..

Você pode usar estes comandos show para solucionar problemas de sua configuração:

• show ip negotiation cache
• mostrar status de admissão de IP
• mostrar estatísticas de admissão de IP
• show ldap server all

Comandos debug

Note: Consulte Informações Importantes sobre Comandos de Depuração antes de usar comandos debug.

Aqui estão alguns comandos debug úteis que você pode usar para solucionar problemas de sua configuração:

• debug ldap all - Este comando pode ser usado para descobrir o motivo da falha na autenticação.
  
  
• debug ip negotiation detail - Este comando é muito detalhado e usa muito a CPU. A Cisco recomenda que você o use somente com clientes de teste único que acionam a admissão de IP.
  
  
• debug ip Admission ntlm - Esse comando pode ser usado para descobrir o motivo pelo qual o processo de Admissão IP é acionado.
  
  
• debug ip negotiation httpd
  
  
• debug ip http transaction
  
  
• debug aaa authentication debug aaa authorization

Problemas comuns

Esta seção descreve alguns problemas comuns encontrados com a configuração descrita neste documento.

A Admissão de IP não Intercepta Solicitações HTTP

Esse problema torna-se evidente quando você visualiza a saída do comando show ip negotiation statistics. A saída não mostra a interceptação de nenhuma solicitação HTTP:

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

  HTTPd process 1
    Intercepted HTTP requests: 0

Soluções possíveis

Há duas soluções possíveis para esse problema. A primeira é verificar se o servidor ip http está habilitado. 

Se o servidor HTTP do ISR não estiver habilitado, a Admissão de IP aciona, mas nunca intercepta a sessão HTTP. Portanto, ele solicita a autenticação. Nesta situação, não há saída para o comando show ip negotiation cache, mas muitas recorrências dessas linhas são vistas na saída do comando debug ip import 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

A segunda solução para esse problema é verificar se o endereço IP do usuário não está isento da ACL na configuração de Admissão IP.

Os usuários recebem um erro 404 não encontrado

Esse problema é observado quando os usuários são redirecionados para autenticação e um erro 404 Not Found ocorre no navegador.

Solução possível

Certifique-se de que o nome no host virtual IP de admissão de ip 1.1.1.1 ISR_PROXY possa ser resolvido com êxito com o servidor DNS (Domain Name System) cliente. Nesse caso, o cliente executa uma consulta DNS para ISR_PROXY.lab.cisco.com pois lab.cisco.com é o FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado) do domínio ao qual a estação de trabalho está associada. Se a consulta DNS falhar, o cliente envia uma consulta LLMNR (Link-Local Multicast Name Resolution), seguida de uma consulta NETBIOS que é transmitida para a sub-rede local. 

Se todas essas tentativas de resolução falharem, um erro 404 Not Found ou Internet Explorer Cannot Display the webpage será exibido no navegador. 

Falha na autenticação do usuário quando solicitado

Isso pode ser causado por vários motivos, mas geralmente está relacionado à configuração LDAP no ISR ou à comunicação entre o ISR e o servidor LDAP. No ISR, o sintoma geralmente é observado quando os usuários ficam presos no estado INIT quando a Admissão IP é acionada:

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 comuns

Estas são as causas comuns para este problema:

• Um nome de usuário e/ou senha inválidos é digitado pelo usuário para autenticação ativa.
  
  
• Uma base-dn inválida é usada na configuração LDAP, o que resulta em pesquisas que não retornam nenhum resultado.
  
  
• Uma autenticação de associação inválida root-dn está configurada para o nome de usuário ou senha, o que faz com que a associação LDAP falhe.
  
  
• A comunicação entre o ISR e o servidor LDAP falha. Verifique se o servidor LDAP escuta na porta TCP especificada para comunicação LDAP e se todos os firewalls entre os dois permitem o tráfego.
  
  
• Um filtro de pesquisa inválido não causa resultados para a pesquisa LDAP.

Solucionar problemas de LDAP

A melhor maneira de determinar o motivo da falha na autenticação é utilizar os comandos de depuração LDAP no ISR. Lembre-se de que as depurações podem ser caras e perigosas para serem executadas em um ISR se houver saída excessiva, e podem fazer com que o roteador trave e exija um ciclo de energia. Isso é especialmente verdadeiro para as plataformas mais avançadas. 

Para solucionar problemas, a Cisco recomenda que você aplique uma ACL à regra de admissão de IP para submeter apenas uma estação de trabalho de teste única na rede à autenticação. Dessa forma, as depurações podem ser habilitadas com um risco mínimo de impacto negativo para a capacidade do roteador de transmitir tráfego.

Tip: Consulte a seção Isentar Hosts Internos da Autenticação deste documento para obter mais informações sobre a aplicação de uma ACL à configuração de Admissões IP.

Quando você soluciona problemas relacionados ao LDAP, é útil entender as etapas nas quais o LDAP processa solicitações do ISR. 

Etapas de alto nível para autenticação LDAP

Aqui estão as etapas de alto nível para a autenticação LDAP:

1. Abra a conexão com o servidor LDAP na porta especificada. A porta padrão é TCP 389.
   
   
2. Vincule ao servidor LDAP com o link authenticate root-dn user e password.
   
   
3. Execute a pesquisa LDAP, com o uso dos filtros base-dn e de pesquisa definidos na configuração LDAP, para o usuário que tenta autenticar.
   
   
4. Obtenha os resultados LDAP do servidor LDAP e crie uma entrada de cache de Admissão IP para o usuário se a autenticação for bem-sucedida ou solicite credenciais no caso de uma falha de autenticação.

Análise de saída de depuração LDAP

Esses processos podem ser visualizados na saída do comando debug ldap all. Esta seção fornece um exemplo da saída de depuração LDAP para uma autenticação que falha devido a uma base-dn inválida.  Revise a saída de depuração e os comentários associados, que descrevem as partes da saída que mostram onde as etapas acima podem encontrar falha.

*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 

A parte da saída mostrada em negrito indica que isso não é um problema da camada de rede, já que a conexão foi aberta com êxito.

*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

O Bind authenticate-dn está correto nesta saída. Se a configuração estiver incorreta para isso, as falhas de associação serão vistas. 

*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

A parte da saída mostrada em negrito indica que todas as operações de vinculação foram bem-sucedidas e que continua a procurar o usuário 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

A primeira linha (mostrada em negrito) indica que a saída de depuração da Pesquisa LDAP começa. Observe também que o controlador de domínio base-dn deve ser configurado para laboratório, não para 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

A parte da saída mostrada em negrito indica que a pesquisa não retornou resultados, o que, nesse caso, é devido a uma base-dn inválida.

RFC 4511

RFC 4511 (Lightweight Diretory Access Protocol (LDAP): O Protocolo) fornece informações sobre as mensagens de código de resultado para LDAP e outras informações relacionadas ao protocolo LDAP, que podem ser referenciadas através do site IETF.

Histórico de revisões