Exemple de configuration des admissions IP ISR et LDAP pour la redirection Web vers ScanSafe/Cloud Web Security

Introduction

Ce document décrit comment configurer les routeurs à services intégrés (ISR) de la gamme Cisco G2. Bien que la configuration IP Admission and Lightweight Directory Access Protocol (LDAP) puisse être utilisée uniquement pour le proxy d'authentification sur l'ISR, elle est généralement utilisée en conjonction avec la fonction de redirection de Cisco Cloud Web Security (CWS). À ce titre, ce document est destiné à servir de référence afin de compléter la configuration de redirection CWS et la documentation de dépannage sur les ISR.

Conditions préalables

Conditions requises

Cisco recommande que votre système réponde à ces exigences avant de tenter les configurations décrites dans ce document :

• Le routeur de service intégré doit exécuter le code version 15.2(1)T1 ou ultérieure.
  
  
• Votre système doit disposer des images avec la licence SEC (Security Feature Set) disponibles dans Cisco IOS^® (universel).
  
  
• La station de travail Client du domaine Active Directory (AD) doit être capable d'effectuer une authentification active via un navigateur Web.
  
  
• Vous devez disposer d'un abonnement CWS.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Internet Explorer, Google Chrome, Mozilla Firefox (configuration supplémentaire requise pour l'authentification NTLM (NT LAN Manager) transparente)
  
  
• Routeurs à services intégrés des gammes Cisco G2 800, 1900, 2900 et 3900. 
  
  
• Contrôleur de domaine 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: Les routeurs des gammes Cisco G1 1800, 2800 et 3800 ne sont pas pris en charge.

Informations générales

De nombreux administrateurs qui installent les ISR de la gamme Cisco G2 qui n'ont pas d'ASA (Adaptive Security Appliances) Cisco dans leurs réseaux choisissent d'utiliser la fonctionnalité de redirection CWS (anciennement ScanSafe) de l'ISR afin de tirer parti de la solution CWS pour le filtrage Web. Dans le cadre de cette solution, la plupart des administrateurs souhaitent également utiliser l'infrastructure AD actuelle afin d'envoyer des informations d'identité utilisateur aux tours CWS à des fins d'application de stratégies utilisateur ou de groupe pour les stratégies de filtrage Web dans le portail CWS.

Le concept global est similaire à l'intégration entre l'ASA et l'agent de répertoire contextuel (CDA), avec quelques différences. La différence la plus notable est que le routeur de service intégré ne gère pas réellement de base de données de mappage utilisateur-IP passive, de sorte que les utilisateurs doivent passer par un type d'authentification afin de transmettre le routeur de service intégré et d'envoyer des informations utilisateur ou de groupe au portail CWS.

Astuce : Reportez-vous à la section Méthodes d'authentification de ce document pour plus d'informations sur les différences entre les différentes méthodes d'authentification disponibles.

Bien que la partie redirection CWS de la configuration décrite dans ce document soit relativement simple, certains administrateurs peuvent rencontrer des difficultés lors des tentatives de configuration de la partie authentification. Cette partie fonctionne avec la commande ip admission qui fait référence aux serveurs LDAP et aux instructions d'authentification AAA (Authentication, Authorization, and Accounting) qui doivent également être configurées. L'objectif de ce document est de fournir aux opérateurs réseau une source de référence complète afin de configurer ou de dépanner les sections IP Admissions et LDAP de cette configuration sur les ISR de la gamme Cisco G2.

Configuration

Utilisez les informations décrites dans cette section afin de configurer le routeur de service intégré Cisco.

Note: Utilisez l'Outil de recherche de commande (clients inscrits seulement) pour obtenir plus d'informations sur les commandes utilisées dans cette section.

Diagramme du réseau

Configurer LDAP

Complétez ces étapes afin de configurer les propriétés LDAP du ou des serveurs AAA :

1. Configurez un mappage d'attribut LDAP afin de forcer le nom d'utilisateur entré par l'utilisateur à correspondre à la propriété sAMAccountName dans l'AD :
   

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

   Note: Cette configuration est requise car l'attribut sAMAccountName est une valeur unique dans l'AD, contrairement à l'attribut Common Name (CN), qui est par ailleurs utilisé afin de correspondre par défaut. Par exemple, il peut y avoir plusieurs instances de John Smith dans l'AD, mais il ne peut y avoir qu'un seul utilisateur avec le sAMAccountName de jsmith, qui est également l'ouverture de session du compte d'utilisateur. D'autres comptes John Smith ont sAMAccountNames tels que jsmith1 ou jsmith2.

   
   La commande show ldap attribute peut également être utilisée pour afficher une liste des attributs LDAP et des attributs AAA associés.
   
   
