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.
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).
In questo documento viene descritto il modo in cui comunicano Identity Service Engine (ISE) e Active Directory (AD), i protocolli utilizzati, i filtri e i flussi di Active Directory.
Cisco consiglia una conoscenza di base di:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
I tre capi di Kerberos comprendono il centro distribuzione chiavi (KDC), l'utente client e il server a cui accedere.
Il KDC viene installato come parte del controller di dominio ed esegue due funzioni di servizio: il servizio di autenticazione (AS) e il servizio di concessione ticket (TGS).
Quando il client accede inizialmente a una risorsa server, vengono coinvolti tre scambi:
Quando si accede inizialmente a una rete, gli utenti devono negoziare l'accesso e fornire un nome di accesso e una password per poter essere verificati dalla parte AS di un KDC all'interno del proprio dominio.
Il KDC ha accesso alle informazioni sull'account utente di Active Directory. Una volta autenticato, all'utente viene concesso un ticket TGT valido per il dominio locale.
Il TGT ha una durata predefinita di 10 ore e viene rinnovato per tutta la sessione di accesso dell'utente senza che l'utente debba reimmettere la propria password.
Il TGT viene memorizzato nella cache del computer locale nello spazio di memoria volatile e viene utilizzato per richiedere sessioni con servizi in tutta la rete.
L'utente presenta il TGT alla parte TGS del KDC quando è necessario accedere a un servizio server.
Il TGS sul KDC autentica il TGT utente e crea un ticket e una chiave di sessione sia per il client che per il server remoto. Queste informazioni (il ticket di servizio) vengono quindi memorizzate nella cache locale del computer client.
Il TGS riceve il TGT client e lo legge con la propria chiave. Se il TGS approva la richiesta del client, viene generato un ticket di servizio sia per il client che per il server di destinazione.
Il client legge la propria parte con la chiave di sessione TGS recuperata in precedenza dalla risposta AS.
Il client presenta la parte server della risposta TGS al server di destinazione nel successivo scambio client/server.
Esempio:
Pacchetti acquisiti da ISE per un utente autenticato:
AS-REQ contiene il nome utente. Se la password è corretta, il servizio AS fornisce un TGT crittografato con la password utente. Il TGT viene quindi fornito al servizio TGT per ottenere un ticket di sessione.
L'autenticazione ha esito positivo alla ricezione di un ticket di sessione.
Questo è un esempio di password errata fornita dal client:
Se la password è errata, la richiesta AS ha esito negativo e non viene ricevuto un TGT:
Esegue l'accesso al file ad_agent.log quando la password è errata:
2020-01-14 13:36:05,442 DEBUG ,140574072981248,krb5: Inviata richiesta (276 byte) a RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Errore ricevuto da KDC: -1765328360/Preautenticazione non riuscita,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Riprovare prima Tipi di input: 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 WARNING,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] KRB5 Codice di errore: -1765328360 (Messaggio: Preautenticazione non riuscita),LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892
2020-01-14 13:36:05,444 DEBUG ,140574072981248,[LwKrb5InitializeUserLoginCredentials()] Codice di errore: 40022 (simbolo: LW_ERROR_PASSWORD_MISMATCH),LwKrb5InitializeUserLoginCredentials(),lwadvapi/threaded/lwkrb5.c:1453
ISE utilizza MS-RPC su SMB, SMB fornisce l'autenticazione e non richiede una sessione separata per individuare la posizione di un determinato servizio RPC. Utilizza un meccanismo denominato "named pipe" per comunicare tra il client e il server.
Transazione dello scambio RPC su SMB.
OSPF (Open Shortest Path First) negotiate protocol request/response
La linea negozia il dialetto di SMB. OSPF (Open Shortest Path First) session setup request/response
esegue l'autenticazione.
La richiesta e la risposta di connessione alla struttura si connettono alla risorsa richiesta. Si è connessi a una condivisione speciale IPC$.
Questa condivisione di comunicazione tra processi fornisce i mezzi di comunicazione tra gli host e anche come trasporto per le funzioni MSRPC.
Al pacchetto 77 è Create Request File
e il nome file è il nome del servizio connesso (il servizio netlogon in questo esempio).
Ai pacchetti 83 e 86, la richiesta NetlogonSamLogonEX è dove si invia il nome utente per l'autenticazione del client su ISE all'AD sul campo Network_INFO.
Il pacchetto di risposta NetlogonSamLogonEX risponde con i risultati.
Alcuni valori dei flag per la risposta NetrlogonSamLogonEX:
0xc00006a è STATUS_WRONG_PASSWORD
0x00000000 è STATUS_SUCCESS
0x0000103 è STATUS_PENDING
ISE utilizza LDAP, KRB e MSRBC per comunicare con AD durante il processo di unione/uscita e autenticazione.
Nelle sezioni seguenti vengono illustrati i protocolli, il formato di ricerca e i meccanismi utilizzati per connettersi a un controller di dominio specifico in Active Directory e per l'autenticazione degli utenti in base a tale controller di dominio.
Nel caso in cui il controller di dominio diventi offline per qualsiasi motivo, ISE esegue il failover sul successivo controller di dominio disponibile e il processo di autenticazione non subisce modifiche.
Un server di catalogo globale è un controller di dominio in cui vengono archiviate copie di tutti gli oggetti Active Directory della foresta.
Memorizza una copia completa di tutti gli oggetti nella directory del dominio e una copia parziale di tutti gli oggetti di tutti gli altri domini della foresta.
Pertanto, il catalogo globale consente agli utenti e alle applicazioni di trovare oggetti in qualsiasi dominio della foresta corrente con una ricerca di attributi inclusi nel catalogo globale.
Il catalogo globale contiene un set di attributi di base (ma incompleto) per ogni oggetto foresta in ogni dominio (Set di attributi parziali, PAT).
Il catalogo globale riceve i dati da tutte le partizioni di directory di dominio nella foresta. Vengono copiati con il servizio di replica standard di Active Directory.
Prerequisiti per l'integrazione con Active Directory e ISE
ISE applica la funzionalità di individuazione del dominio per ottenere informazioni sul dominio di join in tre fasi:
Cisco ISE individua inoltre i nomi di dominio DNS (suffissi UPN), i suffissi UPN alternativi e i nomi di dominio NTLM.
ISE applica un'individuazione CC per ottenere tutte le informazioni sui controller di dominio e i cataloghi disponibili.
Un fattore utilizzato per calcolare la priorità del controller di dominio è il tempo impiegato dal controller di dominio per rispondere ai ping CLDAP. Una risposta più rapida riceve una priorità più alta.
Nota: CLDAP è il meccanismo utilizzato da ISE per stabilire e mantenere la connettività con i controller di dominio. Misura il tempo di risposta fino alla prima risposta DC. Non funziona se non si vede alcuna risposta da DC. Avvisa se il tempo di risposta è superiore a 2,5 secondi. CLDAP esegue il ping di tutti i controller di dominio nel sito (se non è presente alcun sito, verranno eseguiti tutti i controller di dominio nel dominio). La risposta CLDAP contiene il sito DC e il sito client (il sito a cui è assegnata la macchina ISE).
Quando ISE esce, l'AD deve considerare:
Quando il DC connesso all'ISE diventa offline o irraggiungibile per qualsiasi motivo, il failover del DC viene attivato automaticamente sull'ISE. Il failover del controller di dominio può essere attivato dalle seguenti condizioni:
In questi casi, il connettore AD avvia la selezione del controller di dominio con un elenco bloccato (il controller di dominio "danneggiato" viene inserito nell'elenco bloccato) e tenta di comunicare con il controller di dominio selezionato. Il controller di dominio selezionato nell'elenco dei controller di dominio bloccati non è memorizzato nella cache.
Il connettore AD deve completare il failover entro un tempo ragionevole (o interromperlo se non è possibile). Per questo motivo, il connettore AD tenta di utilizzare un numero limitato di controller di dominio durante il failover.
ISE blocca i controller di dominio Active Directory in caso di errore irreversibile della rete o del server per impedire ad ISE di utilizzare un controller di dominio danneggiato. Il controller di dominio non viene aggiunto all'elenco dei controller bloccati se non risponde ai ping CLDAP. L'ISE riduce solo la priorità del controller di dominio che non risponde.
ISE esegue la ricerca di computer o utenti in Active Directory in uno dei seguenti formati di ricerca. Se la ricerca riguardava un computer, ISE aggiunge "$" alla fine del nome del computer. Elenco di tipi di identità utilizzati per identificare un utente in Active Directory:
Ogni AD può avere più suffissi UPN (@alt1.com,@alt2.com,..., ecc.). Esempio: UPN principale (sajeda@cisco.com), UPN alternativo:sajeda@domain1 , sajeda@domain2
I filtri vengono utilizzati per identificare un'entità che desidera comunicare con AD. ISE cerca sempre tale entità nei gruppi utenti e computer.
Esempi di filtri di ricerca:
Se il nome SAM non è univoco, ISE utilizza la password per distinguere gli utenti e ISE è configurato per utilizzare un protocollo senza password, ad esempio EAP-TLS.
Non esistono altri criteri per individuare l'utente giusto, quindi ISE non riesce l'autenticazione con un errore di "Identità ambigua".
Tuttavia, se il certificato utente è presente in Active Directory, Cisco ISE utilizzerà il confronto binario per risolvere l'identità.
Se esiste una corrispondenza unica, Cisco ISE procede con il flusso AAA.
Se sono presenti più punti di join con lo stesso UPN e la stessa password o con lo stesso UPN e la stessa posta, Cisco ISE non riesce a eseguire l'autenticazione con un errore di "identità ambigua".
Se nell'identità è stato specificato un suffisso di dominio completo, ad esempio host/machine.domain.com, Cisco ISE eseguirà una ricerca nella foresta in cui è presente il dominio.
Se l'identità è nel formato host/computer, Cisco ISE cerca il nome dell'entità servizio in tutte le foreste.
In caso di più corrispondenze, Cisco ISE non riesce l'autenticazione con un errore di "Identità ambigua".
Nota: gli stessi filtri si trovano nei file ad-agent.log di ISE
Nota: ISE 2.2 patch 4 e precedenti e 2.3 patch 1 e gli utenti precedentemente identificati con gli attributi SAM, CN o entrambi. Cisco ISE, release 2.2 Patch 5 e successive, e 2.3 Patch 2 e successive, utilizzano solo l'attributo sAMAccountName come attributo predefinito.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
2.0 |
03-Aug-2022 |
Grammatica, struttura, traduzione automatica, stile, formato |
1.0 |
06-Feb-2020 |
Versione iniziale |