Para parceiros
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.
A Cisco recomenda que seu sistema atenda a esses requisitos antes de tentar as configurações descritas neste documento:
As informações neste documento são baseadas nestas versões de software e hardware:
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.
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.
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.
Use as informações descritas nesta seção para configurar o Cisco ISR.
Conclua estes passos para configurar as propriedades LDAP dos servidores AAA:
C-881(config)#ldap attribute-map ldap-username-map map type sAMAccountName
username
C-881(config-attr-map)#map type sAMAccountName username
C-881(config)#aaa group server ldap LDAP_GROUP
C-881(config-ldap-sg)#server DC01
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.
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
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
Esta é a configuração usada para habilitar a Admissão IP:
C-881(config)#int vlan301 (internal LAN-facing interface)
C-881(config-if)#ip admission SCANSAFE_ADMISSION
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
É 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
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
Esta seção fornece configurações de exemplo completas para as seções anteriores.
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 new-model
aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
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
ip http server
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
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:
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.
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.
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.
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).
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.
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.
No momento, não há procedimento de verificação disponível para esta configuração.
Esta seção disponibiliza informações para a solução de problemas de configuração.
Você pode usar estes comandos show para solucionar problemas de sua configuração:
Aqui estão alguns comandos debug úteis que você pode usar para solucionar problemas de sua configuração:
Esta seção descreve alguns problemas comuns encontrados com a configuração descrita neste documento.
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
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.
Esse problema é observado quando os usuários são redirecionados para autenticação e um erro 404 Not Found ocorre no navegador.
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.
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
Estas são as causas comuns para este problema:
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.
Quando você soluciona problemas relacionados ao LDAP, é útil entender as etapas nas quais o LDAP processa solicitações do ISR.
Aqui estão as etapas de alto nível para a autenticaçã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 (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.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
18-Jul-2014 |
Versão inicial |