2. Configurez le groupe de serveurs LDAP :
   

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

3. Configurez les serveurs 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

Cette configuration ne nécessite généralement pas de modification, sauf s'il est nécessaire d'implémenter un filtre de recherche personnalisé. Seuls les administrateurs qui connaissent bien LDAP et savent comment saisir correctement ces informations doivent utiliser des filtres de recherche personnalisés. Si vous n'êtes pas certain du filtre de recherche à utiliser, utilisez simplement le filtre décrit ; il localise les utilisateurs dans un environnement AD normal.

Une autre partie de la configuration LDAP qui nécessite également une attention particulière aux détails est les noms distinctifs (DN) requis dans les commandes bind-authenticate-root-dn et base-dn. Elles doivent être entrées exactement comme elles apparaissent dans le serveur LDAP, sinon les requêtes LDAP échouent. En outre, la commande base-dn doit être la partie la plus basse de l'arborescence LDAP, où résident tous les utilisateurs authentifiés.

Considérez le scénario dans lequel la commande base-dn dans la configuration précédente est modifiée comme suit :

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

Dans ce cas, la requête pour les utilisateurs qui sont inclus dans CN=Users,DC=lab,DC=cisco,DC=com ne renvoie aucun résultat, car le serveur LDAP ne recherche que l'unité d'organisation de TestCompany (OU) et les objets enfants qu'il contient. Par conséquent, l'authentification échoue toujours pour ces utilisateurs jusqu'à ce qu'ils soient déplacés dans l'unité d'organisation de TestCompany ou dans sa sous-arborescence, ou si la commande base-dn est modifiée afin de l'inclure dans la requête. 

Astuce : Reportez-vous à la section Déterminer les objets DN dans la section AD - ADSI Edit de ce document pour plus de détails sur la façon de déterminer les DN appropriés pour les commandes de base et racine.

Configurer AAA

Maintenant que les serveurs LDAP sont configurés, vous devez les référencer dans les instructions AAA correspondantes utilisées par le processus d'admission IP :

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

Note: Si ces commandes ne sont pas disponibles, la commande aaa new-model devra peut-être être saisie pour activer cette fonctionnalité AAA car elle n'est pas activée par défaut.

Configurer l'admission IP

La partie Admission IP déclenche un processus qui invite l'utilisateur à s'authentifier (ou qui effectue une authentification transparente), puis exécute des requêtes LDAP en fonction des informations d'identification de l'utilisateur et des serveurs AAA définis dans la configuration. Si les utilisateurs sont authentifiés avec succès, les informations d'identité de l'utilisateur sont ensuite extraites par le processus d'analyse du contenu et envoyées aux tours CWS, ainsi que le flux redirigé. Le processus d'admission IP n'est pas activé tant que la commande ip admission name n'est pas entrée sur l'interface d'entrée du routeur. Par conséquent, cette partie de la configuration peut être implémentée sans aucun impact sur le trafic.

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

Activer l'admission IP

Voici la configuration utilisée pour activer l'admission IP :

Note: Cela force les utilisateurs à être authentifiés, ce qui entraîne l'interruption du flux de trafic en cas d'échec de l'authentification.

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

Exempter les hôtes internes de l'authentification

Certains administrateurs peuvent souhaiter exempter certains hôtes internes du processus d’authentification pour diverses raisons. Par exemple, il peut être indésirable que des serveurs ou des périphériques internes qui ne sont pas capables de NTLM ou d'authentification de base soient affectés par le processus d'admission IP. Dans ces cas, une liste de contrôle d’accès (ACL) peut être appliquée à la configuration d’admission IP afin d’empêcher des adresses IP ou des sous-réseaux hôtes spécifiques de déclencher une admission IP.

Dans cet exemple, l'hôte interne 10.10.10.150 est exempté de la condition d'authentification, alors que l'authentification est toujours requise pour tous les autres hôtes :

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

Activer le serveur HTTP sur le routeur de service intégré

Vous devez activer le serveur HTTP afin d'intercepter les sessions HTTP et d'initier le processus d'authentification :

Ip http server
Ip http secure-server 

