Risoluzione dei problemi di gestione e postura delle sessioni ISE

Opzioni per il download

  • PDF     (2.1 MB)
    Visualizza con Adobe Reader su diversi dispositivi
Aggiornato:25 agosto 2026
ID documento:215419

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Sommario

Anteprima
Introduzione
Premesse
Problema
Esperienza utente finale
Esperienza di amministrazione ISE
Scenari problematici comuni
Problema di sessione non aggiornata/fantasma
Logica di gestione delle sessioni ISE
Gestione di MNT e sessioni
Gestione di PSN e sessioni
Sessione non aggiornata su PSN
Sessione fantasma nel PSN
Sessione obsoleta e sessione fantasma interrompono il processo di postura
Il processo di individuazione non viene avviato in un nuovo tentativo di autenticazione
Riautenticazione su PSN diverso
E genera un nuovo ID sessione alla riautenticazione
Metodi rapidi per identificare quando un problema è stato causato da una sessione obsoleta/fantasma
Risoluzione avanzata dei problemi di sessioni obsolete/fantasma
DART Bundle Collection
Analisi bundle DART
Indagine sui log ISE
Indagine sui report ISE
Come identificare quando un problema è stato causato dalla mancanza di un riavvio di individuazione
Risoluzione avanzata dei problemi relativi all'assenza di riavvio del rilevamento
Soluzione
Approccio classico - Prevenzione dei problemi
Procedure ottimali per ridurre al minimo il numero di sessioni obsolete o fantasma nell'implementazione ISE
Postura su caso di utilizzo VPN
È possibile implementare best practice per ridurre al minimo l'impatto dovuto all'assenza del riavvio del modulo di rilevamento della postura ISE
Implementazione della riautenticazione
Ambienti con load balancer
Approccio moderno - Condivisione dello stato di postura
Light Data Distribution Architecture
Condivisione dello stato di postura su RSD
Condivisione dello stato della postura su RSD - Sessione non aggiornata/fantasma
Condivisione dello stato di postura su RSD - Failover tra PSN

Introduzione

Questo documento descrive il problema comune relativo ai servizi di postura di Identity Service Engine (ISE), ad esempio "Il modulo di postura AnyConnect ISE è conforme..."

Premesse

Questo documento descrive il problema comune relativo ai servizi di postura di Identity Service Engine (ISE): "Il modulo di postura AnyConnect ISE risulta conforme quando lo stato della sessione su ISE è in sospeso."

Anche se i sintomi sono sempre gli stessi, ci sono diverse cause principali di questo problema. Spesso, la risoluzione di un problema di questo tipo richiede molto tempo, con gravi conseguenze.

Questo documento spiega:

  • Scenari problematici comuni.
  • Algoritmi di identificazione rapida dei problemi.
  • Soluzioni classiche a scenari problematici comuni.
  • Condivisione dello stato della postura sulla directory della sessione Radius.
  • Segnalazione del problema dal punto di vista dell'utente finale e dell'amministratore ISE.
  • La teoria dietro ISE, AnyConnect e le operazioni di rete che innescano il problema.

Per una spiegazione migliore dei concetti descritti più avanti, fare riferimento a Confronto tra gli stili della postura ISE per le versioni precedenti e successive alla 2.2

Problema

Esperienza utente finale

Questo problema si verifica in genere in assenza di accesso alla rete o di reindirizzamento costante al portale di provisioning dei client ISE nel browser, mentre, allo stesso tempo, il modulo di postura AnyConnect ISE mostra lo stato della postura come Conforme.

Esperienza tipica dell'utente finale:

Client Provisioning Portal

Esperienza di amministrazione ISE

Nella fase di valutazione iniziale del problema, un amministratore ISE avvia un'indagine sui log di Radius Live per verificare che l'autenticazione abbia esito positivo sull'ISE. Il primo sintomo rilevato in questa fase indica una mancata corrispondenza in uno stato di postura tra l'endpoint e l'ISE nei log live. In alternativa, i report di autenticazione Radius sull'ultima autenticazione riuscita per l'endpoint mostrano lo stato della postura in sospeso.

Esperienza tipica degli amministratori ISE:

Client Provisioning Portal 2

  • Ultima autenticazione riuscita per l'identità: alice.
  • Lo stato di postura della sessione è In sospeso.
  • Ultimo evento sessione per l'identità: alice.
  • L'evento della sessione mostra lo stato della postura come Conforme.

Nota: Nell'esempio, C e D non sono sempre presenti nei log attivi quando si verifica il problema descritto. Un evento di sessione con uno stato di postura Conforme è più comune negli scenari causati da sessioni obsolete o fantasma (descritti più avanti in questo documento).

Scenari problematici comuni

Questo problema si manifesta in genere in due scenari problematici e ognuno di essi ha più cause principali. Gli scenari:

  • Il modulo di postura AnyConnect ISE è stato informato erroneamente dal PSN (Policy Service Node) durante il processo di postura che ha causato la visualizzazione dello stato di postura errato. In questo caso, TAC normalmente funziona con una sessione obsoleta o fantasma nella cache della sessione PSN.
  • AnyConnect ISE visualizza lo stato della postura del ciclo di rilevamento precedente perché l'autenticazione corrente non ha attivato un processo di rilevamento.

Il modulo di postura ISE in AnyConnect ha un numero limitato di eventi che attivano il processo di rilevamento. È possibile che durante l'autenticazione o la riautenticazione non sia stato rilevato nessuno di questi eventi.

Problema di sessione non aggiornata/fantasma

Per comprendere meglio il problema, esaminare la logica di gestione delle sessioni ISE e il processo di rilevamento di AnyConnect richiesti.

Logica di gestione delle sessioni ISE

Nell'implementazione ISE, il processo di gestione delle sessioni è affidato a due persone: PSN e MNT (Monitoring Node). Per risolvere correttamente il problema e identificarlo, è fondamentale comprendere la teoria della gestione delle sessioni su entrambe le persone.

Gestione di MNT e sessioni

Client Provisioning Portal 3

Come spiegato in questa immagine, il nodo MNT crea stagioni basate sui messaggi Syslog di autenticazione passati provenienti dai PSN. Lo stato della sessione può essere aggiornato in seguito dal syslog per l'accounting.

La rimozione della sessione sul MNT si verifica in tre scenari:

1. Le sessioni senza avvio di accounting vengono rimosse circa 60 minuti dopo la loro creazione. È presente un job cron eseguito ogni 5 minuti per verificare gli stati delle sessioni e pulirle.

2. La sessione terminata è stata rimossa circa 15 minuti dopo che l'interruzione dell'accounting è stata elaborata dallo stesso processo cron.

3. Lo stesso cron su ciascuna esecuzione rimuove le sessioni nello stato 'Avviato' per più di 5 giorni (120 ore). Uno stato avviato indica che il nodo MNT ha elaborato sia l'autenticazione che l'accounting per avviare la sessione Syslog.

note-icon

Nota: Questi sono i normali timer di pulizia MnT, tempi di eliminazione dell'orologio da parete non garantiti. La rimozione può essere ritardata se:

  • SessionPurgeJob non eseguito correttamente.
  • MnT è sotto la pressione della risorsa o del database.
  • Impossibile correlare Accounting-Stop alla sessione esistente.

Esempi di messaggi syslog da PSN:

I messaggi vengono registrati nel file prrt-server.log quando il componente runtime-aaa è abilitato in DEBUG. Le parti in grassetto possono essere utilizzate per creare espressioni regolari di ricerca.

Autenticazione superata:

