Admissions et LDAP IP ISR pour la redirection de Web à ScanSafe/à exemple de configuration sécurité Web de nuage
Contenu
Introduction
Ce document décrit comment configurer les Integrated Services Router de gamme Cisco G2 (ISR). Tandis que la configuration d'ip admission et de Protocole LDAP (Lightweight Directory Access Protocol) peut être utilisée simplement pour le Seveur mandataire d'authentification sur l'ISR, elle est typiquement utilisée en même temps que la caractéristique de redirection de la sécurité Web de nuage de Cisco (CWS). En soi, ce document est destiné pour être une référence afin de compléter la documentation de configuration et de dépannage de redirection CWS sur des ISR.
Conditions préalables
Conditions requises
Cisco recommande que votre rassemblement de système ces conditions requises avant que vous tentiez les configurations qui sont décrites dans ce document :
- L'ISR doit exécuter la version 15.2(1)T1 ou ultérieures de code.
- Votre système doit avoir les images avec le permis (sec) réglé par fonctionnalité de sécurité qui sont disponibles dans le Cisco IOS® (universel).
- Le poste de travail de client sur le domaine de Répertoire actif (AD) doit avoir la capacité pour exécuter l'authentification active par l'intermédiaire d'un navigateur Web.
- Vous devez avoir un abonnement CWS.
Composants utilisés
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 (exige la configuration supplémentaire pour l'authentification transparente du LAN Manager de NT (NTLM))
- Cisco G2 800, 1900, 2900, et gamme 3900 ISR.
- Contrôleur de domaine d'AD de Microsoft Windows (ADDC)
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Informations générales
Beaucoup d'administrateurs qui installent la gamme Cisco G2 ISR qui n'ont pas les appliances de sécurité adaptable Cisco (ASA) dans leurs réseaux choisissent d'utiliser la fonctionnalité de redirection ISR CWS (autrefois ScanSafe) afin de tirer profit de la solution CWS pour le filtrage de Web. En tant qu'élément de cette solution, la plupart des administrateurs veulent également utiliser l'infrastructure en cours d'AD afin d'envoyer les informations d'identité de l'utilisateur aux towers CWS aux fins de l'application basée sur groupe d'utilisateur ou de stratégie pour les stratégies de filtrage de Web dans le portail CWS.
Le concept global est semblable à l'intégration entre l'ASA et l'agent de répertoire de contexte (CDA), avec quelques différences. La différence la plus notable est que l'ISR ne met pas à jour réellement une base de données passive du mappage utilisateur-à-IP, ainsi les utilisateurs doivent traverser un certain type d'authentification afin de transiter l'ISR et envoyer l'utilisateur ou l'information du groupe au portail CWS.
Tandis que la partie de redirection CWS de la configuration qui est décrite dans ce document est relativement simple, quelques administrateurs pourraient rencontrer la difficulté avec des tentatives de configurer la partie d'authentification. Cette partie fonctionne avec la commande d'ip admission qui met en référence les instuctions d'authentification de serveurs LDAP et d'Authentification, autorisation et comptabilité (AAA) qui doivent également être configurées. Le but de ce document est de fournir à des opérateurs réseau une source de référence complète afin de configurer ou dépanner les admissions IP et les parties de LDAP de cette configuration sur la gamme Cisco G2 ISR.
Configurez
Utilisez les informations qui sont décrites dans cette section afin de configurer Cisco ISR.
Diagramme du réseau
Configurez le LDAP
Terminez-vous ces étapes afin de configurer les propriétés de LDAP des serveurs d'AAA :
- Configurez une carte d'attribut de LDAP afin de forcer le nom d'utilisateur qui est écrit par l'utilisateur pour apparier la propriété de 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
La commande d'attributs de show ldap peut également être utilisée afin de visualiser une liste des attributs de LDAP et des attributs associés d'AAA. - Configurez le groupe de serveur LDAP :
C-881(config)#aaa group server ldap LDAP_GROUP
C-881(config-ldap-sg)#server DC01 - 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 généralement n'exige pas la modification, à moins qu'il y ait un besoin d'implémenter un recherche-filtre fait sur commande. Seulement les administrateurs qui sont bien-versés dans le LDAP et savent entrer correctement ces informations devraient utiliser les filtres faits sur commande de recherche. Si vous êtes incertain au sujet du filtre de recherche qui devrait être utilisé, utilisez simplement le filtre décrit ; il localise les utilisateurs dans un environnement normal d'AD.
Une autre partie de la configuration de LDAP qui exige également l'attention aux détails particulière est les noms uniques (dn) qui sont exigés dans les commandes de grippage-authentifier-racine-dn et de base-dn. Ceux-ci doivent être entrés exactement pendant qu'ils apparaissent dans le serveur LDAP, ou les requêtes de LDAP échouent. En outre, la commande de base-dn doit être la partie la plus inférieure de l'arborescence de LDAP, où tous les utilisateurs qui sont authentifiés résident.
Considérez le scénario dans lequel la commande de base-dn dans la configuration précédente est modifiée comme ceci :
base-dn OU=TestCompany,DC=lab,DC=cisco,DC=com
Dans ce cas, la requête pour les utilisateurs qui sont inclus dans le CN=Users, DC=lab, DC=cisco, DC=com ne renvoie aucun résultat, puisque le serveur LDAP recherche seulement l'unité organisationnelle de TestCompany (OU) et les objets d'enfant dans elle. En conséquence, l'authentification échoue toujours pour utilisateurs jusqu'à ce qu'ils soient entrés dans l'OU de TestCompany ou son sous-arbre, ou si la commande de base-dn est modifiée afin de l'inclure dans la requête.
Configurez l'AAA
Maintenant que les serveurs LDAP sont configurés, vous devez les mettre en référence dans les instructions AAA correspondantes qui sont utilisées par le processus d'ip admission :
C-881(config)#aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
C-881(config)#aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
Configurez l'ip admission
La partie d'ip admission déclenche un processus qui incite l'utilisateur pour l'authentification (ou exécute l'authentification transparente) et puis exécute des requêtes de LDAP basées sur les identifiants utilisateurs et les serveurs d'AAA qui sont définis dans la configuration. Si les utilisateurs sont authentifiés avec succès, les informations d'identité de l'utilisateur sont alors tirées par le processus de contenu-balayage et envoyées aux towers CWS, avec l'écoulement réorienté. Le processus d'ip admission n'est pas lancé jusqu'à ce que la commande d'ip admission name soit sélectionnée sur l'interface d'entrée du routeur. Par conséquent, cette partie de la configuration peut être mise en application sans n'importe quelle incidence du 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
Ip admission d'enable
Voici la configuration qui est utilisée afin d'activer l'ip admission :
C-881(config)#int vlan301 (internal LAN-facing interface)
C-881(config-if)#ip admission SCANSAFE_ADMISSION
Hôtes internes exempts de l'authentification
Quelques administrateurs pourraient désirer exempter quelques hôtes internes de la procédure d'authentification pour différentes raisons. Par exemple, il pourrait être indésirable pour les serveurs internes ou les périphériques qui ne sont pas capables de NTLM ou d'authentification de base à affecter par le processus d'admissions IP. Dans ces exemples, une liste de contrôle d'accès (ACL) peut être appliquée à la configuration d'ip admission afin d'empêcher l'hôte spécifique IPS ou les sous-réseaux de déclencher l'ip admission.
Dans cet exemple, l'hôte interne 10.10.10.150 est exempt de la condition requise de l'authentification, alors que l'authentification est encore exigée pour tous 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
Activez le serveur HTTP sur l'ISR
On l'exige que vous permettez au serveur HTTP afin d'intercepter les sessions de HTTP et initier la procédure d'authentification :
Ip http server
Ip http secure-server
Configurez 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
Configuration d'échantillon complète
Cette section fournit des exemples de configuration complets 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
Ip admission
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
Contenu-balayage 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éterminez les objets de DN dans l'AD - ADSI éditent
Si nécessaire, il est possible de parcourir des dn d'une consultation de structure d'AD pour l'usage avec la base d'utilisateur ou de recherche de groupe. Les administrateurs peuvent utiliser un outil appelé l'ADSI éditent qui est construit dans des contrôleurs de domaine d'AD. Afin d'ouvrir ADSI éditez, choisissez le Start > Run sur le contrôleur de domaine d'AD et écrivez adsiedit.msc.
Une fois qu'ADSI Edit est ouvert, cliquez avec le bouton droit n'importe quel objet, tel qu'une OU, groupe, ou utilisateur, et choisissez Properties afin de visualiser le DN de cet objet. La chaîne de DN peut alors être facilement copiée et collée à la configuration de routeur afin d'éviter toutes les erreurs typographiques. Cette image illustre le processus :
Méthodes d'authentification
Il y a quatre types différents de méthodes d'authentification disponibles qui utilisent l'ip admission, et ils sont souvent mal compris, particulièrement 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 active NTLM incite des utilisateurs pour l'authentification quand l'authentification transparente NTLM échoue. C'est habituellement dû au fait que le navigateur de client ne prend en charge pas l'authentification intégrée de Microsoft Windows ou parce que l'utilisateur s'est connecté dans le poste de travail avec les qualifications locales (de non-domaine). L'authentification active NTLM exécute des requêtes de LDAP au contrôleur de domaine afin de s'assurer que les qualifications fournies sont correctes.
NTLM transparent
L'authentification transparente NTLM se produit quand un utilisateur est enregistré dans le poste de travail avec des qualifications de domaine, et ces qualifications sont passées d'une manière transparente par le navigateur au routeur IOS. Le routeur IOS exécute alors une requête de LDAP afin de valider les identifiants utilisateurs. C'est généralement la forme d'authentification la plus désirée pour cette caractéristique.
Authentification de base (par l'intermédiaire du HTTP en texte clair)
Cette forme d'authentification est typiquement utilisée comme mécanisme de repli quand l'authentification NTLM échoue ou n'est pas possible aux clients tels que des périphériques de Macintosh, de Linux, ou des périphériques mobiles. Avec cette méthode, si le serveur sécurisé de HTTP n'est pas activé, puis ces qualifications sont passées par l'intermédiaire du HTTP en texte clair (très non sécurisé).
NTLM passif
Les qualifications passives de demandes d'authentification NTLM des utilisateurs mais n'authentifie pas réellement l'utilisateur contre le contrôleur de domaine. Tandis que ceci peut éviter des problèmes liés à la LDAP où les requêtes échouent contre le contrôleur de domaine, il expose également des utilisateurs dans l'environnement à un risque de sécurité. Si l'authentification transparente échoue ou n'est pas possible, alors les utilisateurs sont incités pour des qualifications. Cependant, l'utilisateur peut entrer dans toutes les qualifications qu'ils choisissent, qui sont passés au tower CWS. En conséquence, des stratégies ne pourraient pas être appliquées convenablement.
Par exemple, l'utilisateur A peut utiliser Firefox (qui par défaut ne permet pas NTLM transparent sans configuration supplémentaire) et écrire le nom d'utilisateur de l'utilisateur B avec n'importe quel mot de passe, et les stratégies pour l'utilisateur B sont appliquées à l'utilisateur R. L'exposition de risque peut être atténuée si des utilisateurs tous sont forcés pour utiliser les navigateurs qui prennent en charge l'authentification transparente NTLM, mais dans la plupart des cas, l'utilisation de l'authentification passive n'est pas recommandée.
Ordre de message pour l'authentification active NTLM
Voici l'ordre de message complet pour la méthode d'authentification active NTLM :
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
L'ISR copie le message de type 1 du HTTP sur le LDAP, octet-par-octet sans n'importe quelle modification de données.
ISR <-- AD : LDAP Bind Response + NTLM Type-2 msg
Browser <-- ISR : 401 Unauthorized + NTLM Type-2 msg
Le message de type-2 est également copié octet-par-octet de LDAP sur le HTTP. Ainsi, dans le PCAP, il semble provenir de 1.1.1.1, mais le contenu réel est de l'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
Quand NTLM actif est configuré, l'ISR ne gêne pas pendant l'échange NTLM. Cependant, si NTLM passif est configuré, puis l'ISR génère son propre message de type-2.
Vérifiez
Aucune procédure de vérification n'est disponible pour cette configuration.
Dépannez
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Commandes show
Vous pouvez employer ces commandes show afin de dépanner votre configuration :
- cache de show ip admission
- état de show ip admission
- statistiques de show ip admission
- serveur tout de show ldap
Commandes de débogage
Voici quelques commandes de débogage utiles que vous pouvez employer afin de dépanner votre configuration :
- mettez au point le LDAP entièrement que cette commande peut être utilisée afin de découvrir la raison pour laquelle l'authentification échoue.
- mettez au point le détail d'ip admission - Cette commande est très bavarde et CPU-intensive. Cisco recommande que vous l'utilisiez seulement avec les clients simples de test qui déclenchent l'ip admission.
- mettez au point le ntlm d'ip admission - Cette commande peut être utilisée afin de découvrir la raison pour laquelle le processus d'ip admission est déclenché.
- mettez au point le httpd d'ip admission
- debug ip http transaction
- autorisation de debug aaa de debug aaa authentication
Problèmes courants
Cette section décrit quelques problèmes courants qui sont produits avec la configuration décrite dans ce document.
L'ip admission n'intercepte pas des demandes de HTTP
Cette question devient évidente quand vous visualisez la sortie de commande de statistiques de show ip admission. La sortie n'affiche pas l'interception d'aucune demande de HTTP :
C-881#show ip admission statistics
Webauth HTTPd statistics:
HTTPd process 1
Intercepted HTTP requests: 0
Solutions possibles
Il y a deux solutions possibles à cette question. Le premier est de vérifier que l'ip http server est activé.
Si le serveur HTTP pour l'ISR n'est pas activé, alors les déclencheurs d'ip admission mais intercepte jamais réellement la session de HTTP. Par conséquent, il incite pour l'authentification. Dans cette situation, il n'y a aucune sortie pour la commande de cache de show ip admission, mais beaucoup de récurrences de ces lignes sont vues dans la sortie de la commande de détail d'ip admission de débogage :
*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 à cette question est de vérifier que l'adresse IP d'utilisateur n'est pas exempte de l'ACL dans la configuration d'ip admission.
Les utilisateurs reçoivent une erreur 404 non trouvée
Cette question est observée quand des utilisateurs sont réorientés pour l'authentification, et une erreur 404 non trouvée se produit dans le navigateur.
Solution possible
Assurez-vous que le nom dans le serveur virtuel ISR_PROXY virtuel-IP 1.1.1.1 d'ip admission peut avec succès le résoudre avec le serveur de Système de noms de domaine (DNS) de client. Dans ce cas, le client exécute une requête DNS pour ISR_PROXY.lab.cisco.com puisque lab.cisco.com est le nom de domaine complet (FQDN) du domaine auquel le poste de travail est joint. Si la requête DNS échoue, le client envoie une requête de la résolution de noms de Multidiffusion de Lien-gens du pays (LLMNR), suivie d'une requête de NETBIOS qui est émission au sous-réseau local.
Si toutes ces tentatives de résolution échouent, alors des 404 non trouvés ou l'Internet Explorer ne peuvent pas afficher l'erreur de page Web est affichés dans le navigateur.
L'authentification de l'utilisateur échoue une fois incitée
Ceci peut sont provoqué par par de diverses raisons mais sont habituellement liés à la configuration de LDAP sur l'ISR, ou à la transmission entre l'ISR et le serveur LDAP. Sur l'ISR, on observe généralement le symptôme quand des utilisateurs sont coincés dans l'état Init une fois que l'ip admission est déclenché :
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 classiques
Ce sont les causes classiques pour cette question :
- Un nom d'utilisateur et/ou un mot de passe non valides est entré par l'utilisateur pour l'authentification active.
- Un base-dn non valide est utilisé dans la configuration de LDAP, qui a comme conséquence les recherches qui ne renvoient aucun résultat.
- Un racine-dn non valide d'authentification de grippage est configuré pour le nom d'utilisateur ou mot de passe, qui fait échouer le grippage de LDAP.
- La transmission entre l'ISR et le serveur LDAP échoue. Vérifiez que le serveur LDAP écoute sur le port TCP spécifié la transmission de LDAP et que tous les Pare-feu entre les deux permettent le trafic.
- Un filtre non valide de recherche n'entraîne aucun résultat pour la recherche de LDAP.
Dépannez le LDAP
La meilleure manière de déterminer la raison pour laquelle l'authentification échoue est d'utiliser les commandes de débogage de LDAP sur l'ISR. Maintenez dans l'esprit qui met au point peut être cher et dangereux de s'exécuter sur un ISR s'il y a sortie excessive, et ils peuvent faire arrêter et avoir besoin le routeur d'un arrêt et redémarrage dur. Cela vaut particulièrement pour les Plateformes plus bas de gamme.
Afin de dépanner, Cisco recommande que vous vous appliquiez un ACL à la règle d'ip admission afin de soumettre seulement un poste de travail simple de test sur le réseau à l'authentification. De cette façon, met au point peut être activée avec un risque minimal d'incidence négative à la capacité du routeur de passer le trafic.
Quand vous dépannez des problèmes liés à la LDAP, il est utile de comprendre les étapes dans lesquelles le LDAP traite des demandes de l'ISR.
Étapes de haut niveau pour l'authentification LDAP
Voici les étapes de haut niveau pour l'authentification LDAP :
- Ouvrez la connexion au serveur LDAP sur le port spécifié. Le port par défaut est le TCP 389.
- Le grippage au serveur LDAP avec le grippage authentifient l'utilisateur et le mot de passe de racine-dn.
- Exécutez la recherche de LDAP, avec l'utilisation du base-dn et des recherche-filtres qui sont définis dans la configuration de LDAP, pour l'utilisateur qui tente d'authentifier.
- Obtenez les résultats de LDAP du serveur LDAP et créez une entrée de cache d'ip admission pour l'utilisateur si l'authentification est réussie, ou le reprompt pour des qualifications en cas d'un échec d'authentification.
Analyse de sortie de débogage de LDAP
Ces processus peuvent être visualisés dans la sortie du LDAP de débogage toute la commande. Cette section fournit un exemple de la sortie de débogage de LDAP pour une authentification qui échoue en raison d'un base-dn non valide. Passez en revue la sortie de débogage et les commentaires associés, qui décrivent les parties de la sortie qui affichent où les étapes mentionnées ci-dessus pourraient rencontrer la panne.
*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 présenté en gras indique que ce n'est pas une question de couche réseau, puisque la la connexion est avec succès 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
L'authentifier-dn de grippage est correct dans cette sortie. Si la configuration est incorrecte pour ceci, alors des pannes de grippage sont vues.
*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 du résultat présenté en gras indique que toutes les exécutions de grippage sont réussies et il poursuit pour rechercher 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 recherche de LDAP commence. En outre, notez que le contrôleur de domaine de base-dn devrait être configuré pour le laboratoire, pas 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 du résultat présenté en gras indique que la recherche n'a renvoyé aucun résultat, qui est dans ce cas due à un base-dn non valide.
RFC 4511
RFC 4511 (Protocole LDAP (Lightweight Directory Access Protocol) : Protocol) fournit les informations sur les messages de code de résultat pour le LDAP et d'autres informations liées à la Protocol de LDAP, qui peuvent être mises en référence par l'intermédiaire du site Web IETF.
CommentairesLaissez-nous vous aider
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)