La versión 4.0 de AnyConnect y NAC Posture Agent no aparecen en la guía de solución de problemas de ISE
Contenido
Introducción
Identity Services Engine (ISE) proporciona funciones de postura que requieren el uso del agente Network Admission Control (NAC) (para Microsoft Windows, Macintosh o mediante webagent) o AnyConnect versión 4.0. El módulo de estado de ISE de AnyConnect versión 4.0 funciona exactamente igual que el agente NAC y, por lo tanto, en este documento se hace referencia a él como el agente NAC. El síntoma más común de falla de estado para un cliente es que el agente NAC no aparece, ya que un escenario de trabajo siempre hace que la ventana del agente NAC aparezca y analice su PC. Este documento le ayuda a reducir las muchas causas que pueden llevar a que la postura falle, lo que significa que el agente NAC no aparece. No pretende ser exhaustiva, ya que los registros de los agentes NAC solo pueden ser descodificados por el Cisco Technical Assistance Center (TAC) y las posibles causas principales son numerosas; sin embargo, pretende aclarar la situación y señalar el problema más allá de simplemente "el agente no aparece con el análisis de estado" y probablemente le ayudará a resolver las causas más comunes.
Prerequisites
Requirements
Los escenarios, síntomas y pasos enumerados en este documento están escritos para que usted resuelva los problemas después de que la configuración inicial ya se haya completado. Para obtener la configuración inicial, consulte Posture Services en la Guía de configuración de Cisco ISE en Cisco.com.
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- Versión 1.2.x de ISE
- NAC Agent para ISE versión 4.9.x
- AnyConnect versión 4.0
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). If your network is live, make sure that you understand the potential impact of any command.
Metodología de Troubleshooting
¿Qué hace que el agente aparezca?
El agente aparece cuando detecta un nodo ISE. Si el agente detecta que no tiene acceso completo a la red y se encuentra en un escenario de redirección de estado, busca constantemente un nodo ISE.
Hay un documento Cisco.com que explica los detalles del proceso de detección del agente: Proceso de detección del agente de control de admisión a la red (NAC) para Identity Services Engine. Para evitar la duplicación de contenido, este documento solo trata el punto clave.
Cuando un cliente se conecta, se somete a una autenticación RADIUS (filtrado de MAC o 802.1x) al final de la cual, ISE devuelve la lista de control de acceso (ACL) de redirección y la URL de redirección al dispositivo de red (switch, dispositivo de seguridad adaptable (ASA) o controlador inalámbrico) con el fin de restringir el tráfico del cliente para que solo permita obtener una dirección IP y resoluciones de servidor de nombres de dominio (DNS). Todo el tráfico HTTP(S) que proviene del cliente se redirige a una URL única en ISE que termina con CPP (estado y aprovisionamiento del cliente), excepto el tráfico destinado al propio portal de ISE. El agente NAC envía un paquete GET HTTP normal al gateway predeterminado. Si el agente no recibe ninguna respuesta o cualquier otra respuesta que una redirección de CPP, se considera a sí mismo con conectividad completa y no continúa con el estado. Si recibe una respuesta HTTP que es una redirección a una URL de CPP al final de un nodo de ISE específico, continúa el proceso de estado y se pone en contacto con ese nodo de ISE. Solo aparece e inicia el análisis cuando recibe correctamente los detalles de estado de ese nodo de ISE.
El agente NAC también se comunica con la dirección IP del host de detección configurada (no espera que se configure más de una). Espera ser redirigido allí también para obtener la URL de redirección con el ID de sesión. Si la dirección IP de detección es un nodo de ISE, no realiza la detección porque espera a ser redirigida para obtener el ID de sesión correcto. Por lo tanto, el host de detección no suele ser necesario, pero puede ser útil cuando se establece como cualquier dirección IP en el rango de la ACL de redirección para activar una redirección (como en escenarios de VPN, por ejemplo).
Posibles Causas
La redirección no se produce
Esta es la causa más común con diferencia. Para validar o invalidar, abra un navegador en la PC donde el agente no aparezca y vea si se le redirige a la página de descarga del agente de estado cuando escribe cualquier URL. También puede escribir una dirección IP aleatoria como http://1.2.3.4 para evitar un posible problema de DNS (si una dirección IP redirige pero el nombre de un sitio web no, puede ver DNS).
Si se le redirige, debe recopilar los registros de los agentes y el paquete de soporte de ISE (con el módulo de estado y suizo en modo de depuración) y ponerse en contacto con el TAC de Cisco. Esto indica que el agente detecta un nodo ISE, pero se produce un error durante el proceso para obtener los datos de estado.
Si no ocurre ninguna redirección, tiene su primera causa, que aún requiere una investigación adicional de la causa raíz. Un buen comienzo es comprobar la configuración del dispositivo de acceso a la red (controlador de LAN inalámbrica (WLC) o switch) y pasar al siguiente elemento de este documento.
Los atributos no están instalados en el dispositivo de red
Este problema es un subcaso del escenario La redirección no ocurre. Si no se produce la redirección, lo primero es comprobar (ya que el problema se produce en un cliente determinado) que el switch o la capa de acceso inalámbrico han colocado correctamente al cliente en el estado correcto.
Aquí hay un ejemplo de salida del comando show access-session interface <número de interfaz> detail (es posible que tenga que agregar detalle al final de algunas plataformas) tomado en el switch donde está conectado el cliente. Debe verificar que el estado sea "Éxito de autenticación", que la ACL de redirección URL apunte correctamente a la ACL de redirección deseada y que la redirección URL apunte al nodo ISE esperado con CPP al final de la URL. El campo ACL de ACS no es obligatorio porque solo se muestra si ha configurado una lista de acceso descargable en el perfil de autorización en ISE. Sin embargo, es importante verlo y verificar que no haya conflicto con la ACL de redirección (consulte los documentos sobre la configuración de la postura en caso de duda).
01-SW3750-access#show access-sess gi1/0/12 det
Interface: GigabitEthernet1/0/12
MAC Address: 000f.b049.5c4b
IP Address: 192.168.33.201
User-Name: 00-0F-B0-49-5C-4B
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-myDACL-51519b43
URL Redirect ACL: redirect
URL Redirect: https://ISE2.wlaaan.com:8443/guestportal/gateway?
sessionId=C0A82102000002D8489E0E84&action=cpp
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A82102000002D8489E0E84
Acct Session ID: 0x000002FA
Handle: 0xF60002D9
Runnable methods list:
Method State
mab Authc Success
Para resolver problemas de un WLC que ejecuta AireOS, ingrese show wireless client detail <mac address> e ingrese show wireless client mac-address <mac address> detail para resolver problemas de un WLC que ejecuta Cisco IOS-XE. Se muestran datos similares y debe verificar la URL de redirección y la ACL y si el cliente está en estado "POSTURE_REQD" o similar (varía según la versión de software).
Si los atributos no están presentes, debe abrir los detalles de autenticación en el ISE del cliente que estaba resolviendo el problema (navegue hasta Operaciones > Autenticaciones) y verificar en la sección Resultado que se enviaron los atributos de redirección. Si no se enviaron, debe revisar la directiva de autorización para comprender por qué no se devolvieron los atributos para este cliente en particular. Probablemente una de las condiciones no coincidía, por lo que es una buena idea solucionarlas una a una.
Recuerde que, en lo que respecta a la ACL de redirección, Cisco IOS® redirige las sentencias de permiso (por lo que las direcciones IP de ISE y DNS deben ser denegadas) mientras que AireOS en el WLC redirige las sentencias de denegación (por lo que está permitido para ISE y DNS).
Los atributos están en su lugar pero el dispositivo de red no redirige
La causa principal en este caso es un problema de configuración. Debe revisar la configuración del dispositivo de red comparándola con la guía de configuración y los ejemplos de configuración en Cisco.com. Si este es el caso, el problema suele existir en todos los puertos o puntos de acceso (AP) del dispositivo de red. Si no es así, el problema podría ocurrir solamente en algunos puertos de switch o algunos AP. Si este es el caso, debe comparar la configuración de aquellos donde ocurre el problema en comparación con los puertos o AP donde la postura funciona bien.
Los AP de FlexConnect son sensibles porque cada uno puede tener una configuración única y es fácil cometer un error en una ACL o una VLAN en algunos AP y no en otros.
Otro problema común es que la VLAN del cliente no tiene una SVI. Esto solo se aplica a los switches y se analiza en detalle en ISE Traffic Redirection on the Catalyst 3750 Series Switch. Todo puede verse bien desde la perspectiva de los atributos.
Interferir en la lista de acceso descargable (DACL)
Si, al mismo tiempo que los atributos de redirección, vuelve a colocar una DACL en el switch (o Airespace-ACL para un controlador inalámbrico), podría bloquear su redirección. La DACL se aplica en primer lugar y determina lo que se descarta completamente y lo que se procesa. A continuación, se aplica la ACL de redirección y determina qué se redirige.
Esto significa concretamente que la mayoría de las veces, querrá permitir todo el tráfico HTTP y HTTPS en su DACL. Si lo bloquea, no se redirigirá, ya que se eliminará antes. No supone un problema de seguridad, ya que el tráfico se redirigirá principalmente en la ACL de redirección después de, por lo que en realidad no está permitido en la red; sin embargo, debe permitir esos dos tipos de tráfico en la DACL para que tengan la oportunidad de acceder a la ACL de redirección inmediatamente después.
Versión del agente NAC incorrecta
Es fácil olvidar que las versiones específicas de los agentes de NAC se validan frente a versiones específicas de ISE. Muchos administradores actualizan su clúster de ISE y se olvidan de cargar la versión del agente NAC relacionada en la base de datos de resultados de aprovisionamiento de clientes.
Si utiliza una versión de agente de NAC obsoleta para el código ISE, tenga en cuenta que puede funcionar, pero también puede que no. Por lo tanto, no es de extrañar que algunos clientes trabajen y otros no. Una forma de verificarlo es ir a la sección de descargas Cisco.com de su versión de ISE y comprobar qué versiones de agentes NAC existen. Normalmente, hay varias versiones compatibles con cada ISE. Esta página web recopila todas las matrices: Información de compatibilidad de Cisco ISE.
El proxy web HTTP está siendo utilizado por los clientes
El concepto de proxy web HTTP es que los clientes no resuelven las direcciones IP de DNS del sitio web por sí mismos ni se ponen en contacto con los sitios web directamente; en lugar de ello, simplemente envían su solicitud al servidor proxy, que se encarga de ello. El problema típico con una configuración habitual es que el cliente resuelve un sitio web (como www.cisco.com) enviando directamente el HTTP GET para él al proxy, que se intercepta y se redirige correctamente al portal ISE. Sin embargo, en lugar de enviar el siguiente HTTP GET a la dirección IP del portal de ISE, el cliente continúa enviando esa solicitud al proxy.
En caso de que decida no redirigir el tráfico HTTP destinado al proxy, los usuarios tendrán acceso directo a Internet (ya que todo el tráfico pasa a través del proxy) sin autenticación ni postura. La solución consiste en modificar la configuración del navegador de los clientes y agregar una excepción para la dirección IP de ISE en la configuración de proxy. De este modo, cuando el cliente tiene que acceder a ISE, envía la solicitud directamente a ISE y no al proxy. Esto evita el loop infinito donde el cliente constantemente es redirigido pero nunca ve la página de login.
Tenga en cuenta que el agente NAC no se ve afectado por la configuración de proxy introducida en el sistema y continúa funcionando con normalidad. Esto significa que si utiliza un proxy web, no puede hacer que la detección de agentes NAC funcione (porque utiliza el puerto 80) y que los usuarios autoinstalen el agente una vez que se les redirija a la página de estado cuando naveguen (ya que utiliza el puerto proxy y los switches típicos no pueden redirigir en varios puertos).
Los hosts de detección se configuran en el agente NAC
Especialmente después de la versión 1.2 de ISE, se recomienda no configurar ningún host de detección en el agente NAC a menos que tenga experiencia en lo que hace y no hace. Se supone que el agente NAC debe detectar el nodo ISE que autenticó el dispositivo cliente a través de la detección HTTP. Si confía en los hosts de detección, puede hacer que el agente NAC se ponga en contacto con otro nodo de ISE distinto del que autenticó el dispositivo y que no funciona. La versión 1.2 de ISE rechaza un agente que detecta el nodo a través del proceso de detección de host porque desea que el agente NAC obtenga el ID de sesión de la URL de redirección, por lo que no se recomienda este método.
En algunos casos, es posible que desee configurar un host de detección. Luego, debe configurarse con cualquier dirección IP (incluso si no existe) que será redirigida por la ACL de redirección, y lo ideal sería que no esté en la misma subred que el cliente (de lo contrario, el cliente ARP indefinidamente para él y nunca enviar el paquete de detección HTTP).
El agente NAC no aparece a veces
Cuando el problema es más intermitente y acciones como desconectar/volver a conectar la conectividad cable/wifi hacen que funcione, es un problema más sutil. Podría ser un problema con los ID de sesión de RADIUS donde el ID de sesión se elimina en el ISE mediante la contabilidad RADIUS (desactive la contabilidad para ver si cambia algo).
Si utiliza ISE Versión 1.2, otra posibilidad es que el cliente envíe muchos paquetes HTTP para que ninguno provenga de un navegador o del agente NAC. La versión 1.2 de ISE analiza el campo user-agent en los paquetes HTTP para ver si proviene del agente NAC o de un navegador, pero muchas otras aplicaciones envían tráfico HTTP con un campo user-agent y no mencionan ningún sistema operativo ni información útil. A continuación, la versión 1.2 de ISE envía un cambio de autorización para desconectar al cliente. La versión 1.3 de ISE no se ve afectada por este problema porque funciona de una manera diferente. La solución consiste en actualizar a la versión 1.3 o permitir todas las aplicaciones detectadas en la ACL de redirección para que no se redireccionen hacia ISE.
Problema inverso: el agente aparece varias veces
El problema opuesto puede surgir cuando el agente aparece, realiza el análisis de estado, valida al cliente y luego aparece de nuevo poco después en lugar de permitir la conectividad de red y permanecer en silencio. Esto sucede porque, incluso después de una postura correcta, el tráfico HTTP se sigue redirigiendo al portal CPP en ISE. Es una buena idea pasar a través de la política de autorización de ISE y comprobar que tiene una regla que envía un permiso de acceso (o una regla similar con posibles ACL y VLAN) cuando ve un cliente compatible y NO una redirección de CPP de nuevo.
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
30-Jan-2015 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)