AnyConnect versie 4.0 en NAC Posture Agent worden niet opgenomen in de ISE-probleemoplossingsgids
Inhoud
Inleiding
Identity Services Engine (ISE) biedt posteringsfuncties die het gebruik van de NAC-agent (Network Admission Control) (voor Microsoft Windows, Macintosh of via webagent) of AnyConnect versie 4.0 vereisen. De AnyConnect versie 4.0 ISE-poortmodule werkt precies zoals de NAC-agent en wordt daarom in dit document de NAC-agent genoemd. Het meest voorkomende symptoom van posturfalen voor een client is dat de NAC-agent niet opduikt, omdat een werkscenario altijd veroorzaakt dat het NAC-agent-venster opduikt en uw pc analyseert. Dit document helpt u de vele oorzaken te versmallen die de houding kunnen leiden om te ontbreken, wat betekent dat de NAC agent niet verschijnt. Het is niet bedoeld uitputtend te zijn omdat de NAC agent logs alleen kunnen worden gedecodeerd door het Cisco Technical Assistance Center (TAC) en de mogelijke basisoorzaken zijn talrijk; het is echter bedoeld om de situatie te verduidelijken en het probleem verder aan te wijzen dan gewoon "de agent verschijnt niet met de postuur analyse" en zal u waarschijnlijk helpen de meest voorkomende oorzaken op te lossen.
Voorwaarden
Vereisten
De scenario's, symptomen en stappen die in dit document worden vermeld, worden geschreven zodat u problemen kunt oplossen nadat de eerste configuratie al is voltooid. Raadpleeg voor de eerste configuratie Posture Services op de Cisco ISE-configuratiegids op Cisco.com.
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
- ISE-versie 1.2.x
- NAC Agent voor ISE versie 4.9.x
- AnyConnect versie 4.0
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Methodologie voor probleemoplossing
Wat maakt dat de agent naar boven komt?
De agent verschijnt wanneer deze een ISE-knooppunt detecteert. Als de agent merkt dat hij geen volledige netwerktoegang heeft en in een postuur scenario zit, zoekt hij constant naar een ISE-knooppunt.
Er is een Cisco.com document dat de details van het proces van de agentenontdekking verklaart: Het Proces van de Ontdekking van de Agent van de Netwerktoegangscontrole (NAC) voor de Motor van de Diensten van de Identiteit. Om duplicatie van inhoud te voorkomen, wordt in dit document alleen het belangrijkste punt besproken.
Wanneer een client verbinding maakt, ondergaat de client een RADIUS-verificatie (MAC-filtering of 802.1x) aan het einde waarvan ISE de omleidingstoegangscontrolelijst (ACL) en de omleidingsURL naar het netwerkapparaat (switch, adaptieve security applicatie (ASA) of draadloze controller) retourneert om het clientverkeer zo te beperken dat het alleen een IP-adres en DNS-resoluties (Domain Name Server) kan verkrijgen. Al het HTTP(S)-verkeer dat van de client komt, wordt omgeleid naar een unieke URL op ISE die eindigt met CPP (Client Posture and Provisioning), behalve het verkeer dat naar het ISE-portal zelf gaat. De NAC-agent stuurt een standaard HTTP GET-pakket naar de standaardgateway. Als de agent geen antwoord of enig ander antwoord ontvangt dan een CPP-omleiding, beschouwt hij zichzelf als volledig verbonden en gaat niet verder met het aanstellen. Als het een HTTP-reactie ontvangt die een omleiding is naar een CPP-URL aan het einde van een specifiek ISE-knooppunt, dan gaat het het postuur- en contactproces van dat ISE-knooppunt verder. Het verschijnt alleen en start de analyse wanneer het met succes de postuur details van die ISE-knooppunt ontvangt.
De NAC-agent bereikt ook het IP-adres van de geconfigureerde detectiegasker (er wordt niet verwacht dat meer dan één wordt geconfigureerd). Het verwacht ook daar omgeleid te worden om de omleiding URL met de sessie-ID te krijgen. Als het IP-adres van de ontdekking een ISE-knooppunt is, wordt dit niet nagestreefd, omdat het wacht om te worden omgeleid om de juiste sessie-id te verkrijgen. Dus de discovery host is meestal niet nodig, maar kan nuttig zijn wanneer ingesteld als een IP-adres in het bereik van de omleiding ACL om een omleiding te activeren (zoals in VPN-scenario's bijvoorbeeld).
Mogelijke oorzaken
Omleiding gebeurt niet
Dit is verreweg de meest voorkomende oorzaak. Om te valideren of ongeldig te maken, opent u een browser op de pc waar de agent niet verschijnt en ziet u of u wordt doorgestuurd naar de downloadpagina van de postuur-agent wanneer u een URL typt. U kunt ook een willekeurig IP-adres invoeren, zoals http://1.2.3.4 om een mogelijk DNS-probleem te voorkomen (als een IP-adres wordt omgeleid, maar een websitenaam niet, kunt u naar DNS kijken).
Als u wordt omgeleid, moet u de agent logs en ISE-ondersteuningsbundel verzamelen (met de postuur en de zwitserse module om te debuggen modus) en contact opnemen met Cisco TAC. Dit geeft aan dat de agent een ISE-knooppunt ontdekt, maar er is iets mis tijdens het proces om de postuur-gegevens te verkrijgen.
Als er geen omleiding gebeurt, heb je je eerste oorzaak, die nog steeds verder onderzoek van de grondoorzaak vereist. Een goed begin is om de configuratie op het netwerktoegangsapparaat (Wireless LAN-controller (WLC) of switch) te controleren en naar het volgende item in dit document te gaan.
Kenmerken zijn niet geïnstalleerd op het netwerkapparaat
Deze kwestie is een subcase van het scenario Redirection Does Not. Als de omleiding niet gebeurt, moet eerst worden geverifieerd (aangezien het probleem zich voordoet op een bepaalde client) dat de client correct in de juiste status wordt geplaatst door de switch of de draadloze toegangslaag.
Hier is voorbeelduitvoer van de show access-sessie interface <interfacenummer> detail opdracht (u zou detail kunnen moeten toevoegen aan het eind op sommige platforms) genomen op de switch waar de client is verbonden. U moet verifiëren dat de status "Authz succes"is, dat URL ACL correct aan voorgenomen opnieuw richt richt opnieuw richt ACL, en dat URL aan het eind van de URL aan de verwachte knoop van ISE met CPP richt. Het veld ACS ACL is niet verplicht, omdat het alleen wordt weergegeven als u een downloadbare toegangslijst hebt ingesteld in het autorisatieprofiel op ISE. Het is echter belangrijk om er naar te kijken en te verifiëren dat er geen conflict is met de omleiding ACL (zie documenten over postuur configuratie in geval van twijfel).
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
Als u een WLC wilt oplossen die AireOS draait, geeft u details van draadloze client <mac address> en geeft u details van draadloos client-mac-adres <mac address> weer om een WLC op te lossen die Cisco IOS-XE uitvoert. Gelijkaardige gegevens tonen en u moet verifiëren opnieuw richten URL en ACL en als de client in "POSTURE_REQD"staat of gelijkaardig is (het varieert afhankelijk van de softwareversie).
Als er geen attributen aanwezig zijn, moet u de verificatiedetails openen in de ISE van de client waar u problemen oploste (navigeer naar Operations > Authenticaties) en in de resultaatsectie verifiëren dat de omleidingsattributen zijn verzonden. Als ze niet zijn verzonden, moet u het autorisatiebeleid bekijken om te begrijpen waarom de attributen niet zijn teruggestuurd voor deze specifieke klant. Waarschijnlijk kwam een van de voorwaarden niet overeen, dus het is een goed idee om ze een voor een op te lossen.
Vergeet niet dat Cisco IOS® met betrekking tot de omleiding van ACL omleidt naar vergunningsverklaringen (zodat de ISE- en DNS-IP-adressen moeten worden geweigerd) terwijl AireOS op de WLC omleidt naar verklaringen ontkennen (zodat deze zijn toegestaan voor ISE en DNS).
Kenmerken zijn ingesteld maar netwerkapparaat leidt niet om
De belangrijkste oorzaak in dit geval is een configuratiekwestie. U dient de configuratie van het netwerkapparaat te bekijken aan de hand van de configuratiehandleiding en configuratievoorbeelden op Cisco.com. Als dit probleem zich voordoet, bestaat het probleem meestal in alle poorten of toegangspunten van het netwerkapparaat. Als dit niet het geval is, kan het probleem alleen op sommige switchpoorten of bepaalde AP's optreden. Als dit het geval is, zou u de configuratie van die moeten vergelijken waar het probleem zich voordoet in vergelijking met de poorten of AP's waar de houding prima werkt.
FlexConnect AP's zijn gevoelig omdat ze elk een unieke configuratie kunnen hebben en het gemakkelijk is om een fout te maken in een ACL of een VLAN in sommige AP's en niet in andere.
Een ander veelvoorkomend probleem is dat de client-VLAN geen SVI heeft. Dit is alleen van toepassing op switches en wordt in detail besproken in ISE Traffic Redirection op de Catalyst 3750 Series Switch . Vanuit het perspectief van de eigenschappen kan alles er goed uitzien.
Interfering downloadbare toegangslijst (DACL)
Als u, tegelijkertijd met omleidingskenmerken, een DACL terug naar de switch (of Airace-ACL voor een draadloze controller) duwt, dan zou het uw omleiding kunnen blokkeren. DACL wordt eerst toegepast en bepaalt wat volledig wordt gelaten vallen en wat verder wordt verwerkt. Dan richt ACL opnieuw wordt toegepast en bepaalt wat opnieuw wordt gericht.
Wat dit concreet betekent, is dat u het grootste deel van de tijd al HTTP- en HTTPS-verkeer in uw DACL wilt toestaan. Als je het blokkeert, wordt het niet omgeleid, omdat het eerder zal worden weggelaten. Het is geen veiligheidszorg, omdat dat verkeer grotendeels op opnieuw zal worden gericht ACL na, zodat wordt het niet echt toegestaan op het netwerk; nochtans, moet u die twee types van verkeer in DACL toestaan opdat zij een kans hebben om opnieuw te richten ACL te raken net na.
Dubbele NAC Agent versie
Het is gemakkelijk om te vergeten dat de specifieke NAC agent versies tegen specifieke versies van ISE worden gevalideerd. Veel beheerders upgraden hun ISE-cluster en vergeten de gerelateerde NAC-agent versie te uploaden in de database met resultaten voor clientprovisioning.
Als u een verouderde NAC-agent versie voor uw ISE-code gebruikt, houd er dan rekening mee dat het zou kunnen werken, maar ook niet. Daarom is het geen verrassing dat sommige klanten werken en andere niet. Een manier om te verifiëren is om naar de Cisco.com download sectie van uw ISE versie te gaan en te controleren welke NAC agent versies er zijn. Meestal worden er meerdere ondersteund voor elke ISE-versie. Deze webpagina verzamelt alle matrixen: Cisco ISE-compatibiliteitsinformatie.
HTTP-webproxy is in gebruik door clients
Het concept van een HTTP web proxy is dat clients niet zelf de DNS IP-adressen van de website oplossen, noch direct contact opnemen met de websites; in plaats daarvan sturen ze hun verzoek simpelweg naar de proxy server, die het verzorgt. Het typische probleem met een gebruikelijke configuratie is dat de client een website (zoals www.cisco.com) oplost door de HTTP GET direct naar de proxy te sturen, die wordt onderschept en rechtmatig doorgestuurd naar het ISE portal. In plaats van de volgende HTTP GET naar het IP-adres van het ISE-portal te verzenden, blijft de client dat verzoek echter doorsturen naar de proxy.
In het geval dat u besluit om HTTP-verkeer niet opnieuw te sturen dat bestemd is voor de proxy, hebben uw gebruikers directe toegang tot het hele internet (aangezien al het verkeer door de proxy gaat) zonder authenticatie of postuur. De oplossing is om de browserinstellingen van de clients daadwerkelijk aan te passen en een uitzondering toe te voegen voor het ISE IP-adres in de proxyinstellingen. Op deze manier, wanneer de klant ISE moet bereiken, stuurt hij het verzoek rechtstreeks naar de ISE en niet naar de proxy. Dit vermijdt de oneindige loop waar de klant constant wordt omgeleid maar nooit de login pagina ziet.
Merk op dat de NAC agent niet wordt beïnvloed door de proxy-instellingen die in het systeem zijn ingevoerd en het blijft normaal handelen. Dit betekent dat als u een webproxy gebruikt, u niet zowel de NAC agent discovery kunnen hebben werken (omdat het poort 80 gebruikt) en gebruikers hebben zelf-installeert de agent zodra ze worden omgeleid naar de postuur pagina wanneer ze bladeren (omdat dat de proxy-poort en typische switches niet kunnen omleiden op meerdere poorten).
Discovery-hosts zijn geconfigureerd in de NAC-agent
Zeker na ISE versie 1.2, is het aan te raden om geen discovery host te configureren op de NAC-agent, tenzij u expertise hebt over wat het wel en niet doet. De NAC-agent moet de ISE-knooppunt detecteren die het clientapparaat heeft geverifieerd via HTTP-detectie. Als u zich baseert op detectiegastheren, kunt u de NAC-agent contact laten opnemen met een andere ISE-knooppunt dan de knooppunt die het apparaat heeft geverifieerd en die niet werkt. ISE versie 1.2 verwerpt een agent die de node ontdekt via het discovery host-proces, omdat de NAC-agent de sessie-ID uit de omleiding-URL wil halen, zodat deze methode wordt ontmoedigd.
In sommige gevallen, zou u een ontdekkingsgastheer kunnen willen vormen. Dan zou het met om het even welk IP adres (zelfs als niet-bestaand) moeten worden gevormd dat door opnieuw te richten ACL zal worden opnieuw gericht, en het zou idealiter niet in zelfde Subnet moeten zijn zoals de cliënt (anders zal de cliënt voor onbepaalde tijd voor het ARP en nooit het HTTP ontdekkingspakket verzenden).
NAC-agent verschijnt soms niet
Wanneer het probleem meer intermitterend is en acties zoals het loskoppelen/opnieuw aansluiten van de kabel / Wi-Fi-verbinding maken het werken, is het een subtieler probleem. Het kan een probleem zijn met de RADIUS-sessie-ID's waar de sessie-ID door RADIUS-accounting op de ISE wordt verwijderd (accounting uitschakelen om te zien of het iets verandert).
Als u ISE versie 1.2 gebruikt, is een andere mogelijkheid dat de client veel HTTP-pakketten verstuurt, zodat er geen afkomstig is van een browser of de NAC-agent. ISE versie 1.2 scant het user-agent veld in HTTP pakketten om te zien of het afkomstig is van de NAC agent of een browser, maar veel andere toepassingen verzenden HTTP verkeer met een user-agent veld en vermelden geen besturingssysteem of nuttige informatie. ISE versie 1.2 stuurt vervolgens een wijziging van autorisatie om de client los te koppelen. ISE versie 1.3 wordt niet beïnvloed door deze kwestie omdat het werkt op een andere manier. De oplossing is om te upgraden naar versie 1.3 of om alle gedetecteerde toepassingen in de omleiding van ACL toe te staan, zodat ze niet worden omgeleid naar ISE.
Probleem omkeren: Agent verschijnt herhaaldelijk
Het tegenovergestelde probleem kan zich voordoen waar de agent verschijnt, de postuur-analyse doet, de client valideert en vervolgens kort daarna weer verschijnt in plaats van netwerkconnectiviteit toe te staan en stil te blijven. Dit gebeurt omdat, zelfs na een succesvolle houding, het HTTP-verkeer nog steeds wordt omgeleid naar het CPP-portaal op ISE. Het is een goed idee om dan door het de vergunningsbeleid van ISE te gaan en te controleren dat u een regel hebt die een vergunningstoegang (of gelijkaardige regel met mogelijke ACLs en VLANs) verzendt wanneer het een volgzame cliënt en NIET een omleiding CPP opnieuw ziet.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
30-Jan-2015 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)