Note: Le serveur sécurisé Ip http n'est nécessaire que si une redirection vers HTTPS pour l'authentification est requise.

Configurer la redirection CWS

Voici une configuration récapitulative de base pour la redirection 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

Exemple complet de configuration

Cette section fournit des exemples complets de configuration pour les sections précédentes.

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

Admission 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

Serveur HTTP

ip http server

Analyse de contenu et 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

Déterminer les objets DN dans AD - ADSI Edit

Si nécessaire, il est possible de parcourir une structure AD afin de rechercher des numéros de répertoire à utiliser avec la base de recherche utilisateur ou groupe. Les administrateurs peuvent utiliser un outil appelé ADSI Edit qui est intégré aux contrôleurs de domaine AD. Afin d'ouvrir ADSI Edit, choisissez Start > Run sur le contrôleur de domaine AD et entrez adsiedit.msc.

Une fois ADSI Edit ouvert, cliquez avec le bouton droit de la souris sur un objet, tel qu'une unité d'organisation, un groupe ou un utilisateur, puis sélectionnez Propriétés afin d'afficher le DN de cet objet. La chaîne DN peut ensuite être copiée et collée facilement dans la configuration du routeur afin d'éviter toute erreur typographique. Cette image illustre le processus :

 

Méthodes d'authentification

Il existe quatre types différents de méthodes d'authentification qui utilisent l'Admission IP, et elles sont souvent mal comprises, en particulier la différence entre NTLM transparent et passif. Les sections suivantes décrivent les différences entre ces types d’authentification.

NTLM actif

La méthode d'authentification NTLM active invite les utilisateurs à l'authentification en cas d'échec de l'authentification NTLM transparente. Cela est généralement dû au fait que le navigateur du client ne prend pas en charge l'authentification Microsoft Windows intégrée ou parce que l'utilisateur s'est connecté à la station de travail avec des informations d'identification locales (non-domaine). L'authentification NTLM active effectue des requêtes LDAP vers le contrôleur de domaine afin de s'assurer que les informations d'identification fournies sont correctes.

Note: Avec tous les types d'authentification NTLM, les informations d'identification ne sont pas transmises en texte clair. Cependant, NTLM Version 1 (NTLMv1) présente des vulnérabilités bien documentées. L'ISR est compatible NTLMv2, bien que par défaut, les versions plus anciennes de Microsoft Windows puissent négocier via NTLMv1. Ce comportement dépend des stratégies d'authentification AD.

NTLM transparent

L'authentification NTLM transparente se produit lorsqu'un utilisateur est connecté à la station de travail avec des informations d'identification de domaine et que ces informations d'identification sont transmises de manière transparente par le navigateur au routeur IOS. Le routeur IOS exécute ensuite une requête LDAP afin de valider les informations d'identification de l'utilisateur. Il s'agit généralement de la forme d'authentification la plus souhaitée pour cette fonctionnalité.

Authentification de base (via HTTP en texte clair)

Cette forme d'authentification est généralement utilisée comme mécanisme de secours lorsque l'authentification NTLM échoue ou n'est pas possible pour des clients tels que Macintosh, des périphériques Linux ou des périphériques mobiles. Avec cette méthode, si le serveur HTTP Secure n'est pas activé, ces informations d'identification sont transmises via HTTP en texte clair (très peu sécurisé).

NTLM passif

L'authentification NTLM passive demande des informations d'identification aux utilisateurs mais n'authentifie pas réellement l'utilisateur par rapport au contrôleur de domaine. Bien que cela puisse éviter des problèmes liés à LDAP lorsque les requêtes échouent sur le contrôleur de domaine, cela expose également les utilisateurs de l'environnement à un risque de sécurité. Si l'authentification transparente échoue ou n'est pas possible, les utilisateurs sont invités à fournir des informations d'identification. Cependant, l'utilisateur peut saisir les informations d'identification qu'il choisit, qui sont transmises à la tour CWS. En conséquence, les politiques pourraient ne pas être appliquées de manière appropriée.

Par exemple, l'utilisateur A peut utiliser Firefox (qui par défaut n'autorise pas NTLM transparent sans configuration supplémentaire) et entrer le nom d'utilisateur de l'utilisateur B avec n'importe quel mot de passe, et les stratégies de l'utilisateur B sont appliquées à l'utilisateur A. L'exposition au risque peut être atténuée si les utilisateurs sont tous obligés d'utiliser des navigateurs qui prennent en charge l'authentification NTLM transparente, mais dans la plupart des cas, l'utilisation de l'authentification passive n'est pas recommandée.

