Risoluzione dei problemi di gestione e postura delle sessioni ISE

Introduzione

Questo documento descrive il problema comune relativo ai servizi di postura di Identity Service Engine (ISE): "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 è conforme quando lo stato della sessione è 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 un conseguente impatto grave.

Questo documento spiega:

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

Per una migliore spiegazione dei concetti descritti più avanti, fare riferimento a:

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:

Esperienza di amministrazione ISE

Normalmente, nella fase iniziale di valutazione del problema, l'amministratore ISE esegue un'indagine dei log Radius Live per verificare che ci sia un'autenticazione effettiva per accedere all'ISE.

Il primo sintomo rilevato in questa fase indica una mancata corrispondenza in uno stato di postura tra l'endpoint e ISE, come nei log attivi o nei report di autenticazione Radius l'ultima autenticazione riuscita per l'endpoint mostra lo stato di postura in sospeso.

Tipica esperienza di amministrazione ISE:

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

Nota: 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 (descritte 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 in modo errato dal PSN (Policy Service Node) durante il processo di postura che ha causato la visualizzazione dello stato di postura errato. 

In questo caso, in genere viene utilizzata 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, ci sono due persone responsabili del processo di gestione della sessione: PSN e MNT (Monitoring Node).

Per risolvere e identificare correttamente questo problema, è fondamentale comprendere la teoria della gestione delle sessioni su entrambe le persone.

Gestione di MNT e sessioni

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 su MNT si verifica in 3 scenari:

1. Le sessioni senza avvio contabilità vengono rimosse circa 60 minuti dopo la loro creazione: è presente un job cron eseguito ogni 5 minuti per controllare 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 anche le sessioni che sono state 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 Syslog per la sessione.

Esempi di messaggi syslog da PSN:

Questi messaggi vengono registrati in port-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 dello stato 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.

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.
• PSN ha ottenuto un aggiornamento temporaneo di accounting per la sessione che non esiste nella cache della sessione.

Per quanto riguarda la rimozione delle sessioni, 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 delle 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:

1. L'autenticazione viene eseguita correttamente sul PSN per la sessione ABC.

2. Il PSN crea una voce nella cache della sessione.

3. La valutazione della postura avviene.

4. La sessione è contrassegnata come conforme.

5. Il cambiamento di autorizzazione (attivato dalla modifica dello stato della postura) comporta la riautenticazione dell'endpoint per applicare il livello di accesso successivo.

6. L'interruzione della contabilità per la sessione ABC viene trasferita a PSN2.

In seguito, ABC rimane bloccato nello stato non aggiornato su PSN1 perché non è stato elaborato alcun messaggio di interruzione dell'accounting su questo PSN per rimuoverlo.

La sessione viene rimossa per un periodo di tempo prolungato 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 è arrivato 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 che causano il failover di NAD al PSN successivo.

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

1. L'autenticazione iniziale per la sessione ABC viene eseguita da PSN 1.

2. Questa autenticazione avvia un timer di persistenza sul load balancer.

3. Il PSN 1 crea una voce per la sessione ABC nella cache locale.

4. Messaggio syslog per l'autenticazione passata trasferita al nodo MNT.

5. La voce relativa alla sessione ABC viene creata nella directory di sessione MNT con lo stato Autenticato.

6. Messaggio di avvio della contabilità per la sessione ABC termina su PSN 1.

7. La voce della cache delle sessioni per la sessione ABC viene aggiornata con le informazioni di Accounting-Start.

8. Il messaggio Syslog per Accounting-Start viene trasferito al nodo MNT.

9. Lo stato della sessione viene aggiornato su Avviata.

10. Il timer di persistenza scade sul load balancer.

11. Accounting-Stop per la sessione ABC viene inoltrato dal servizio di bilanciamento del carico a PSN 2.

12. Il messaggio Syslog per Accounting-Stop viene inoltrato dal PSN 2 al MNT.

13. La sessione ABC è contrassegnata come terminata il MNT.

Sessione fantasma nel PSN

La sessione fantasma è uno scenario in cui l'aggiornamento intermedio di accounting arriva al PSN che non ha eseguito l'autenticazione per questa sessione specifica. 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:

1. La stessa procedura descritta nell'esempio di sessione non aggiornata viene eseguita su PSN1 per la sessione ABC.

2. Lo stato della sessione ABC è Conforme nella cache della sessione PSN1.

3. Un aggiornamento intermedio della contabilità per la sessione ABC ha riscontrato PSN2.

4. Una voce di sessione per la sessione ABC viene creata su PSN2. Poiché la voce della sessione viene creata dal messaggio di accounting, dispone di un numero limitato di attributi. Ad esempio, lo stato della postura non è disponibile per la sessione ABC. Mancano anche elementi quali i gruppi di utenti e altri attributi specifici delle autorizzazioni.

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 servizio di bilanciamento del carico.

Di seguito è riportato un esempio di sessione fantasma per lo scenario con problemi temporanei nel percorso di rete verso PSN1:

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 della contabilità 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 della contabilità provvisoria per la sessione ABC viene inoltrato a PSN2.

10. PSN2 crea una voce per la sessione ABC nella cache locale.

11. L'arresto della contabilità per la sessione ABC viene inoltrato a PSN1.

12. La voce relativa alla sessione ABC viene rimossa dalla cache delle sessioni su PSN1.

13. Un messaggio syslog per Accounting-Stop viene inoltrato da PSN 1 a MNT.

14. La sessione ABC viene contrassegnata come terminata il MNT.

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

1. Autenticazione iniziale su PSN1.

2. La sessione ABC viene creata nella cache delle sessioni.

3. La contabilità avvia il messaggio elaborato dal PSN.

4. Il nuovo indirizzo IP viene assegnato alla scheda di rete VPN (Virtual Private Network).

5. Un aggiornamento contabile temporaneo con informazioni sull'indirizzo IP viene eseguito sul 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), che attiva l'assegnazione di un nuovo livello di accesso.

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 viene eseguito in 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 la sessione non aggiornata e la sessione fantasma interrompono la postura, è possibile rivedere il processo di rilevamento del modulo di postura di AnyConnect ISE:

Individuazione fase 1:

In questa fase, il modulo di postura ISE esegue 4 problemi simultanei per individuare il PSN che ha eseguito un'autenticazione per l'endpoint.

In primo luogo, 3 probe sulla cifra sono basate sul reindirizzamento (IP GW predefinito). Discovery host IP (se definito) e enroll.cisco.com IP; queste sonde puntano sempre l'agente al PSN corretto in quanto l'URL reindirizzato viene preso dal NAD stesso.

La sonda numero 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 seguito nel caso in cui il client esegua la migrazione tra i 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, il risultato della sonda 4 viene utilizzato solo se tutte le altre 3 sonde hanno avuto esito negativo o se il modulo di postura ISE non è stato in grado di stabilire una corretta comunicazione con il PSN restituito nell'URL di reindirizzamento entro 5 secondi.

Quando il probe 4 atterra sul PSN, contiene un elenco di indirizzi IP e MAC attivi rilevati 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ù rapida.

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 riesce a 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 di sessioni, la fase 2 del rilevamento può essere ulteriormente influenzata da problemi derivanti da sessioni obsolete o fantasma.

Se il PSN raggiunge la 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.

Nell'esempio viene mostrato come si verifica la postura quando il PSN mantiene una sessione obsoleta o una sessione fantasma:

Nota: questo problema può verificarsi solo quando tutte le richieste di rilevamento basate sul reindirizzamento hanno esito negativo o quando viene implementata la postura di non reindirizzamento.

1. Una qualsiasi delle sonde Find my session emesse dal modulo di postura ISE.

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 priva di attributi di autenticazione/autorizzazione e tutti i criteri configurati dal cliente sono molto 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. Questa condizione può essere rilevata nel messaggio di errore: "Ignorando AnyConnect, la rete è configurata per l'utilizzo 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 ai criteri della configurazione AnyConnect), il PSN risponde con i dettagli necessari per la continuazione del processo di valutazione.
• In questa fase, quando è possibile gestire sessioni non aggiornate, il PSN risponde immediatamente con lo stato di postura Conforme e tutte le fasi successive non vengono eseguite. 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 di 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. Poiché a questo punto la sessione fantasma non dispone di attributi, non esistono criteri per la corrispondenza. In questo caso, PSN risponde all'endpoint che è conforme. Si tratta di un comportamento ISE predefinito in caso di criteri di postura non corrispondenti. 

Nota: quando esistono criteri generici che è possibile selezionare dagli attributi della sessione fantasma, si continua con il passo 6.

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

Nota: se non è possibile selezionare alcun criterio, 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 in caso di modifiche dello stato della sessione e di ISE a Conforme.

Nota: in caso di problemi di postura causati dalla sessione fittizia, l'amministratore ISE può notare alcuni errori di postura. In questi casi, 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 CSCvo6957

Il modulo ISE posture non rileva nuove autenticazioni dot1x, sblocco del PC e modifica dell'indirizzo IP.

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

• 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 in un PSN diverso causata dall'interruzione del PSN originale. Uno scenario con un load balancer è molto simile.

Nel caso di un load balancer, la riautenticazione viene indirizzata al diverso PSN come risultato di una scadenza del timer di persistenza.

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 ABS della sessione viene impostato su Conforme.

5. Il certificato di autenticità (COA) 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:

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

E genera un nuovo ID sessione alla riautenticazione

Questo può accadere nei due scenari più comuni:

• La riautenticazione non è configurata correttamente sul lato ISE. La soluzione a questo problema è illustrata più avanti in questo documento.
• Comportamento errato dal lato AND. Normalmente AND mantiene lo stesso ID sessione durante il tentativo di riautenticazione. Si tratta di un comportamento potenzialmente problematico che deve essere esaminato sul NAD stesso.

Il nuovo ID di sessione può essere generato in altri scenari con casi d'angolo. In alcuni casi, ad esempio, il roaming wireless può essere la causa di questo problema.

La cosa principale qui è che ISE PSN mette sempre una nuova sessione nello stato postura in sospeso a meno che il lease della postura non sia configurato. Il lease della postura è descritto più avanti in questo documento.

Metodo rapido per identificare quando il problema è stato causato dalla sessione non aggiornata/fantasma

Per stabilire se AnyConnect mostra la conformità mentre è in stato di reindirizzamento, è possibile che la sessione sia obsoleta o fittizia. È necessario ottenere l'accesso all'endpoint mentre si trova nello stato problematico.

1.  Analizzare i dettagli della scansione del sistema:
   
   

     1. Fare clic sull'icona gear nell'interfaccia utente di AnyConnect

   

         2. Nella nuova finestra passare a Scansione sistema > Statistiche

   

           Prestare attenzione a due elementi:

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

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

Risoluzione avanzata dei problemi di sessioni obsolete/fantasma

L'esempio precedente serve a distinguere il problema di una sessione obsoleta o fittizia dal problema del processo di rilevamento non avviato.

Allo stesso tempo, dobbiamo identificare la sessione effettiva che ha innescato il problema per capire meglio come esattamente diventi un problema di sessione obsoleta o fantasma.

Sebbene in alcuni scenari non sia possibile evitare sessioni obsolete e fantasma, è necessario garantire l'implementazione di procedure ottimali in modo che non vengano create sessioni obsolete o fantasma nell'ambiente.

DART Bundle Collection

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

• Conservare solo i registri importanti nel DART. Si consiglia di cancellare i registri prima di riprodurre il problema. 

Per ottenere questo risultato, l'utility del bundle DART deve essere avviata come amministratore ed eseguire la pulizia del log. 

1. In Windows passare a Start e iniziare a digitare DART, fare clic con il pulsante destro del mouse e scegliere - Esegui come amministratore
   
   
2. Nella prima schermata della procedura guidata fare clic su Avanti.
   
   
3. Nella schermata successiva della procedura guidata fare clic su Cancella tutti i registri.
   
   

4. Una volta riprodotto il problema, sarà possibile raccogliere i dati DART da qui. Fare clic su Avanti.

Analisi bundle DART

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

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 del rilevamento o il rilevamento HTTP. Passare alla riga con il riavvio del rilevamento che si è verificato nel momento in cui si è verificato il problema:

2. Diverse righe dopo il riavvio del rilevamento, c'è una riga che contiene - Probing no MNT stage targets. Questo è un indicatore dell'avvio del rilevamento della Fase 1:

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 molto simili ed è difficile individuare la differenza.

3. Leggere i file di log per vedere un risultato per ciascuna sonda. Questo è un esempio di come appare la sonda guasta:

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

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 diventa obsoleta/fantasma:

Indagine sui log ISE

 Nel file guest.log con il componente clientwebapp abilitato in DEBUG, è possibile visualizzare il PSN che risponde con la sessione non aggiornata/fantasma.

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

La richiesta contiene matrici di indirizzi IP e indirizzi MAC. In questo particolare 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 della sonda non basata sul reindirizzamento.

In seguito sarà possibile vedere come i valori degli array vengono utilizzati 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

Dopo la riga con le parole chiave Inviata risposta http, è possibile visualizzare il contenuto della risposta effettiva:

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

Dopo aver individuato l'ID della sessione non aggiornata/fantasma, è possibile esaminare il report Contabilità Radius per comprendere meglio le cause che hanno determinato lo stato di questa sessione:

• 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.

Di seguito è riportato un esempio di report che mostra come è stata lasciata una sessione non aggiornata su ciscolive-ise2:

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

Un modo rapido per identificare quando il problema è stato causato dall'assenza del riavvio del rilevamento

In questo caso, è possibile seguire la stessa logica del problema precedente. L'unica differenza è che è necessario concentrarsi sull'ora di inizio dell'ultima scansione. Per questo tipo di problema, la data e l'ora dell'ultima analisi sono già trascorse.

Normalmente, quando l'utente finale rileva un problema, viene visualizzata una scansione eseguita qualche tempo fa. 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

L'approccio qui descritto è molto simile alla sezione Risoluzione avanzata dei problemi relativi alle 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 di individuazione (come illustrato per il problema precedente) e confermare che non è stato eseguito alcun riavvio di individuazione al momento della segnalazione del problema.

Sul lato ISE, esaminare il report di autenticazione Radius Live Logs/Radius per verificare che sia stato generato il failover tra i PSN o un nuovo ID sessione da NAD.

Soluzione

Approccio classico - Prevenzione dei problemi

Storicamente ISE non aveva una funzione in grado di risolvere i problemi descritti in questo documento, quindi l'unico modo è stato affidarsi alla serie di best practice implementate sulla rete e dal lato ISE 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 è un'esperienza utente errata; vengono visualizzati popup 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, questo ACL di reindirizzamento può essere combinato 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 dell'URL non è supportato (ad esempio le implementazioni con NAD di terze parti).

Come soluzione, implementare più criteri di autorizzazione PosturePending (uno per PSN). Ogni criterio deve contenere come condizione il nome del PSN in cui è stata eseguita l'autenticazione.

Nel profilo di autorizzazione assegnato a ogni criterio è necessario bloccare l'accesso a tutti i nomi di servizio (PSN) ad eccezione del nodo in cui è stata eseguita l'autenticazione.

Creare criteri di autorizzazione per la distribuzione su 2 nodi:

 

1. Criterio di postura in sospeso per PSN1

2. Nome PSN1 utilizzato come condizione nel criterio.

3. Profilo di autorizzazione con ACL che blocca l'accesso a tutti i PSN ad eccezione di PSN1.

4. Criteri in sospeso della postura per PSN2.

5. Nome PSN2 utilizzato come condizione nel criterio.

6. Profilo di autorizzazione con ACL che blocca l'accesso a tutti i PSN ad eccezione di PSN2.

7. Regole di autorizzazione della postura "conforme".

La figura spiega come funziona questo approccio:

1. L'autenticazione ha raggiunto PSN1.

2. Come risultato dei criteri di autorizzazione configurati, PSN1 assegna un profilo di autorizzazione che blocca l'accesso a tutti gli altri nodi tranne PSN1.

3. Il modulo di postura AnyConnect ISE riavvia il processo di rilevamento.

4. La sonda per PSN2 è bloccata dal NAD come da un ACL assegnato in precedenza.

5. Il 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. Per maggiori informazioni sulle best practice di IBM per ISE, fare clic qui.
• Utilizzare un timer di persistenza più lungo di una giornata lavorativa media per coprire il momento in cui il PC entra in sospensione (ad esempio, 10 ore anziché 8).
• Se viene implementata la riautenticazione, utilizzare un timer di riautenticazione leggermente inferiore al timer di persistenza (ad esempio, 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 

• Verificare che l'intervallo di aggiornamento intermedio di 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 funzionalità di ISE contrassegna l'endpoint come conforme per un periodo definito (1-365 giorni). Il valore del lease di postura è un attributo dell'endpoint, il che significa che è archiviato in ISE DB.

Tutti gli attributi dell'endpoint che includono il lease di postura vengono replicati su tutti i nodi nell'implementazione ISE.

Quando PSN ottiene una nuova sessione per la postura dell'endpoint, è possibile contrassegnare immediatamente la sessione come conforme.

Per prendere questa decisione, il PSN utilizza 3 valori. Tali valori sono:

1. Quantità di giorni definita per il leasing della postura nelle impostazioni ISE: passare ad Amministrazione > Sistema > Postura > Impostazioni generali:

2. Il valore dell'attributo PostureExpiry è un attributo effettivo dell'endpoint che contiene un timestamp Epoch. Il valore di 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 si verifica dopo la scadenza del lease.

            È possibile visualizzare PostureExpiry in Context Visibility > Endpoints mentre uno degli endpoint posturati è aperto:

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

3. Ora di sistema PSN nel momento in cui viene eseguita la nuova autenticazione

Quando l'autenticazione per un endpoint con lease di postura raggiunge il PSN, utilizza PostureExpiry e la data di sistema per ottenere 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, alla sessione viene assegnato lo stato Conforme.

Se il valore risultante è superiore al 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:

1. L'autenticazione iniziale viene eseguita con PSN1.

2. La sessione ABC viene creata nella cache delle sessioni.

3. La valutazione della postura avviene.

4. Lo stato della sessione cambia in Conforme

5. Il certificato di autenticità (COA) viene attivato dalla modifica dello stato della postura e determina la riautenticazione dell'endpoint per applicare il 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.

11. La sessione viene aggiunta alla cache delle sessioni come conforme.

12. 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 garantisce che NAD mantenga lo stesso ID sessione durante la riautenticazione.

.

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 la progettazione della rete offre la possibilità di utilizzare diverse subnet con 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. In questo caso, quando il PSN originale non è più disponibile, l'errore PRA riavvia il processo di rilevamento.

Approccio moderno - Condivisione dello stato di postura

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

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

Questa nuova funzionalità si basa sul meccanismo LSD (Light Session Directory), introdotto ad 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 esiste una replica completa 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 è in genere necessaria all'avvio del flusso COA. Con LDD ogni PSN può trovare un proprietario effettivo della sessione dalla cache della directory di sessione Radius locale. 

Light Data Distribution Architecture

Questa funzionalità contiene i seguenti elementi:

• Cache RSD (Radius Session Directory)

Questa cache esiste su ogni nodo ISE e archivia 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 degli attributi memorizzati nella directory di sessione Radius per ciascuna sessione:

• ID sessione
• MAC endpoint
• IDContazioneChiamante
• IP endpoint
• IP PSN - PSN in cui è stata eseguita l'autenticazione
• FQDN PSN 
• Indirizzo IP-NAS
• Indirizzo-IPv6-NAS
• Stato - Autenticato, Avviato, Arrestato

• Scambio RabbitMQ

In questo formato, Publisher, la coda correlata e Consumer vengono presentati in ogni nodo dell'implementazione ISE. Ciò assicura che la topologia a maglia completa si formi tra tutti i nodi ISE.

• Autore

La directory di sessione Radius rappresenta qui un server di pubblicazione. 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.

• Consumer - su tutti gli altri nodi; Radius Session Directory rappresenta un consumer.

Nella figura viene illustrato il funzionamento del flusso del certificato di autenticità (COA) con la cache RSD:

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 di profilo vengono ricevuti su PSN2.

7. Viene eseguito il reprofiling dell'endpoint e, nel caso di una modifica che richiede l'esecuzione del certificato di autenticità (COA) con PSN2, l'operazione prosegue.

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. Va 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 Director in DEBUG:

Di seguito è riportato un esempio di messaggio di debug dal file lsd.log per la creazione di sessioni 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 della postura risolve i problemi quando la causa principale è una sessione non aggiornata/fantasma o la 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 in seguito possono essere utilizzate da ogni PSN della distribuzione.

La feature descritta non è ancora in grado di risolvere altri problemi d'angolo. Ad esempio, uno scenario in cui NAD esegue la riautenticazione sullo stesso PSN ma con un ID sessione diverso.

Tali scenari possono essere gestiti seguendo le procedure ottimali descritte nel presente documento.

La figura mostra la topologia utilizzata per un test di condivisione dello stato di postura:

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

Per creare una sessione non aggiornata, è necessario eseguire inizialmente l'autenticazione sullo 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, AND deve essere riconfigurato (di nuovo) per inviare l'accounting a skuchere-ise26-1.

La figura mostra una relazione contabile che prova la presenza della sessione fantasma su skuchere-ise26-3:

1. Messaggi Accounting-Start elaborati da skuchere-ise26-1.

2. Contabilità provvisoria-Aggiornamento per la stessa sessione elaborato da skuchere-ise26-3.

3. La sessione si concluderà in seguito con il skuchere-ise26-1.

Dopo qualche tempo, l'endpoint si connette nuovamente alla rete ma il reindirizzamento non funziona più. Nel file guest.log di PSN - 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 contiene una sessione non aggiornata/fittizia per l'endpoint, non risponde al modulo di postura ISE e ciò consente di ottenere la risposta corretta dal PSN in cui è stata eseguita 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 di PSN nella cache della sessione locale, presuppone che la sessione (presentata nella cache della sessione) non sia aggiornata.

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 mostra un report di autenticazione che mostra il failover per la stessa sessione da skuchere-ise26-1 a skuchere-ise26-3:

1. L'autenticazione avviene su skuchere-ise26-1, il profilo di autorizzazione con reindirizzamento è assegnato.

2. Costo del lavoro dopo una valutazione positiva della postura.

3. Autenticazione successiva quando viene assegnato il profilo di autorizzazione per lo stato di conformità.

4. L'autenticazione ha raggiunto un numero PSN diverso ma ottiene comunque il profilo di autorizzazione per lo stato di conformità.

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):