AcsLogs,2020-04-07 10:07:29,202,DEBUG,0x7fa0ada91700,cntx=0000629480,sesn=skuchere-ise26-1/375283310/10872,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:53:24.288 +02:00 0000423024 5200 NOTICE Passed-Authentication: Authentication succeeded, ConfigVersionId=87, Device IP Address=10.62.148.108, DestinationIPAddress=192.168.43.26, DestinationPort=1812, UserName=bob@example.com, Protocol=Radius, RequestLatency=45, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Service-Type=Framed, Framed-IP-Address=192.168.255.205, Framed-MTU=1472, State=37CPMSessionID=0A3E946C00000073559C0123\;42SessionID=skuchere-ise26-1/375283310/10872\;, Calling-Station-ID=00-50-56-B6-0B-C6, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, EAP-Key-Name=, cisco-av-pair=service-type=Framed, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, cisco-av-pair=client-iif-id=526638260, NetworkDeviceProfileName=Cisco, NetworkDeviceProfileId=b0699505-3150-4215-a80e-6753d45bf56c, IsThirdPartyDeviceFlow=false, RadiusFlowType=Wired802_1x, AcsSessionID=skuchere-ise26-1/375283310/10872, AuthenticationIdentityStore=EXAMPLE, AuthenticationMethod=MSCHAPV2, SelectedAccessService=Default Network Access, SelectedAuthorizationProfiles=PermitAccess, IsMachineAuthentication=false, IdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Step=11001, Step=11017, Step=15049, Step=15008, Step=15048, Step=15048, Step=15048, Step=11507, Step=12500, Step=12625, Step=11006, Step=11001, Step=11018, Step=12301, Step=12300, Step=12625, Step=11006, Step=11001, Step=11018, Step=12302, Step=12318, Step=12800, Step=12805, Step=12806, Step=12807, Step=12808, Step=12810, Step=12811, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12318, Step=12812, Step=12813, Step=12804, Step=12801, Step=12802, Step=12816, Step=12310, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12313, Step=11521, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11522, Step=11806, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11808, Step=15041, Step=22072, Step=15013, Step=24210, Step=24216, Step=15013, Step=24430, Step=24325, Step=24313, Step=24319, Step=24323, Step=24343, Step=24402, Step=22037, Step=11824, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11810, Step=11814, Step=11519, Step=12314, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=24715, Step=15036, Step=24209, Step=24211, Step=24432, Step=24325, Step=24313, Step=24319, Step=24323, Step=24355, Step=24416, Step=15048, Step=15016, Step=22081, Step=22080, Step=12306, Step=11503, Step=11002, SelectedAuthenticationIdentityStores=Internal Users, SelectedAuthenticationIdentityStores=All_AD_Join_Points, SelectedAuthenticationIdentityStores=Guest Users, AuthenticationStatus=AuthenticationPassed, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, IdentityPolicyMatchedRule=Dot1X, AuthorizationPolicyMatchedRule=Compliant-Wired, EapTunnel=PEAP, EapAuthentication=EAP-MSCHAPv2, CPMSessionID=0A3E946C00000073559C0123, EndPointMACAddress=00-50-56-B6-0B-C6, PostureAssessmentStatus=NotApplicable, EndPointMatchedProfile=Microsoft-Workstation, ISEPolicySetName=Default, IdentitySelectionMatchedRule=Dot1X, AD-User-Resolved-Identities=bob@example.com, AD-User-Candidate-Identities=bob@example.com, AD-User-Join-Point=EXAMPLE.COM, StepData=4= Radius.NAS-IP-Address, StepData=5= Cisco-VPN3000.CVPN3000/ASA/PIX7x-Tunnel-Group-Name, StepData=6= DEVICE.Device Type, StepData=77=All_User_ID_Stores, StepData=78=Internal Users, StepData=81=All_AD_Join_Points, StepData=82=All_AD_Join_Points, StepData=83=bob@example.com, StepData=84=example.com, StepData=85=example.com, StepData=87=bob@example.com, StepData=88=All_AD_Join_Points, StepData=109=EXAMPLE, StepData=110=bob@example.com, StepData=111=example.com, StepData=112=example.com, StepData=114=example.com, StepData=115=EXAMPLE, StepData=116= EXAMPLE.ExternalGroups, AD-User-Resolved-DNs=CN=bob\,CN=Users\,DC=example\,DC=com, AD-User-DNS-Domain=example.com, AD-Groups-Names=example.com/Users/Domain Users, AD-User-NetBios-Name=EXAMPLE, IsMachineIdentity=false, UserAccountControl=66048, AD-User-SamAccount-Name=bob, AD-User-Qualified-Name=bob@example.com, allowEasyWiredSession=false, TLSCipher=ECDHE-RSA-AES256-GCM-SHA384, TLSVersion=TLSv1.2, DTLSSupport=Unknown, HostIdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, IdentityAccessRestricted=false, PostureStatus=Compliant, Response={Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872; EAP-Key-Name=19:5e:8c:e9:13:0c:89:23:78:49:ad:2b:d4:31:63:51:27:81:db:e2:61:b1:51:36:6d:11:10:41:ce:3b:aa:cc:c6:66:4e:7c:92:f8:83:c5:06:84:ac:95:4c:5b:f1:b2:37:a2:f5:04:4e:9e:4d:08:79:55:b7:4d:9a:41:f5:b2:0a; MS-MPPE-Send-Key=****; MS-MPPE-Recv-Key=****; LicenseTypes=65541; },],MessageFormatter.cpp:107

Inizio accounting:

AcsLogs,2020-04-07 10:07:30,202,DEBUG,0x7fa0ad68d700,cntx=0000561096,sesn=skuchere-ise26-1/375283310/10211,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 10:07:30.857 +02:00 0000382874 3000 NOTICE Radius-Accounting: RADIUS Accounting start request, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=7, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10210, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Start, Acct-Delay-Time=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Event-Timestamp=1586279242, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10211, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=15048, Step=22083, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107

Aggiornamento contabile provvisorio:

AcsLogs,2020-04-07 22:57:48,642,DEBUG,0x7fa0adb92700,cntx=0000629843,sesn=skuchere-ise26-1/375283310/10877,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:57:48.650 +02:00 0000423268 3002 NOTICE Radius-Accounting: RADIUS Accounting watchdog update, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=8, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Interim-Update, Acct-Delay-Time=0, Acct-Input-Octets=2293926, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Input-Packets=15785, Acct-Output-Packets=0, Event-Timestamp=1586325462, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10877, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22085, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107

Arresto accounting:

AcsLogs,2020-04-08 11:43:22,356,DEBUG,0x7fa0ad68d700,cntx=0000696242,sesn=skuchere-ise26-1/375283310/11515,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-08 11:43:22.368 +02:00 0000463071 3001 NOTICE Radius-Accounting: RADIUS Accounting stop request, ConfigVersionId=88, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=12, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/11503, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Stop, Acct-Delay-Time=0, Acct-Input-Octets=4147916, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Session-Time=92157, Acct-Input-Packets=29120, Acct-Output-Packets=0, Acct-Terminate-Cause=Lost Carrier, Event-Timestamp=1586371399, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, Framed-IPv6-Address=2001:10::100, Framed-IPv6-Address=2001:10::101, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/11515, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22084, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107

Gestione di PSN e sessioni

La cache delle sessioni PSN è un database in memoria in cui vengono archiviate tutte le sessioni attive di un PSN specifico. La cache della sessione è sempre locale rispetto al nodo. In ISE non esiste alcun meccanismo in grado di eseguire la replica degli stati di sessione FULL da un nodo all'altro.

Per ogni ID sessione attivo, PSN memorizza tutti gli attributi raccolti durante la fase di autenticazione/autorizzazione, ad esempio gruppi di utenti interni/esterni, attributi del dispositivo di accesso alla rete, attributi del certificato e così via. Tali attributi vengono utilizzati dal PSN per selezionare diversi tipi di criteri, ad esempio autenticazione, autorizzazione, provisioning client e postura.

La cache della sessione viene rimossa completamente al riavvio del nodo o dei servizi sul nodo.

Client Provisioning Portal 4

La logica di elaborazione della sessione corrente crea una nuova voce nella cache della sessione in due scenari. I dettagli successivi delle sessioni esistenti possono essere aggiornati dai messaggi di accounting provenienti da NAD.

  • La sessione è stata autenticata correttamente nel PSN.
  • Il PSN dispone di un aggiornamento intermedio di accounting per la sessione che non esiste nella cache della sessione. Con la rimozione della sessione, PSN implementa la logica seguente:
    • La voce della cache della sessione viene rimossa immediatamente dopo l'elaborazione del messaggio di arresto dell'accounting.
    • Il PSN inizia a rimuovere le sessioni utilizzate meno di recente quando un nodo raggiunge il limite di sessioni attive.