Séquence de messages pour l'authentification NTLM active

Voici la séquence de messages complète de la méthode d'authentification NTLM active :

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

Le routeur de service intégré copie le message de type 1 du protocole HTTP vers le protocole LDAP, octet par octet, sans modification des données.

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

Le message Type-2 est également copié octet par octet de LDAP à HTTP. Ainsi, dans le PCAP, il semble provenir du 1.1.1.1, mais le contenu réel provient de la DA.

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

Lorsque NTLM actif est configuré, l'ISR n'interfère pas pendant l'échange NTLM. Cependant, si NTLM passif est configuré, l'ISR génère son propre message de type 2.

Vérification

Aucune procédure de vérification n'est disponible pour cette configuration.

Dépannage

Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.

Commandes show

Note: L'Outil d'interprétation de sortie (clients enregistrés seulement) prend en charge certaines commandes d'affichage. Utilisez l'Outil d'interprétation de sortie afin de visualiser une analyse de commande d'affichage de sortie .

Vous pouvez utiliser ces commandes show afin de dépanner votre configuration :

• show ip admission cache
• show ip admission status
• show ip admission statistics
• show ldap server all

Commandes de débogage

Note: Référez-vous aux informations importantes sur les commandes de débogage avant d'utiliser les commandes de débogage.

Voici quelques commandes de débogage utiles que vous pouvez utiliser pour dépanner votre configuration :

• debug ldap all - Cette commande peut être utilisée afin de découvrir la raison pour laquelle l'authentification échoue.
  
  
• debug ip admission detail - Cette commande est très détaillée et nécessite beaucoup de CPU. Cisco vous recommande de ne l'utiliser qu'avec des clients de test uniques qui déclenchent l'admission IP.
  
  
• debug ip admission ntlm - Cette commande peut être utilisée afin de découvrir la raison pour laquelle le processus d'admission IP est déclenché.
  
  
• debug ip admission httpd
  
  
• debug ip http transaction
  
  
• debug aaa authentication debug aaa autorisation

Problèmes courants

Cette section décrit quelques problèmes courants rencontrés avec la configuration décrite dans ce document.

Admission IP n'intercepte pas les requêtes HTTP

Ce problème devient évident lorsque vous affichez la sortie de la commande show ip admission statistics. Le résultat ne montre pas l'interception d'une requête HTTP :

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

  HTTPd process 1
    Intercepted HTTP requests: 0

Solutions possibles

Il existe deux solutions possibles à ce problème. La première consiste à vérifier que ip http server est activé. 

Si le serveur HTTP du routeur de service intégré n'est pas activé, l'entrée IP déclenche mais n'intercepte jamais la session HTTP. Par conséquent, il demande l'authentification. Dans cette situation, il n'y a aucune sortie pour la commande show ip admission cache, mais de nombreuses récurrences de ces lignes sont visibles dans la sortie de la commande debug ip admission 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 deuxième solution à ce problème consiste à vérifier que l'adresse IP de l'utilisateur n'est pas exempte de la liste de contrôle d'accès dans la configuration IP Admission.

Les utilisateurs reçoivent une erreur 404 introuvable

Ce problème est observé lorsque les utilisateurs sont redirigés pour authentification et qu'une erreur 404 Not Found se produit dans le navigateur.

Solution possible

Assurez-vous que le nom de l'adresse ip admission virtual-ip 1.1.1.1 de l'hôte virtuel ISR_PROXY peut être résolu avec succès avec le serveur DNS (Domain Name System) du client. Dans ce cas, le client effectue une requête DNS pour ISR_PROXY.lab.cisco.com car lab.cisco.com est le nom de domaine complet (FQDN) du domaine auquel la station de travail est jointe. Si la requête DNS échoue, le client envoie une requête LLMNR (Link-Local Multicast Name Resolution), suivie d'une requête NETBIOS qui est diffusée au sous-réseau local. 

Si toutes ces tentatives de résolution échouent, une erreur 404 Not Found or Internet Explorer ne peut pas afficher la page Web s'affiche dans le navigateur. 

Échec de l'authentification utilisateur à la demande

