AnyConnect Version 4.0 und NAC Posture Agent erscheinen nicht im ISE-Fehlerbehebungshandbuch
Inhalt
Einleitung
Identity Services Engine (ISE) bietet Statusfunktionen, die die Verwendung des Network Admission Control (NAC)-Agenten (für Microsoft Windows, Macintosh oder über den Webagent) oder der AnyConnect Version 4.0 erfordern. Das ISE-Statusmodul AnyConnect Version 4.0 funktioniert genau wie der NAC-Agent und wird daher in diesem Dokument als NAC-Agent bezeichnet. Das häufigste Symptom eines Statusfehlers für einen Client ist, dass der NAC-Agent nicht angezeigt wird, da ein funktionierendes Szenario immer dazu führt, dass das Fenster des NAC-Agenten geöffnet wird und Ihren PC analysiert. Dieses Dokument hilft Ihnen, die vielen Ursachen einzugrenzen, die zum Fehlschlagen des Status führen können. Das bedeutet, dass der NAC-Agent nicht angezeigt wird. Sie soll nicht vollständig sein, da die NAC-Agentenprotokolle nur vom Cisco Technical Assistance Center (TAC) entschlüsselt werden können und die möglichen Ursachen zahlreich sind. Sie zielt jedoch darauf ab, die Situation zu klären und das Problem genauer zu bestimmen, als nur "der Agent wird mit der Statusanalyse nicht angezeigt". Dies wird Ihnen wahrscheinlich helfen, die häufigsten Ursachen zu lösen.
Voraussetzungen
Anforderungen
Die in diesem Dokument aufgeführten Szenarien, Symptome und Schritte dienen dazu, Probleme zu beheben, nachdem die Ersteinrichtung bereits abgeschlossen ist. Weitere Informationen zur Erstkonfiguration finden Sie unter Posture Services im Cisco ISE-Konfigurationsleitfaden unter Cisco.com.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- ISE Version 1.2.x
- NAC Agent für ISE Version 4.9.x
- AnyConnect Version 4.0
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.
Methodik der Fehlerbehebung
Warum wird der Agent angezeigt?
Der Agent wird angezeigt, wenn ein ISE-Knoten erkannt wird. Wenn der Agent erkennt, dass er nicht über vollständigen Netzwerkzugriff verfügt, und sich in einem Statusumleitungsszenario befindet, sucht er ständig nach einem ISE-Knoten.
Es gibt ein Dokument unter Cisco.com, in dem die Details des Agent Discovery-Prozesses erläutert werden: Network Admission Control (NAC) Agent Discovery Process for Identity Services Engine. Um eine Duplizierung von Inhalten zu vermeiden, wird in diesem Dokument nur auf den Kernpunkt eingegangen.
Wenn ein Client eine Verbindung herstellt, durchläuft er eine RADIUS-Authentifizierung (MAC-Filterung oder 802.1x), an deren Ende die ISE die Umleitungszugriffskontrollliste (ACL) und die Umleitungs-URL an das Netzwerkgerät (Switch, Adaptive Security Appliance (ASA) oder Wireless-Controller) zurückgibt, um den Client-Datenverkehr so einzuschränken, dass er nur eine IP-Adresse und DNS-Auflösungen (Domain Name Server) erhalten kann. Sämtlicher HTTP(S)-Datenverkehr, der vom Client stammt, wird an eine eindeutige URL auf der ISE umgeleitet, die mit CPP (Client Posture and Provisioning) endet, mit Ausnahme des Datenverkehrs, der an das ISE-Portal selbst gerichtet ist. Der NAC-Agent sendet ein reguläres HTTP GET-Paket an das Standard-Gateway. Wenn der Agent keine oder eine andere Antwort als eine CPP-Umleitung erhält, geht er davon aus, dass er über eine vollständige Anbindung verfügt, und fährt nicht mit dem Statusüberprüfung fort. Wenn er eine HTTP-Antwort erhält, die eine Umleitung zu einer CPP-URL am Ende eines bestimmten ISE-Knotens ist, setzt er den Statusprozess fort und kontaktiert diesen ISE-Knoten. Er wird nur angezeigt und startet die Analyse, wenn er die Statusdetails von diesem ISE-Knoten erfolgreich erhält.
Der NAC Agent wendet sich auch an die konfigurierte IP-Adresse des Ermittlungshosts (es wird nicht erwartet, dass mehr als eine konfiguriert wird). Es erwartet, dass auch dort umgeleitet wird, um die Umleitungs-URL mit der Sitzungs-ID zu erhalten. Wenn es sich bei der Ermittlungs-IP-Adresse um einen ISE-Knoten handelt, wird dieser nicht weiterverfolgt, da er auf die Umleitung wartet, um die richtige Sitzungs-ID zu erhalten. Daher wird der Erkennungshost normalerweise nicht benötigt, kann jedoch nützlich sein, wenn er als eine beliebige IP-Adresse im Bereich der Umleitungs-ACLs festgelegt wird, um eine Umleitung auszulösen (z. B. in VPN-Szenarien).
Mögliche Ursachen
Umleitung findet nicht statt
Dies ist bei weitem die häufigste Ursache. Öffnen Sie zur Validierung oder Ungültigerklärung einen Browser auf dem PC, in dem der Agent nicht angezeigt wird, und prüfen Sie, ob Sie bei Eingabe einer URL zur Download-Seite des Statusagenten weitergeleitet werden. Sie können auch eine zufällige IP-Adresse wie http://1.2.3.4 eingeben, um ein mögliches DNS-Problem zu vermeiden (wenn eine IP-Adresse umgeleitet wird, ein Website-Name jedoch nicht, können Sie sich DNS ansehen).
Wenn Sie umgeleitet werden, sollten Sie die Agentenprotokolle und das ISE-Supportpaket (mit Statusmodul und Schweizer Modul im Debugmodus) erfassen und sich an Cisco TAC wenden. Dies weist darauf hin, dass der Agent einen ISE-Knoten erkennt, während des Prozesses zum Abrufen der Statusdaten jedoch ein Fehler auftritt.
Wenn keine Umleitung erfolgt, haben Sie Ihre erste Ursache, die noch weitere Untersuchungen der Ursache erfordert. Ein guter Anfang ist, die Konfiguration auf dem Netzwerkzugriffsgerät (Wireless LAN Controller (WLC) oder Switch) zu überprüfen und mit dem nächsten Eintrag in diesem Dokument fortzufahren.
Attribute werden nicht auf dem Netzwerkgerät installiert
Dieses Problem ist eine Unterart des Szenarios "Umleitung wird nicht ausgeführt". Wenn die Umleitung nicht stattfindet, muss zuerst überprüft werden (wenn das Problem auf einem bestimmten Client auftritt), ob der Client vom Switch oder Wireless Access Layer richtig in den richtigen Status versetzt wurde.
Hier ist ein Beispiel für die Ausgabe des Befehls show access-session interface <Schnittstellennummer> detail (möglicherweise müssen Sie Details am Ende einiger Plattformen hinzufügen), der auf dem Switch ausgeführt wird, mit dem der Client verbunden ist. Sie müssen überprüfen, ob der Status "Authz Success" lautet, ob die URL-Umleitungszugriffskontrollliste korrekt auf die beabsichtigte Umleitungszugriffskontrollliste verweist und ob die URL-Umleitung auf den erwarteten ISE-Knoten mit CPP am Ende der URL verweist. Das Feld "ACS ACL" ist nicht erforderlich, da es nur angezeigt wird, wenn Sie im Autorisierungsprofil der ISE eine herunterladbare Zugriffsliste konfiguriert haben. Es ist jedoch wichtig, sich diesen Vorgang anzusehen und sicherzustellen, dass kein Konflikt mit der Umleitungszugriffskontrollliste vorliegt (siehe Dokumente zur Statuskonfiguration im Zweifelsfall).
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
Geben Sie show wireless client detail <MAC-Adresse> und show wireless client mac-address <MAC-Adresse> ein, um die Fehlerbehebung für einen WLC mit Cisco IOS-XE durchzuführen, um ein Problem mit einem WLC zu beheben, auf dem AireOS ausgeführt wird. Ähnliche Daten werden angezeigt, und Sie müssen die Umleitungs-URL und die ACL überprüfen sowie, ob sich der Client im Status "POSTURE_REQD" oder in einem ähnlichen Zustand befindet (abhängig von der Softwareversion).
Wenn keine Attribute vorhanden sind, müssen Sie die Authentifizierungsdetails in der ISE des Clients öffnen, für den Sie die Fehlerbehebung durchgeführt haben (navigieren Sie zu Operations > Authentications (Vorgänge > Authentifizierungen), und überprüfen Sie im Abschnitt Result (Ergebnis), ob die Umleitungsattribute gesendet wurden. Wenn sie nicht gesendet wurden, sollten Sie die Autorisierungsrichtlinie überprüfen, um zu verstehen, warum die Attribute für diesen bestimmten Client nicht zurückgegeben wurden. Wahrscheinlich stimmte eine der Bedingungen nicht überein, daher empfiehlt es sich, eine Fehlerbehebung nacheinander durchzuführen.
Denken Sie daran, dass Cisco IOS® in Bezug auf die Umleitungszugriffskontrollliste bei "permit"-Anweisungen umleitet (sodass die ISE- und DNS-IP-Adressen abgelehnt werden müssen), während AireOS auf dem WLC bei "deny"-Anweisungen umleitet (sodass dies für ISE und DNS zulässig ist).
Attribute sind vorhanden, aber Netzwerkgerät leitet keine Umleitung ein
Die Hauptursache in diesem Fall ist ein Konfigurationsproblem. Vergleichen Sie die Konfiguration des Netzwerkgeräts mit dem Konfigurationsleitfaden und den Konfigurationsbeispielen unter Cisco.com. In diesem Fall tritt das Problem in der Regel auf allen Ports oder Access Points (APs) des Netzwerkgeräts auf. Andernfalls kann das Problem nur an einigen Switch-Ports oder APs auftreten. Wenn dies der Fall ist, sollten Sie die Konfiguration der Ports oder APs, bei denen das Problem auftritt, mit der Konfiguration der Ports oder APs vergleichen, bei denen der Status einwandfrei funktioniert.
FlexConnect-APs sind sensibel, da sie jeweils eine eindeutige Konfiguration aufweisen können und es leicht ist, bei einigen APs einen Fehler in einer ACL oder einem VLAN zu machen.
Ein weiteres häufiges Problem ist, dass das Client-VLAN keine SVI hat. Dies gilt nur für Switches und wird detailliert in der ISE-Datenverkehrsumleitung für Switches der Serie Catalyst 3750 beschrieben. Alles könnte gut aussehen, wenn es um Attribute geht.
Störende herunterladbare Zugriffsliste (DACL)
Wenn Sie gleichzeitig mit den Umleitungsattributen eine DACL zurück an den Switch senden (oder eine Airespace-ACL für einen Wireless-Controller), kann dies die Umleitung blockieren. Die DACL wird zuerst angewendet und bestimmt, was vollständig verworfen wird und was weiter verarbeitet wird. Anschließend wird die Umleitungszugriffskontrollliste angewendet und bestimmt, was umgeleitet wird.
Konkret bedeutet dies, dass Sie in den meisten Fällen den gesamten HTTP- und HTTPS-Verkehr in Ihrer DACL zulassen möchten. Wenn Sie es blockieren, wird es nicht umgeleitet, da es zuvor gelöscht wird. Es ist kein Sicherheitsbedenken, da der Datenverkehr hauptsächlich über die nachfolgende Umleitungszugriffskontrollliste umgeleitet wird, sodass er im Netzwerk nicht wirklich zulässig ist. Sie müssen diese beiden Datenverkehrstypen in der DACL jedoch zulassen, damit sie unmittelbar danach die Umleitungszugriffskontrollliste erreichen können.
Ungültige Version des NAC-Agents
Es ist leicht zu vergessen, dass bestimmte Versionen von NAC-Agenten gegenüber bestimmten Versionen der ISE validiert werden. Viele Administratoren aktualisieren ihren ISE-Cluster und vergessen, die entsprechende NAC-Agent-Version in die Ergebnisdatenbank für die Client-Bereitstellung hochzuladen.
Wenn Sie eine veraltete Version des NAC-Agenten für Ihren ISE-Code verwenden, sollten Sie bedenken, dass diese zwar funktioniert, aber nicht funktioniert. So ist es nicht überraschend, dass einige Kunden arbeiten und andere nicht. Eine Möglichkeit zur Verifizierung besteht darin, im Download-Bereich Ihrer ISE-Version unter Cisco.com zu überprüfen, welche Versionen des NAC-Agenten vorhanden sind. In der Regel werden für jede ISE-Version mehrere unterstützt. Diese Webseite sammelt alle Matrizen: Cisco ISE-Kompatibilitätsinformationen.
HTTP-Webproxy wird von Clients verwendet
Das Konzept eines HTTP-Web-Proxys besteht darin, dass Clients die DNS-IP-Adressen von Websites nicht selbst auflösen oder die Websites direkt kontaktieren, sondern ihre Anfrage einfach an den Proxy-Server senden, der sich um sie kümmert. Das typische Problem bei einer üblichen Konfiguration besteht darin, dass der Client eine Website (z. B. www.cisco.com) auflöst, indem er das HTTP GET dafür direkt an den Proxy sendet, der abgefangen und rechtmäßig an das ISE-Portal weitergeleitet wird. Anstatt jedoch das nächste HTTP GET an die IP-Adresse des ISE-Portals zu senden, sendet der Client diese Anforderung weiterhin an den Proxy.
Falls Sie sich entscheiden, keinen HTTP-Verkehr zum Proxy umzuleiten, haben Ihre Benutzer direkten Zugriff auf das gesamte Internet (da der gesamte Verkehr über den Proxy läuft), ohne sich zu authentifizieren oder einen Status zu erhalten. Die Lösung besteht darin, die Browsereinstellungen der Clients zu ändern und in den Proxyeinstellungen eine Ausnahme für die ISE-IP-Adresse hinzuzufügen. Auf diese Weise sendet der Client, wenn er die ISE erreichen muss, die Anforderung direkt an die ISE und nicht an den Proxy. Dadurch wird die Endlosschleife vermieden, in der der Client ständig umgeleitet wird, aber die Anmeldeseite nie sieht.
Beachten Sie, dass der NAC-Agent von den im System eingegebenen Proxyeinstellungen nicht betroffen ist und weiterhin normal funktioniert. Das bedeutet, dass Sie bei Verwendung eines Web-Proxys nicht gleichzeitig die NAC-Agent-Erkennung aktivieren können (da Port 80 verwendet wird), und dass Benutzer den Agenten selbst installieren können, wenn sie beim Durchsuchen zur Statusseite umgeleitet werden (da dies den Proxy-Port verwendet und typische Switches nicht auf mehreren Ports umleiten können).
Erkennungshosts werden im NAC Agent konfiguriert.
Insbesondere nach der ISE-Version 1.2 wird empfohlen, keinen Discovery Host auf dem NAC-Agenten zu konfigurieren, es sei denn, Sie wissen, was dieser tut und was nicht. Der NAC-Agent soll den ISE-Knoten erkennen, der das Client-Gerät über die HTTP-Erkennung authentifiziert hat. Wenn Sie auf Erkennungshosts angewiesen sind, kann der NAC-Agent einen anderen ISE-Knoten kontaktieren als den, der das Gerät authentifiziert hat und der nicht funktioniert. ISE Version 1.2 lehnt einen Agenten ab, der den Knoten über den Discovery Host-Prozess erkennt, da der NAC-Agent die Sitzungs-ID von der Umleitungs-URL abrufen soll. Daher wird von dieser Methode abgeraten.
In einigen Fällen können Sie einen Discovery-Host konfigurieren. Dann sollte sie mit jeder IP-Adresse konfiguriert werden (auch wenn sie nicht vorhanden ist), die von der Umleitungs-ACL umgeleitet wird, und sie sollte sich idealerweise nicht im gleichen Subnetz wie der Client befinden (andernfalls wird der Client auf unbestimmte Zeit für sie ARP durchführen und niemals das HTTP-Erkennungspaket senden).
Der NAC Agent wird gelegentlich nicht angezeigt.
Wenn das Problem nur gelegentlich auftritt und Aktionen wie das Trennen/Wiedereinstecken der Kabel-/Wi-Fi-Verbindung es möglich machen, ist es ein subtileres Problem. Bei den RADIUS-Sitzungs-IDs kann es zu Problemen kommen, wenn die Sitzungs-ID auf der ISE durch RADIUS-Accounting gelöscht wird (deaktivieren Sie die Kontoverwaltung, um festzustellen, ob etwas geändert wird).
Wenn Sie die ISE-Version 1.2 verwenden, besteht eine weitere Möglichkeit darin, dass der Client viele HTTP-Pakete sendet, sodass keines von einem Browser oder dem NAC-Agent stammt. Die ISE Version 1.2 überprüft das Benutzer-Agent-Feld in HTTP-Paketen, um festzustellen, ob es vom NAC-Agenten oder einem Browser stammt. Viele andere Anwendungen senden jedoch HTTP-Datenverkehr mit einem Benutzer-Agent-Feld und erwähnen weder ein Betriebssystem noch nützliche Informationen. ISE Version 1.2 sendet dann eine Autorisierungsänderung, um die Verbindung zum Client zu trennen. ISE Version 1.3 ist von diesem Problem nicht betroffen, da es anders funktioniert. Die Lösung besteht darin, entweder ein Upgrade auf Version 1.3 durchzuführen oder alle erkannten Anwendungen in der ACL für die Umleitung zuzulassen, sodass sie nicht zur ISE umgeleitet werden.
Reverse-Problem: Agent kommt immer wieder vor
Ein gegenteiliges Problem kann auftreten, wenn der Agent sich öffnet, die Schwachstellenanalyse durchführt, den Client validiert und dann kurz darauf erneut auftaucht, anstatt die Netzwerkverbindung zuzulassen und den Betrieb zu unterbrechen. Dies geschieht, da der HTTP-Datenverkehr selbst nach einem erfolgreichen Status immer noch zum CPP-Portal auf der ISE umgeleitet wird. Es empfiehlt sich, anschließend die ISE-Autorisierungsrichtlinie zu durchlaufen und zu überprüfen, ob eine Regel vorhanden ist, die einen Genehmigungszugriff (oder eine ähnliche Regel mit möglichen ACLs und VLANs) sendet, wenn ein kompatibler Client erkannt wird und KEINE CPP-Umleitung erneut erfolgt.
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
30-Jan-2015 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)