Sessione non aggiornata su PSN

Nella distribuzione ISE, l'arresto dell'accounting per una sessione esistente è stato elaborato dal PSN che non ha eseguito l'autenticazione effettiva:

Esempio di sessione non aggiornata:

Client Provisioning Portal 5

  1. L'autenticazione viene eseguita correttamente sul PSN per la sessione ABC.
  2. PSN crea una voce nella cache della sessione.
  3. Viene eseguita la valutazione della postura.
  4. La sessione è contrassegnata come conforme.
  5. La modifica dell'autorizzazione (COA, Change of Authorization) viene attivata dalla modifica dello stato della postura, che determina la riautenticazione dell'endpoint per applicare il livello di accesso successivo.
  6. L'accounting si arresta per la sessione ABC su PSN2.

In seguito, ABC rimane bloccato in uno stato non aggiornato su PSN1 poiché non è stato elaborato alcun messaggio di interruzione dell'accounting su questo PSN per rimuoverlo. La sessione viene rimossa se nella distribuzione non viene eseguito un numero elevato di tentativi di autenticazione.

La sessione non aggiornata viene visualizzata nella cache della sessione PSN nei seguenti scenari:

  • L'arresto dell'accounting è stato inviato al PSN errato a causa della scadenza del timer di persistenza nel servizio di bilanciamento del carico.
  • La configurazione errata in NAD non è la stessa PSN configurata per l'autenticazione e l'accounting.
  • Problemi di connettività temporanei nel percorso di rete hanno causato il failover di NAD al PSN successivo.

Esempio di sessione non aggiornata nell'ambiente di bilanciamento del carico:

Client Provisioning Portal 6

  1. L'autenticazione iniziale per la sessione ABC viene eseguita da PSN1. Questa autenticazione avvia un timer di persistenza sul load balancer.
  2. PSN1 crea una voce per la sessione ABC nella cache locale.
  3. Il messaggio Syslog per l'autenticazione passata viene trasferito al nodo MNT.
  4. La voce relativa alla sessione ABC viene creata nella directory di sessione MNT con lo stato Authenticated.
  5. Il messaggio di avvio dell'accounting per la sessione ABC termina su PSN1.
  6. La voce della cache di sessione per la sessione ABC viene aggiornata con le informazioni di Accounting-Start.
  7. Il messaggio Syslog per Accounting-Start viene trasferito al nodo MNT.
  8. Lo stato della sessione viene aggiornato su Avviata.
  9. Il timer di persistenza scade sul load balancer.
  10. Accounting-Stop per la sessione ABC viene inoltrato dal bilanciamento del carico a PSN2.
  11. Il messaggio Syslog per Accounting-Stop viene inoltrato da PSN2 a MNT.
  12. La sessione ABC è contrassegnata come terminata in MNT.

Sessione fantasma nel PSN

La sessione fantasma è uno scenario in cui l'aggiornamento intermedio di accounting arriva al PSN e non esegue l'autenticazione per tale sessione. In questo scenario, viene creata una nuova voce nella cache della sessione PSN. Se il PSN non riceve un messaggio di interruzione dell'accounting per questa sessione, la voce non viene rimossa a meno che il PSN non raggiunga il limite di sessioni attive.

Esempio della sessione fantasma:

Client Provisioning Portal 7

  1. Gli stessi passaggi descritti nell'esempio di sessione obsoleta si verificano su PSN1 per la sessione ABC.
  2. Lo stato della sessione ABC è Conforme nella cache di sessione PSN1.
  3. Un aggiornamento intermedio della contabilità per la sessione ABC ha riscontrato PSN2.
  4. In PSN2 viene creata una voce di sessione per ABC. Poiché la voce di sessione viene creata dal messaggio di contabilità, dispone di un numero limitato di attributi. Ad esempio, lo stato della postura non è disponibile per la sessione ABC e i gruppi di utenti o altri attributi specifici dell'autorizzazione sono assenti.

La sessione fantasma viene visualizzata nella cache della sessione PSN nei seguenti scenari:

  • Interruzione a breve termine del transito di rete.
  • Errore di funzionamento del dispositivo di accesso alla rete.
  • Configurazione errata o errata nel bilanciamento del carico.

Lo screenshot successivo è un esempio di sessione fantasma in cui problemi temporanei sul percorso di rete verso PSN1:

Client Provisioning Portal 8

  1. L'autenticazione iniziale per la sessione ABC viene eseguita dal PSN.
  2. PSN1 crea una voce per la sessione ABC nella cache locale.
  3. Il messaggio syslog per l'autenticazione passata viene trasferito al nodo MNT.
  4. Una voce per la sessione ABC viene creata nel database TimesTen con lo stato Authenticated.
  5. Il messaggio di avvio dell'accounting per la sessione ABC termina su PSN 1.
  6. Una voce della cache di sessione per la sessione ABC viene aggiornata con le informazioni di Accounting-Start.
  7. Il messaggio Syslog per Accounting-Start viene trasferito al nodo MNT.
  8. Lo stato della sessione viene aggiornato a Avviata.
  9. L'aggiornamento Contabilità provvisoria per la sessione ABC viene inoltrato a PSN2.
  10. PSN2 crea una voce per la sessione ABC nella cache locale.
  11. L'operazione Accounting-Stop per la sessione ABC viene inoltrata a PSN1.
  12. La voce relativa alla sessione ABC viene rimossa dalla cache delle sessioni in PSN1.
  13. PSN1 inoltra un messaggio Syslog per Accounting-Stop a MNT.
  14. La sessione ABC è contrassegnata come terminata in MNT.

In questo scenario viene illustrato uno scenario della sessione fantasma creato per la connessione VPN a lunga durata:

Client Provisioning Portal 9

  1. Autenticazione iniziale su PSN1.
  2. La sessione ABC viene creata nella cache delle sessioni.
  3. L'accounting avvia il messaggio elaborato dal PSN.
  4. Il nuovo indirizzo IP viene assegnato alla scheda VPN (Virtual Private Network).
  5. Un aggiornamento contabile temporaneo con le informazioni sull'indirizzo IP viene inserito nel PSN.
  6. Le informazioni sull'indirizzo IP vengono aggiunte alla cache della sessione.
  7. La valutazione della postura viene eseguita con PSN1.
  8. Lo stato della postura viene aggiornato nella sessione.
  9. ISE esegue un push del certificato di autenticità (COA); viene attivato un nuovo livello di accesso da assegnare.
  10. Si è verificata un'interruzione sul percorso di rete che rende inaccessibile PSN1.
  11. Dopo la scadenza di un intervallo di aggiornamento provvisorio, ASA/FTD rileva che PSN1 non è accessibile.
  12. L'aggiornamento della contabilità provvisoria arriva a PSN2.
  13. La sessione fantasma viene creata nella cache della sessione PSN2.

Se PSN1 diventa accessibile successivamente (14), tutti i messaggi di accounting successivi vengono inoltrati (15,16) e la sessione ABC rimane nella cache della sessione PSN2 per un periodo di tempo non definito.

Sessione obsoleta e sessione fantasma interrompono il processo di postura

Per comprendere come le sessioni obsolete e fantasma interrompono la postura, è possibile rivedere il processo di rilevamento del modulo di postura di AnyConnect ISE:

Client Provisioning Portal 10

Individuazione fase 1:

In questa fase, il modulo di postura ISE esegue quattro richieste simultanee per individuare il PSN che autentica l'endpoint.

In primo luogo, le tre sonde indicate sono basate sul reindirizzamento (IP GW predefinito, IP host di rilevamento (se definito) e enroll.cisco.com IP); tali richieste indirizzano sempre l'agente al PSN corretto, in quanto l'URL reindirizzato viene preso dal NAD stesso.