Cela peut être dû à diverses raisons, mais est généralement lié à la configuration LDAP sur l'ISR ou à la communication entre l'ISR et le serveur LDAP. Sur le routeur de service intégré, le symptôme est généralement observé lorsque les utilisateurs sont bloqués à l'état INIT une fois l'entrée IP déclenchée :

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

Causes courantes

Voici les causes courantes de ce problème :

• L'utilisateur entre un nom d'utilisateur et/ou un mot de passe non valides pour l'authentification active.
  
  
• Une base-dn non valide est utilisée dans la configuration LDAP, ce qui entraîne des recherches qui ne retournent aucun résultat.
  
  
• Une authentification de liaison non valide root-dn est configurée pour le nom d'utilisateur ou le mot de passe, ce qui provoque l'échec de la liaison LDAP.
  
  
• La communication entre le routeur de service intégré et le serveur LDAP échoue. Vérifiez que le serveur LDAP écoute sur le port TCP spécifié pour la communication LDAP et que tous les pare-feu entre les deux autorisent le trafic.
  
  
• Un filtre de recherche non valide n'entraîne aucun résultat pour la recherche LDAP.

Dépannage de LDAP

La meilleure façon de déterminer la raison pour laquelle l'authentification échoue est d'utiliser les commandes de débogage LDAP sur l'ISR. Gardez à l'esprit que les débogages peuvent être coûteux et dangereux à exécuter sur un routeur de service intégré s'il y a une sortie excessive, et qu'ils peuvent entraîner le blocage du routeur et nécessiter un cycle de mise sous tension. Ceci est particulièrement vrai pour les plates-formes de bas de gamme. 

Afin de dépanner, Cisco recommande d'appliquer une liste de contrôle d'accès à la règle d'admission IP afin de soumettre une seule station de travail de test du réseau à l'authentification. De cette manière, les débogages peuvent être activés avec un risque minimal d'impact négatif sur la capacité du routeur à transmettre le trafic.

Astuce : Référez-vous à la section Exempter les hôtes internes de l'authentification de ce document pour plus d'informations sur l'application d'une liste de contrôle d'accès à la configuration des admissions IP.

Lorsque vous dépannez des problèmes liés à LDAP, il est utile de comprendre les étapes dans lesquelles LDAP traite les requêtes de l'ISR. 

Étapes de haut niveau pour l'authentification LDAP

Voici les étapes de haut niveau pour l'authentification LDAP :

1. Ouvrez la connexion au serveur LDAP sur le port spécifié. Le port par défaut est TCP 389.
   
   
2. Lier au serveur LDAP avec l'utilisateur et le mot de passe d'authentification de liaison root-dn.
   
   
3. Effectuez la recherche LDAP, avec l'utilisation des filtres base-dn et de recherche définis dans la configuration LDAP, pour l'utilisateur qui tente de s'authentifier.
   
   
4. Obtenir les résultats LDAP du serveur LDAP et créer une entrée de cache d'admission IP pour l'utilisateur si l'authentification réussit, ou demander à nouveau des informations d'identification en cas d'échec de l'authentification.

Analyse de sortie de débogage LDAP

Ces processus peuvent être affichés dans la sortie de la commande debug ldap all. Cette section fournit un exemple de la sortie de débogage LDAP pour une authentification qui échoue en raison d'une base-dn non valide.  Examinez la sortie de débogage et les commentaires associés, qui décrivent les parties de la sortie qui indiquent où les étapes mentionnées ci-dessus peuvent rencontrer un échec.

*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 partie du résultat affichée en gras indique qu'il ne s'agit pas d'un problème de couche réseau, car la connexion est correctement ouverte.

*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

Le Bind authenticate-dn est correct dans cette sortie. Si la configuration est incorrecte pour cela, des échecs de liaison sont visibles. 

*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 partie de la sortie affichée en gras indique que toutes les opérations de liaison ont réussi et qu'elle poursuit la recherche de l'utilisateur réel.

*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 première ligne (affichée en gras) indique que la sortie de débogage de la recherche LDAP commence. Notez également que le contrôleur de domaine base-dn doit être configuré pour lab, et non 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 partie de la sortie affichée en gras indique que la recherche n'a renvoyé aucun résultat, ce qui dans ce cas est dû à un base-dn non valide.

RFC 4511

RFC 4511 (LDAP (Lightweight Directory Access Protocol) : Le protocole) fournit des informations sur les messages de code de résultat pour LDAP et d'autres informations liées au protocole LDAP, qui peuvent être référencées via le site Web IETF.

Historique de révision