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.
Cisco recommande que votre système réponde à ces exigences avant de tenter les configurations décrites dans ce document :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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.
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.
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.
Utilisez les informations décrites dans cette section afin de configurer le routeur de service intégré Cisco.
Complétez ces étapes afin de configurer les propriétés LDAP du ou des serveurs 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
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.
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
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
Voici la configuration utilisée pour activer l'admission IP :
C-881(config)#int vlan301 (internal LAN-facing interface)
C-881(config-if)#ip admission SCANSAFE_ADMISSION
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
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
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
Cette section fournit des exemples complets de configuration pour les sections précédentes.
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
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 :
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.
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.
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é.
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é).
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.
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.
Aucune procédure de vérification n'est disponible pour cette configuration.
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Vous pouvez utiliser ces commandes show afin de dépanner votre configuration :
Voici quelques commandes de débogage utiles que vous pouvez utiliser pour dépanner votre configuration :
Cette section décrit quelques problèmes courants rencontrés avec la configuration décrite dans ce document.
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
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.
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.
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.
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
Voici les causes courantes de ce problème :
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.
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.
Voici les étapes de haut niveau pour l'authentification 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 (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.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
18-Jul-2014 |
Première publication |