La sonda 4 viene inviata a tutti i server primari presenti nel file ConnectionData.xml. Questo file viene creato dopo il primo tentativo riuscito di postura. Il contenuto del file può essere aggiornato in un secondo momento se il client esegue la migrazione tra PSN.

Sui sistemi Windows, il percorso del file è C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.

Poiché tutte le sonde della fase 1 vengono eseguite contemporaneamente, i risultati della sonda 4 vengono utilizzati solo se tutte le altre tre sonde hanno esito negativo o se il modulo di postura ISE non può stabilire una comunicazione corretta con il PSN restituito nell'URL di reindirizzamento entro 5 secondi.

Quando il probe four atterra sul PSN, contiene un elenco di indirizzi IP e MAC attivi scoperti sull'endpoint. Il servizio PSN utilizza questi dati per trovare una sessione per l'endpoint nella cache locale. Se il PSN dispone di una sessione non aggiornata o fittizia per un endpoint, lo stato della postura visualizzato sul lato client potrebbe essere errato.

Quando un agente riceve più risposte per la sonda 4 (ConnectionData.xml può contenere più di un PSN primario), viene sempre utilizzata la risposta più veloce.

Individuazione fase 2:

Tutte le richieste di individuazione della fase 2 sono senza reindirizzamento, il che significa che ogni sonda attiva una ricerca di sessione sul PSN di destinazione. Se il PSN non è in grado di individuare la sessione nella cache della sessione locale, deve eseguire una ricerca MNT (solo basata sull'indirizzo MAC) per trovare un proprietario della sessione e restituire il nome del proprietario all'agente.

Poiché tutti i probe attivano la ricerca delle sessioni, il rilevamento della Fase 2 può essere influenzato in modo significativo da problemi derivanti da sessioni obsolete o fantasma.

Se il PSN passa alla Fase 2, la sonda di rilevamento presente nella cache della sessione crea una voce non aggiornata o fittizia per lo stesso endpoint. Il risultato è uno stato di postura errato restituito all'utente finale.

In questo esempio viene mostrato come viene visualizzata la postura quando il PSN mantiene una sessione obsoleta o una sessione fantasma:

Client Provisioning Portal 11

Nota: Questo problema può verificarsi solo quando tutti i probe di individuazione basati su reindirizzamento hanno esito negativo o quando viene implementata la postura di non reindirizzamento.

  1. Una qualsiasi delle sonde Find my session emesse dal modulo ISE posture.
  2. PSN esegue la ricerca di sessioni nella cache delle sessioni. Se la sessione deve essere individuata, si verifica un problema di sessione non aggiornata o fittizia.
  3. PSN esegue la selezione dei criteri di provisioning client. Se una sessione fantasma non dispone di attributi di autenticazione/autorizzazione e tutti i criteri configurati dall'utente sono specifici (ad esempio, i criteri vengono creati per gruppi di Active Directory specifici), PSN non è in grado di assegnare un criterio di provisioning client corretto. Questo può manifestarsi nel messaggio di errore: "Ignorando AnyConnect, la rete non è configurata per l'uso di Cisco NAC Agent".
    • Nei casi in cui i criteri di provisioning client sono generici (gli attributi disponibili nella sessione fantasma sono sufficienti per corrispondere al criterio con una configurazione AnyConnect), il PSN risponde con i dettagli necessari per la continuazione del processo di valutazione.
    • In questo passaggio, quando si utilizzano sessioni non aggiornate, il PSN risponde immediatamente con lo stato di postura Conforme e tutti i passaggi successivi non vengono completati. Il PSN non invia il certificato di autenticità perché ritiene che la sessione sia già conforme. Nei registri Radius Live, non è presente un evento di sessione visualizzato con lo stato Conforme.

4. Per lo scenario di sessione fantasma, il modulo di postura ISE continua con la richiesta di postura iniziale. Questa richiesta contiene informazioni su tutti i prodotti di sicurezza e gestione delle patch rilevati sull'endpoint.

5. Il PSN utilizza le informazioni degli attributi della richiesta e della sessione per soddisfare i criteri di postura corretti. A questo punto, la sessione fantasma non dispone di attributi e non sono disponibili criteri per la corrispondenza. In questo caso, il PSN risponde all'endpoint che è conforme. Questo è il comportamento predefinito di ISE se il criterio di postura non corrisponde. 

Nota: Se esiste un criterio generico che può essere selezionato dagli attributi della sessione fantasma, è possibile continuare con il passo 6.

6. PSN restituisce all'agente i criteri di postura selezionati.

Nota: Quando non è possibile selezionare alcun criterio, il PSN restituisce lo stato Conforme.

7. L'agente restituisce gli stati per ogni criterio/requisito come "superato" o "non riuscito".

8. La valutazione del report viene eseguita su ISE e lo stato della sessione cambia in Conforme.

Nota: Se i problemi di postura sono causati dalla sessione fantasma, l'amministratore ISE può notare alcuni errori nel COA della postura. In tal caso, le richieste COA vengono eseguite dai PSN errati e per gli ID sessione errati.

Il processo di individuazione non viene avviato in un nuovo tentativo di autenticazione

Il modulo di postura ISE è progettato per monitorare una quantità limitata di eventi sull'endpoint per innescare un processo di rilevamento.

Eventi che attivano l'individuazione:

  • Installazione iniziale del modulo di postura ISE.
  • Accesso utente.
  • Eventi di alimentazione.
  • Modifica stato interfaccia.
  • Il sistema operativo viene ripreso dopo la sospensione.
  • Modifica del gateway predefinito (DG).
  • Errore di rivalutazione della postura (PRA), vedere l'ID bug Cisco CSCvo69557. Il modulo di postura ISE non rileva la nuova autenticazione dot1x, lo sblocco del PC e la modifica dell'indirizzo IP.

Il modulo di postura ISE non è in grado di rilevare un nuovo tentativo di autenticazione o riautenticazione negli scenari seguenti:

  • La riautenticazione ha raggiunto un numero PSN diverso (a causa di decisioni di bilanciamento del carico o di problemi con il numero PSN originale).
  • NAD genera un nuovo ID sessione alla riautenticazione.

Riautenticazione su PSN diverso

In questo diagramma viene illustrato un esempio di riautenticazione su un numero PSN diverso causata dall'interruzione del numero PSN originale. Uno scenario con un load balancer ha un aspetto simile. Nel caso di un load balancer, la riautenticazione viene indirizzata al diverso PSN come risultato di una scadenza del timer di persistenza.

Client Provisioning Portal 11

  1. Autenticazione iniziale su PSN1.
  2. La sessione ABC viene creata nella cache della sessione PSN1.
  3. La valutazione della postura viene eseguita con PSN1.
  4. Lo stato della postura ABC della sessione viene impostato su Conforme.
  5. Il certificato di autenticità viene attivato dalla modifica dello stato della postura e determina la riautenticazione dell'endpoint per applicare il livello di accesso successivo.
  6. PSN1 non è più disponibile.
  7. La riautenticazione per la sessione ABC ha riscontrato PSN2.
  8. Poiché si tratta di una nuova sessione per PSN2, lo stato di postura della sessione diventa In sospeso.

Lo stato di postura iniziale viene assegnato dal PSN alla sessione:

Client Provisioning Portal 12

Nota: La macchina a stati descrive solo una selezione iniziale dello stato della postura. Ogni sessione inizialmente contrassegnata come Sconosciuta può successivamente diventare Conforme o Non Conforme in base alla valutazione del report ricevuta dal modulo di postura ISE.

E genera un nuovo ID sessione alla riautenticazione

Questa situazione può verificarsi nei due scenari più comuni:

  • La riautenticazione non è configurata correttamente sul lato ISE (la soluzione al problema è illustrata più avanti in questo documento).
  • comportamento scorretto da parte del DNA; Normalmente NAD mantiene lo stesso ID sessione durante il tentativo di riautenticazione. Si tratta di un comportamento potenzialmente problematico che deve essere esaminato su NAD.
    • Il nuovo ID sessione può essere generato in altri scenari. In alcuni casi, ad esempio, il roaming wireless può essere una delle cause.
    • ISE PSN imposta sempre una nuova sessione nello stato postura in sospeso, a meno che il lease di postura non sia configurato. Il lease della postura è descritto più avanti in questo documento.

Metodi rapidi per identificare quando un problema è stato causato da una sessione obsoleta/fantasma

Per stabilire se AnyConnect mostra la conformità nello stato di reindirizzamento, è causato da una sessione non aggiornata/fittizia. È necessario ottenere l'accesso all'endpoint mentre si trova nello stato di problema.

Analizza dettagli analisi sistema

1. Fare clic sull'icona a forma di ingranaggio nell'interfaccia utente di AnyConnect.

Client Provisioning Portal 13

2. Nella nuova finestra passare a Scansione sistema > Statistiche.

Client Provisioning Portal 14

Prestare quindi attenzione a due elementi importanti:

  • Ora di inizio ultima analisi: L'indicatore orario qui deve essere vicino all'ora in cui è stato rilevato il problema.
  • Server dei criteri: Questo campo indica il nome del policy server che esegue una valutazione della postura per l'endpoint. L'FQDN deve essere confrontato con l'FQDN dell'URL di reindirizzamento (per la postura di base di reindirizzamento) o con il nome PSN ricavato dall'ultimo tentativo di autenticazione (per la postura senza reindirizzamento).
  1. Confrontare l'FQDN di Policy Server dalle statistiche di analisi del sistema con il nome del nodo che ha eseguito l'autenticazione per l'endpoint:

Client Provisioning Portal 15

La demo mostra la registrazione dei passi richiesti per l'identificazione del problema:

Risoluzione avanzata dei problemi di sessioni obsolete/fantasma

L'esempio precedente differenzia il problema di una sessione obsoleta o fittizia dal problema del processo di rilevamento non avviato. Allo stesso tempo, è necessario identificare la sessione effettiva che ha attivato il problema per comprendere come esso diventi un problema di sessione obsoleto o fantasma. Sebbene in alcuni scenari non sia possibile evitare sessioni obsolete e fantasma, è necessario garantire l'implementazione di procedure ottimali per impedire la creazione di sessioni obsolete o fantasma in un ambiente.

DART Bundle Collection

Analizza un bundle DART acquisito dall'endpoint che riproduce il problema.

  1. Conservare solo i registri importanti in DART ed è consigliabile cancellare i registri prima di riprodurre il problema.
  2. Per ottenere questo risultato, l'utility del bundle DART deve essere avviata come amministratore ed eseguire la pulizia del log.
  3. In Windows, passare a Start e digitare DART > fare clic con il pulsante destro del mouse e scegliere - Esegui come amministratore.


Client Provisioning Portal 16

4. Nella prima schermata della procedura guidata, fare clic su Avanti.

Client Provisioning Portal 17

5. Nella schermata successiva della procedura guidata, fare clic su Cancella tutti i registri.

Client Provisioning Portal 18

6. Una volta riprodotto il problema, sarà possibile raccogliere i dati DART da qui; fare clic su Avanti.

Analisi bundle DART

Dopo aver raccolto il pacchetto DART, disarchiviarlo e selezionare il file AnyConnect_ISEPosture.txt situato nella cartella Cisco AnyConnect ISE Posture Module. Questo file contiene tutti gli eventi correlati all'individuazione.

Client Provisioning Portal 19

1. Avviare la risoluzione dei problemi e identificare tutti i momenti di riavvio del processo di individuazione. Le parole chiave da cercare sono il riavvio dell'individuazione o l'individuazione HTTP. Passare alla riga con il riavvio del rilevamento che si è verificato nel momento in cui si è verificato il problema:

CLI Output

2. Dopo il riavvio del rilevamento, è presente una riga che contiene, Probing no MNT stage targets (questo è un indicatore dell'inizio del rilevamento della Fase 1):

CLI Output 2

3. Si consiglia di evidenziare tutte le sonde basate sul reindirizzamento con lo stesso colore e i PSN precedentemente connessi ottenuti dalle destinazioni ConnectionData.xml (Auth-Status) con un colore diverso. Normalmente gli FQDN dei PSN sono simili e possono essere difficili da individuare.

4. Leggere i file di log per visualizzare i risultati per ciascuna sonda (questo è un esempio di come appare una sonda guasta):

CLI Output 3

5. In un punto qualsiasi del file dopo il riavvio del rilevamento per la Fase 1 o la Fase 2, viene visualizzata una risposta corretta da uno o più PSN:

CLI Output 4

5. Dopo diverse righe, viene visualizzata una riga con la parola chiave MSG_NS_SWISS_NEW_SESSION. Questa riga contiene un ID sessione effettivo selezionato dal PSN come risultato della ricerca della sessione. Utilizzare questo ID sessione per ulteriori informazioni su ISE e determinare in che modo la sessione è diventata obsoleta/fantasma:

CLI Output 5

Indagine sui log ISE

1. Nel file guest.log con il componente client-webapp abilitato in DEBUG, il PSN risponde con la sessione non aggiornata/fittizia, che può essere visualizzata.

2. Il PSN riceve una richiesta dall'agente di postura ISE. Questa è una richiesta di AnyConnect a causa del valore User-Agent:

cisco.cpm.client.posture.PostureStatusServlet -::- Got http request from 192.168.255.228 user agent is: Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.6.03049)

cisco.cpm.client.posture.PostureStatusServlet -::- mac_list from http request ==> C0:4A:00:1F:6B:39

cisco.cpm.client.posture.PostureStatusServlet -::- iplist from http request ==> 192.168.255.228

cisco.cpm.client.posture.PostureStatusServlet -::- Session id from http request - req.getParameter(sessionId) ==> null

3. La richiesta contiene matrici di indirizzi IP e indirizzi MAC. In questo esempio, ogni matrice contiene un solo valore. Il log mostra che l'ID sessione della richiesta è null, il che indica che si tratta di una richiesta proveniente dalla sonda non basata sul reindirizzamento. In seguito, è possibile vedere come vengono utilizzati i valori delle matrici per individuare un ID sessione:

cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently processed in the for loop ==> 192.168.255.228

cpm.client.provisioning.utils.ProvisioningUtil -::- the ipAddress that matched the http request remote address ==> 192.168.255.228

cpm.client.provisioning.utils.ProvisioningUtil -::- the clientMac from the macarray list for the for loop index matching the ipAddress list index ==> C0-4A-00-1F-6B-39

cisco.cpm.client.posture.PostureStatusServlet -::- Found Client IP matching the remote IP 192.168.255.228, corresponding mac address C0-4A-00-1F-6B-39

cpm.client.provisioning.utils.ProvisioningUtil -::- Session = 0a3e949c000000495c216240

4. Dopo la riga con le parole chiave Inviata risposta http, è possibile visualizzare il contenuto dalla risposta:

cisco.cpm.client.posture.PostureStatusServlet -::- Sent an http response to  192.168.255.228 with X-ISE-PDP=clemea19-ise1.demo.local.

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PDP value is clemea19-ise1.demo.local

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE value is /auth/perfigo_validate.jsp

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_PORT value is 8443

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_PORT value is 8443

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-GUESTFLOW value is false

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URL value is https://clemea19-ise1.demo.local:8443/auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URI value is /auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URL value is https://clemea19-ise1.demo.local:8443/auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URI value is /auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_VER value is 4.6.3049.0

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-STATUS_PATH value is /auth/status

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-BACKUP_SERVERS value is clemea19-ise2.demo.local

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-SessionId value is 0a3e949c000000495c216240

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PostureDomain value is posture_domain

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_STATUS value is Unknown

Indagine sui report ISE

Una volta noto l'ID della sessione non aggiornata/fantasma, è possibile esaminare il report di Contabilità Radius per comprendere meglio le cause che hanno portato la sessione a essere non aggiornata/velata:

  1. Passare a Operazioni > Rapporti > Endpoint e utenti > Rapporto Contabilità Radius ed eseguire questo rapporto per 7 giorni. utilizzare un ID endpoint come chiave di filtro.

2. Questo è un esempio di report che mostra come è stata lasciata la sessione non aggiornata su ciscolive-ise2:

CLI Output 6

  • L'avvio dell'accounting per la sessione è stato inviato a PSN ciscolive-ise2.
  • L'aggiornamento temporaneo per la sessione è stato elaborato nello stesso PSN.
  • Un messaggio di interruzione dell'accounting per l'ID di sessione con problemi è stato inviato a un PSN diverso (ciscolive-ise1).

Come identificare quando un problema è stato causato dalla mancanza di un riavvio di individuazione

La stessa logica è applicabile al problema precedente, tuttavia l'unica differenza consiste nel fatto che è necessario concentrarsi sull'ora di inizio dell'ultima analisi. Per questo tipo di problema, l'indicatore orario dell'ultima analisi è nel passato.

In genere, quando un utente finale rileva un problema, viene eseguita un'analisi. Nei log ISE Radius Live, sono visualizzati i recenti tentativi di autenticazione dall'endpoint problematico.

La demo mostra la registrazione dei passi necessari per l'identificazione del problema:

Risoluzione avanzata dei problemi relativi all'assenza di riavvio del rilevamento

Questo approccio è simile alla sezione Risoluzione avanzata dei problemi relativi a sessioni obsolete/fantasma. L'elemento principale per la risoluzione dei problemi è l'analisi del bundle DART.

All'interno del bundle DART, è possibile ricercare i riavvii del rilevamento (come illustrato per il problema precedente) e confermare che non vi sono stati riavvii del rilevamento nel momento in cui è stato segnalato il problema.

Sul lato ISE, focalizzare l'attenzione sul report di autenticazione Radius Live Logs/Radius per confermare che c'è stato il failover tra i PSN o che è stato generato un nuovo ID sessione da NAD.

Soluzione

Approccio classico - Prevenzione dei problemi

In passato, non esistevano funzionalità in grado di risolvere i problemi descritti in questo documento, quindi l'unico modo era affidarsi al gruppo di best practice implementate sulla rete e dal lato ISE per ridurre al minimo i rischi.

Procedure ottimali per ridurre al minimo il numero di sessioni obsolete o fantasma nell'implementazione ISE

Implementa Sempre La Postura Basata Sul Reindirizzamento, Quando Possibile

Un comune controargomento per questa raccomandazione è la presenza di un'esperienza utente errata nel sistema operativo o nei browser. Ciò indica il reindirizzamento mentre il modulo di postura AnyConnect ISE in background esegue un processo di valutazione.

Per risolvere questo problema, è possibile reindirizzare SOLO le richieste di rilevamento del modulo ISE Posture e consentire in modo selettivo tutto il resto del traffico. Nell'esempio viene mostrato come reindirizzare gli ACL in modo da reindirizzare solo le richieste HTTP all'host di rilevamento (10.1.1.1 nell'esempio) e all'indirizzo enroll.cisco.com (172.16.1.80):

ip access-list extended REDIRECT-DH-ENROLL

 permit tcp any host 10.1.1.1 eq www

 permit tcp any host 172.16.1.80

 deny   ip any any

Per mantenere un livello accettabile di sicurezza, è possibile combinare un ACL di reindirizzamento con un ACL di DACL assegnato da ISE.

Stato in sospeso Consente le connessioni solo a PSN in cui l'endpoint è stato autenticato

Questo approccio è utile per gli ambienti in cui il reindirizzamento URL non è supportato (implementazioni con NAD di terze parti).

Come soluzione, implementare più criteri di autorizzazione Postura in sospeso (uno per PSN). Ogni criterio deve contenere come condizione il nome del PSN in cui è stata eseguita l'autenticazione. Nel profilo di autorizzazione, tutti i PSN devono essere bloccati ad eccezione del nodo in cui si è verificata l'autenticazione.

Creare criteri di autorizzazione per due nodi:

Authz Policy

 

  1. Criterio di postura in sospeso per PSN1.
  2. Il nome PSN1 viene utilizzato come condizione nel criterio.
  3. Il profilo di autorizzazione con ACL blocca l'accesso a tutti i PSN ad eccezione di PSN1.
  4. Criterio di postura in sospeso per PSN2.
  5. Il nome PSN2 viene utilizzato come condizione nel criterio.
  6. Il profilo di autorizzazione con ACL blocca l'accesso a tutti i PSN ad eccezione di PSN2.
  7. Criteri di autorizzazione 'Conforme' postura.

Nella figura seguente viene illustrato il funzionamento dell'approccio:

Client Provisioning Portal 20

  1. L'autenticazione ha raggiunto PSN1.
  2. Come risultato dei criteri di autorizzazione configurati, PSN1 assegna il profilo di autorizzazione che blocca l'accesso a tutti gli altri nodi ad eccezione di PSN1.
  3. Il modulo di postura AnyConnect ISE riavvia il processo di rilevamento.
  4. La sonda per PSN2 è bloccata da NAD come da un ACL assegnato in precedenza.
  5. Probe su PSN1 consentito dall'ACL assegnato su NAD.

Best practice per il servizio di bilanciamento del carico

  • Abilitare l'adesività sul load balancer per l'autenticazione e l'accounting utilizzando Calling-Station-ID come chiave di Sticky Key. Fare riferimento a best practice per ISE con la Guida all'implementazione di Cisco e F5: ISE Load Balancing con BIG-IP.
  • Utilizzare un timer di persistenza più lungo di una giornata lavorativa media per coprire il momento in cui il PC passa alla modalità sospensione (ad esempio, 10 ore anziché 8 ore).
  • Se è implementata la riautenticazione, utilizzare il timer di riautenticazione leggermente più basso rispetto al timer di persistenza (utilizzare 8 ore se la persistenza è configurata per 10 ore). In questo modo, l'intervallo di persistenza viene prolungato con la riautenticazione.

Postura su caso di utilizzo VPN 

Accertarsi che l'intervallo di aggiornamento intermedio dell'accounting sia maggiore o uguale a vpn-session-timeout. In questo modo si riduce al minimo lo sfarfallio di accounting tra PSN durante sessioni VPN lunghe.  In questo esempio viene mostrato l'intervallo di aggiornamento della contabilità provvisoria configurato per 20 ore. Ciò non impedisce l'aggiornamento provvisorio iniziale che trasporta l'indirizzo IP assegnato all'endpoint.

aaa-server ISE protocol radius

 interim-accounting-update periodic 20

group-policy SSL-VPN attributes

 vpn-idle-timeout 1200

 vpn-session-timeout 1200

È possibile implementare best practice per ridurre al minimo l'impatto dovuto all'assenza del riavvio del modulo di rilevamento della postura ISE

Abilita lease postura 

Questa è una funzionalità di ISE che contrassegna l'endpoint come conforme per un periodo definito (1-365 giorni). Il valore del lease di postura è un attributo dell'endpoint, ossia è memorizzato nel database ISE. Tutti gli attributi dell'endpoint che includono il lease di postura vengono replicati su tutti i nodi nell'implementazione ISE.

Quando PSN riceve una nuova sessione per l'endpoint, il lease di postura può essere utilizzato per contrassegnare la sessione come conforme immediatamente. Per prendere questa decisione, PSN utilizza 3 valori, ovvero:

  1. Numero di giorni definiti per il lease della postura nelle impostazioni ISE: Passare ad Amministrazione > Sistema > Postura > Impostazioni generali:

Client Provisioning Portal 21

2. Il valore dell'attributo PostureExpiry è un attributo dell'endpoint che contiene un timestamp Epoch. Il valore PostureExpiry viene inserito inizialmente al primo tentativo riuscito di postura per l'endpoint dopo il lease di postura abilitato dall'amministratore ISE. In seguito, questo valore viene aggiornato al successivo tentativo di postura riuscito che avviene dopo la scadenza del lease. È possibile visualizzare PostureExpiry in Context Visibility > Endpoints mentre uno degli endpoint posturati è aperto:

Client Provisioning Portal 22

3. Questo valore può essere convertito nel timestamp leggibile dall'uomo, ad esempio qui - https://www.epochconverter.com/

Client Provisioning Portal 23

3. Quando l'autenticazione per un endpoint con lease di postura raggiunge il numero PSN, utilizza PostureExpiry e la data di sistema per recuperare il numero di giorni trascorsi dall'ultimo controllo di postura riuscito. Se il valore risultante rientra in un intervallo di lease di postura definito nelle impostazioni, la sessione riceve lo stato Conforme. Se il valore risultante è maggiore del valore del lease, alla sessione viene assegnato lo stato Sconosciuto. In questo modo la postura viene eseguita nuovamente e il nuovo valore di PostureExpiry può essere salvato.

In questo diagramma viene illustrato il processo in caso di failover:

Client Provisioning Portal 24

  1. L'autenticazione iniziale viene eseguita con PSN1.
  2. La sessione ABC viene creata nella cache delle sessioni.
  3. Viene eseguita la valutazione della postura.
  4. Lo stato della sessione viene modificato in Conforme.
  5. Il COA viene attivato dalla modifica dello stato della postura e determina la riautenticazione dell'endpoint da applicare al livello di accesso successivo.
  6. Il valore di PostureExpiry viene salvato nell'endpoint.
  7. I dati degli endpoint vengono replicati nell'intera distribuzione.
  8. L'autenticazione successiva raggiunge PSN2.
  9. PSN2 verifica se l'endpoint rientra in un lease di postura valido.
  10. La sessione viene aggiunta alla cache delle sessioni come conforme.
  11. A causa del lease valido, la sessione viene creata con lo stato di postura Conforme.

Implementazione della riautenticazione 

Eseguire sempre il push del timer di riautenticazione da ISE con RADIUS-Request selezionato in Mantieni connettività durante la riautenticazione. Questa impostazione assicura e mantiene lo stesso ID sessione alla riautenticazione.

Client Provisioning Portal 25

Ambienti con load balancer

È possibile implementare la stessa serie di procedure ottimali (illustrate nella sezione relativa alle sessioni obsolete/fantasma).

È possibile utilizzare subnet diverse per gli stati In sospeso e Conforme

Quando le progettazioni di rete offrono la possibilità di utilizzare subnet diverse, ad esempio stati In sospeso e Conforme, questo approccio garantisce che ogni modifica nello stato della postura determini la modifica del gateway predefinito.

Valutazione della postura utilizzata nello stesso intervallo del timer di riautenticazione

La valutazione della postura può essere abilitata con un intervallo uguale al timer di riautenticazione. Quando il PSN originale non è disponibile, l'errore PRA riavvia il processo di individuazione.

Approccio moderno - Condivisione dello stato di postura

Come parte di un miglioramento implementato (nell'ID bug Cisco CSCvi35647) patch 6 per ISE 2.6, c'è una nuova funzione che implementa la condivisione dello stato di postura della sessione su tutti i nodi nell'implementazione di ISE.

Questo miglioramento è integrato nelle future versioni di ISE 2.7, patch 2 e ISE 3.0.

Questa nuova funzionalità si basa sul meccanismo LSD (Light Session Directory) introdotto in ISE 2.6. Nelle versioni più recenti, questa funzionalità è stata rinominata LDD (Light Data Distribution) Radius Session Directory. Light Data Distribution è abilitato per impostazione predefinita e consente la condivisione di un contesto di sessione limitato tra i nodi ISE. Non esistono repliche complete del contesto di sessione tra i PSN, ma solo una quantità limitata di attributi condivisi per ogni sessione.

Light Session Directory elimina la necessità di eseguire chiamate API a MNT dispendiose in termini di risorse quando uno dei nodi nella distribuzione deve determinare il proprietario della sessione corrente. La ricerca del proprietario è obbligatoria all'avvio del flusso COA. Con LDD, ogni PSN può trovare un proprietario della sessione dalla cache della directory di sessione Radius locale. 

Light Data Distribution Architecture

Questa funzionalità contiene i seguenti elementi:

  • Cache Radius Session Directory (RSD): questa cache esiste su ogni nodo ISE e memorizza tutte le sessioni attive presentate nell'implementazione ISE. Ogni sessione dispone di una quantità limitata di attributi nella cache. Di seguito sono riportati alcuni esempi di attributi memorizzati nella directory di sessione Radius per ciascuna sessione:
    • ID sessione
    • MAC endpoint
    • IDContazioneChiamante
    • IP endpoint
    • IP PSN - PSN in cui viene eseguita l'autenticazione
    • FQDN PSN 
    • Indirizzo IP-NAS
    • Indirizzo-IPv6-NAS
    • Stato - Autenticato, Avviato, Arrestato
  • RabbitMQ Exchange: è stato formato uno scambio in cui il server di pubblicazione, la coda correlata e il consumer vengono presentati su ogni nodo dell'implementazione ISE. In questo modo vengono garantite le forme di topologia a maglia completa tra tutti i nodi ISE.
  • Autore: la directory di sessione Radius rappresenta un autore. Quando una nuova autenticazione viene elaborata da un PSN, viene creata una nuova sessione nella cache della sessione PSN. Per questa sessione, nella directory di sessione Radius viene inserito un set limitato di attributi.
  • Consumatore: In tutti gli altri nodi, la directory di sessione Radius rappresenta un consumer.
note-icon

Nota: La terminologia e l'architettura generale di RabbitMQ non rientrano in questo ambito del documento.

Nell'esempio seguente viene illustrato il funzionamento del flusso del certificato di autenticità (Certificate of Authenticity) con la cache RSD:

Client Provisioning Portal 26

  1. L'autenticazione iniziale viene eseguita con PSN1.
  2. La sessione ABC viene creata nella cache delle sessioni.
  3. Gli attributi obbligatori vengono salvati in RSD.
  4. La sessione viene condivisa su RabbitMQ con tutti gli altri nodi ISE.
  5. La sessione viene creata nella cache RSD su tutti i nodi ISE.
  6. Nuovi dati del profilo ricevuti su PSN2.
  7. L'endpoint viene riprofilato e, nel caso di una modifica che richiede l'esecuzione del certificato di autenticità (COA) PSN2, procede con il passaggio successivo.
  8. Una chiamata API interna viene inviata alla cache RSD per eseguire il processo COA.
  9. I dati della cache RSD vengono utilizzati per preparare un messaggio COA proxy. Si sposta da un nodo ISE a un altro e contiene tutti i dettagli che il nodo di destinazione può utilizzare per inviare una richiesta CAO a NAD. Il messaggio COA viene prima trasferito internamente a PRT Runtime (server AAA effettivo all'interno di ISE).
  10. PSN2 invia un messaggio COA a PSN1.
  11. PSN1 invia un messaggio COA a NAD.

Per risolvere i problemi di comunicazione su LDD sull'ISE, abilitare il componente Light-Session-Directory nel comando DEBUG:

Client Provisioning Portal 27

Questo è un esempio di messaggio di debug da un file lsd.log per la creazione di una sessione e la pubblicazione sul PSN originale:

DEBUG  [pool-45-thread-6][] cisco.cpm.lsd.service.LSDRedisClient -::::- Mapping Session ID 0a3e9498000008e05e071990 to session {"sessionID":"0a3e9498000008e05e071990","endpointMAC":"C0-4A-00-1F-6B-39","callingStationId":"c0-4a-00-1f-6b-39","ipv6AdressLst":[],"psnIP":"192.168.43.26","deviceIP":"192.168.255.102","destinationIP":"192.168.43.26","nasIP":"192.168.255.102","auditSessionID":"0a3e9498000008e05e071990","acctSessionID":"5e07197b/c0:4a:00:1f:6b:39/2299","timeStamp":1577523495,"status":"Started","id":"614f6c44-6c78-4289-b9fd-b352ff012ca4"}

DEBUG  [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.LSDNetAccessEventListener -::::- Publishing session update for session 0a3e9498000008e05e071990

DEBUG  [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.SessionPublisher -::::- Forwarding session 07a26b4b-ea13-438b-99b5-0bbadc9d8bac to batch manager

Su tutti gli altri nodi ISE, è possibile vedere come è stata usata una sessione:

[pool-35-thread-38][] cisco.cpm.lsd.service.SessionConsumer -::::- Consumer is processing : sessionID:[0a3e9498000008e05e071990] status:[Started] id:[614f6c44-6c78-4289-b9fd-b352ff012ca4] auditSessionID:[0a3e9498000008e05e071990] accountingSessionID:[5e07197b/c0:4a:00:1f:6b:39/2299] endpointMAC:[C0-4A-00-1F-6B-39] callingStationId: [c0-4a-00-1f-6b-39] endpointIP:[null], IPv6 : [[]], psnIP:[192.168.43.26] deviceIP:[192.168.255.102] destinationIP:[192.168.43.26] nasIP:[192.168.255.102] nasIPv6:[null] timeStamp:[1577523495]

Condivisione dello stato di postura su RSD

La condivisione dello stato di postura risolve i problemi quando la causa principale è una sessione non aggiornata/fantasma o una riautenticazione su un PSN diverso che non ha attivato il riavvio del rilevamento. Non appena la sessione diventa conforme, queste informazioni vengono inserite nell'RSD della sessione e possono essere utilizzate da ogni PSN della distribuzione.

La feature descritta non è in grado di risolvere altri casi d'angolo. Ad esempio, quando NAD esegue la riautenticazione sullo stesso PSN ma con un ID sessione diverso. Questi scenari possono essere gestiti seguendo le procedure consigliate descritte nel presente documento. La figura mostra la topologia utilizzata per un test di condivisione dello stato di postura:

Network

Condivisione dello stato della postura su RSD - Sessione non aggiornata/fantasma

Per creare una sessione non aggiornata, l'autenticazione deve essere inizialmente eseguita su skuchere-ise26-1. Quindi, NAD deve essere riconfigurato per inviare l'accounting a skuchere-ise26-3. Dopo che un messaggio di accounting è stato inoltrato al PSN errato, NAD deve essere riconfigurato (di nuovo) per inviare l'accounting a skuchere-ise26-1.

L'immagine mostra un rapporto contabile che prova la presenza della sessione fantasma sullo skuchere-ise26-3:

Phantom Session Accounting Report

  1. Messaggi Accounting-Start elaborati da skuchere-ise26-1.
  2. Accounting-Update provvisorio per la stessa sessione elaborato da skuchere-ise26-3.
  3. La sessione si concluderà in seguito con lo skuchere-ise26-1.

L'endpoint si connette alla rete, ma il reindirizzamento non funziona più. Nel file guest.log di PSN per skuchere-ise26-3, è possibile visualizzare questi messaggi di log con il componente client-webapp abilitato in DEBUG:

2020-04-08 13:30:48,217 DEBUG [https-jsse-nio-192.168.43.226-8443-exec-4][] cisco.cpm.client.posture.Util -::- Local session 0A3E946C0000007D5B679296 is stale. Newer session for 00-50-56-B6-0B-C6 is 0A3E946C000000805B7C43A3. Owned by skuchere-ise26-1.example.com

Quando il PSN rileva che mantiene una sessione obsoleta/fantasma per l'endpoint, non risponde al modulo di postura ISE e ciò consente di ottenere informazioni dal PSN in cui si è verificata l'ultima autenticazione.

Come soluzione al problema di sessione obsoleta/fantasma al momento della ricerca della sessione, il PSN controlla la presenza di una nuova sessione per l'endpoint nell'RSD. Se RSD contiene un ID di sessione diverso da quello del PSN nella cache della sessione locale, presuppone che la sessione (presentata nella cache della sessione) sia obsoleta.

Condivisione dello stato di postura su RSD - Failover tra PSN

Per riprodurre questo scenario, è abilitato un timer di riautenticazione breve nel profilo di autorizzazione assegnato all'endpoint con stato conforme. Successivamente, NAD viene riconfigurato per inviare l'autenticazione e l'accounting a un altro PSN (skuchere-ise26-3). Alla scadenza del timer di riautenticazione, la stessa sessione viene non autenticata sul PSN diverso. 

La figura seguente mostra un report di autenticazione che mostra il failover per la stessa sessione da skuchere-ise26-1 a skuchere-ise26-3:

Failover Between PSNs

  1. L'autenticazione viene effettuata sullo skuchere-ise26-1, a cui viene assegnato il profilo di autorizzazione con reindirizzamento.
  2. COA dopo una valutazione riuscita della postura.
  3. Viene assegnata l'autenticazione successiva per il profilo di autorizzazione allo stato conforme.
  4. L'autenticazione ha raggiunto un PSN diverso, tuttavia riceve ancora un profilo di autorizzazione per lo stato conforme.

Lo stato della sessione è conforme sul nuovo PSN dopo il failover in ise-psc.log con i componenti epm-pip e nsf-session abilitati in DEBUG:

2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045 for attribute Session Session.PostureStatus
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.PIPManager -::::- Returning a PIP com.cisco.cpm.nsf.session.impl.SessionPIP for type SESSION and flow null
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [SessionLifecycleNotifier][] cpm.nsf.session.internal.LRUAgingAlogrithm -::::- Accessed session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Returning for session 0A3E946C000000896011D045 data Attrs: {SavedUserNames=[bob@example.com], Acs.LastStepTime=1586423202174, Acs.AD-User-Qualified-Name=bob@example.com, Acs.AD-User-Resolved-DNs=CN=bob,CN=Users,DC=example,DC=com, Acs.StepData=[110=EXAMPLE, 111=bob@example.com, 112=example.com, 113=example.com, 115=example.com, 116=EXAMPLE], Acs.AD-Log-Id=[1585911138/4778, 1585911138/4779], __IntIdGrps__=[Ljava.lang.String;@6d3c29b5, IdentityGroup.Description=[Ljava.lang.String;@3fca88fb, EXAMPLE.ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, Acs.AD-Groups-Names=example.com/Users/Domain Users, Acs.AuthenCPMSessionID=0A3E946C000000896011D045, Acs.IsMachineAuthentication=false, InternalEndpoint.IdentityGroup=[Ljava.lang.String;@6daf4c5, IDStoreUserQueryCache=[EXAMPLE#bob@example.com], Acs.CurrentIDStoreName=EXAMPLE, Acs.AD-User-Join-Point=EXAMPLE.COM, Acs.Step=[24432, 24325, 24313, 24319, 24323, 24355, 24416], Acs.CustomerMessageDuplicator=, Network Access.WasMachineAuthenticated=false, IdentityGroup.Name=[Ljava.lang.String;@570ab37a, Acs.StepDataStart=110, Acs.AD-User-DNS-Domain=example.com, Network Access.AuthenticationMethod=4, Acs.AD-User-Resolved-Identities=bob@example.com, InternalUser.IdentityGroup=[Ljava.lang.String;@51a6caed, Acs.AuthenticationMethod=4, Acs.AD-User-NetBios-Name=EXAMPLE, Normalised Radius.RadiusFlowType=0, Network Access.AuthenticationIdentityStore=EXAMPLE, EXAMPLE.IdentityAccessRestricted=false, Acs.AD-User-SamAccount-Name=bob}
IndexValues: {}

2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- set postureStatus based on posture LSD dictionary: Compliant
2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- PostureStatusPIP for mac 00-50-56-B6-0B-C6 - Attribute Session.PostureStatus value is Compliant

Il problema originale viene risolto con l'aggiunta di una logica supplementare nel processo di selezione dello stato della postura. La figura mostra ciò che è stato modificato (le modifiche sono evidenziate in rosso):

Process

Cronologia delle revisioni

Revisione Data di pubblicazione Commenti
3.0
25-Aug-2026
Titolo, ortografia, grammatica e righe orizzontali inserite aggiornate per separare le sezioni in modo da garantire leggibilità, URL fissi, avvisi CCW e testo alternativo.
2.0
31-May-2023
Certificazione
1.0
22-Apr-2020
Versione iniziale
TAC Authored

Contributo dei tecnici Cisco

  • Serhii Kucherenko

Questo documento ti è stato utile?

FeedbackFeedback

Contattaci

Questo documento si applica a questi prodotti