Informazioni su Identity Service Engine e Active Directory

Introduzione

In questo documento viene descritto il modo in cui vengono comunicati ISE (Identity Service Engine) e Active Directory (AD), i protocolli utilizzati, i filtri e i flussi di Active Directory.

---

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di base di:

• External Identity Authentication su ISE
• Integrazione di ISE 2.x e Active Directory

---

Componenti usati

• ISE 2.x 
• Server Windows (Active Directory) 

---

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.

---

Protocolli AD

Protocollo Kerberos  

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:

1. AS Exchange
2. TGS Exchange
3. Exchange client/server (CS)

---

---

• Controller di dominio = KDC (AS + TGS)
• Autenticazione in AS (il portale SSO) con la password
• Ottenere un ticket di concessione ticket (TGT) (un cookie di sessione)
• Richiedi accesso a un servizio (SRV01)
• SRV01 ti reindirizza a KDC
• Mostra TGT a KDC - (già autenticato)
• KDC offre TGS per SRV01
• Reindirizza a SRV01
• Mostra ticket di servizio per SRV01
• SRV01 verifica/considera attendibile il ticket di servizio
• Il ticket di assistenza contiene tutte le informazioni
• SRV01: accesso

---

Quando si accede inizialmente a una rete, gli utenti devono negoziare l'accesso e fornire un nome di accesso e una password che devono 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 immettere nuovamente la 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 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 dell'utente. Al TGT viene quindi fornito il servizio TGT per ricevere un ticket di sessione. L'autenticazione ha esito positivo quando viene ricevuto un ticket di sessione.

---

Questo è un esempio di password fornita dal client non corretta:

---

Se la password non è corretta, la richiesta AS ha esito negativo e il TGT non viene ricevuto:

---

Nell'esempio successivo, si tratta dei log nel file ad_agent.log quando la password non è corretta:

2020-01-14 13:36:05,442 DEBUG ,140574072981248,krb5: Richiesta inviata (276 byte) a RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Ricevuto errore da KDC: -1765328360/Preautenticazione non riuscita,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325

2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Preautenticazione - riprova 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

---

Protocollo MS-RPC

ISE utilizza MS-RPC su SMB e 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.

---

• Creare una connessione di sessione SMB
• Trasporta messaggi RPC su SMB/CIFS.TCP porta 445 come trasporto 
• La sessione SMB identifica la porta utilizzata da un determinato servizio RPC e gestisce l'autenticazione utente
• Connessione alla condivisione nascosta IPC$ per la comunicazione tra processi
• Aprire una named pipe appropriata per la funzione o la risorsa RPC desiderata
• Transazione scambio RPC su SMB

---

---

La riga di negoziazione richiesta/risposta protocollo negozia il dialetto di SMB e la richiesta/risposta di impostazione sessione 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.

---

Il pacchetto 77 è il file di richiesta di creazione e il nome del file è il nome del servizio connesso (il servizio netlogon in questo esempio).

I pacchetti 83 e 86 sono la richiesta NetlogonSamLogonEX, dove si invia il nome utente per l'autenticazione del client su ISE all'AD del 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

---

Integrazione di ISE con Active Directory (AD)

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. Se per qualsiasi motivo il controller di dominio non è più in linea, ISE eseguirà il failover sul successivo controller di dominio disponibile e il processo di autenticazione non subirà modifiche.

---

Un server di catalogo globale è un controller di dominio in cui vengono archiviate copie di tutti gli oggetti di Active Directory nella 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. 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 della 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 e vengono copiati con il servizio di replica di Active Directory standard.

---

Iscriviti ad ISE 2008

Prerequisiti per le integrazioni di Active Directory e ISE.

1. Verificare di disporre dei privilegi di amministratore privilegiato o di amministratore di sistema in ISE.
2. Utilizzare le impostazioni del server NTP (Network Time Protocol) per sincronizzare l'ora tra il server Cisco e Active Directory. La differenza massima consentita tra ISE e AD è di 5 minuti.
3. Il DNS configurato su ISE deve rispondere alle query SRV per controller di dominio, cataloghi globali e controller di dominio di primo livello con o senza ulteriori informazioni sul sito.
4. Verificare che tutti i server DNS siano in grado di rispondere alle query DNS di inoltro e di inversione per ogni possibile dominio DNS di Active Directory.
5. AD deve disporre di almeno un server di catalogo globale operativo e accessibile da Cisco, per il dominio a cui si intende aggiungere Cisco.

---

Aggiungi a dominio Active Directory

ISE applica la funzionalità di individuazione del dominio per ottenere informazioni sul dominio di join in tre fasi:

1. Interroga i domini uniti: individua i domini della relativa foresta e i domini trusted esternamente al dominio aggiunto.
2. Interroga i domini radice nella relativa foresta - Stabilisce il trust con la foresta.
3. Interroga i domini radice nelle foreste trusted: individua i domini dalle foreste trusted.

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.

1. Il processo di aggiunta inizia con le credenziali di input di un amministratore privilegiato in Active Directory che esistono nel dominio stesso. Se esiste in un dominio o un sottodominio diverso, il nome utente deve essere indicato in una notazione UPN (username@domain).
2. ISE invia una query DNS per tutti i record di controller di dominio, cataloghi globali e KDC. Se la risposta DNS non riceve una risposta, l'integrazione non riesce e viene restituito un errore relativo al DNS.
3. ISE utilizza il ping CLDAP per individuare tutti i controller di dominio e i cataloghi tramite le richieste CLDAP inviate ai controller di dominio che corrispondono alle relative priorità nel record SRV. Viene utilizzata la prima risposta del controller di dominio e l'ISE viene collegata a tale controller di dominio.

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.

---

---

4. ISE riceve il TGT con le credenziali di "join user".
5. Generare il nome dell'account del computer ISE con MSRPC (SAM e SPN.)
6. Cercare Active Directory in base all'SPN se l'account del computer ISE esiste già. Se la macchina ISE non esiste, ISE ne crea una nuova.
7. Aprire l'account Machine e impostare la password dell'account del computer ISE, quindi verificare che l'account del computer ISE sia accessibile.
8. Impostare gli attributi dell'account del computer ISE (SPN, dnsHostname e così via).
9. Ricevere TGT con le credenziali del computer ISE con KRB5 e individuare tutti i domini trusted.
10. Una volta completato il join, il nodo ISE aggiorna i gruppi AD e i SID associati e avvia automaticamente il processo di aggiornamento del SID. Verificare che il processo possa essere completato dal lato Active Directory.

---

Lascia il dominio Active Directory

Quando ISE esce, l'AD deve considerare:

1. Utilizzare un utente amministratore AD completo per eseguire i processi di uscita. Verifica che l'account del computer ISE venga rimosso dal database di Active Directory.
2. Se AD viene lasciato senza credenziali, l'account ISE non viene rimosso da AD e deve essere eliminato manualmente.
3. Quando reimposta la configurazione ISE dalla CLI o ripristina la configurazione dopo un backup o un aggiornamento, esegue un'operazione di uscita e disconnette il nodo ISE dal dominio Active Directory. Se aggiunto, tuttavia, l'account del nodo ISE non viene rimosso dal dominio Active Directory.
4. È consigliabile eseguire un'operazione di uscita dal portale di amministrazione con le credenziali di Active Directory, poiché rimuove anche l'account del nodo dal dominio di Active Directory. Questa opzione è consigliata anche quando si modifica il nome host ISE.

---

Failover DC

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:

1. Il connettore AD rileva che il controller di dominio attualmente selezionato non è più disponibile durante alcuni tentativi di comunicazione CLDAP, LDAP, RPC o Kerberos. In questi casi, il connettore AD avvia la selezione del controller di dominio e ne esegue il failover nel controller di dominio appena selezionato.
2. Il controller di dominio è attivo e risponde al ping CLDAP. Tuttavia, il connettore AD non è in grado di comunicare con esso per qualche motivo (ad esempio, la porta RPC è bloccata, il controller di dominio è in stato di 'replica interrotta', il controller di dominio non è stato rimosso correttamente dalle autorizzazioni).

---

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 periodo di 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. L'ISE blocca i controller di dominio Active Directory in caso di errore irreversibile della rete o del server per impedire all'ISE di utilizzare un controller di dominio danneggiato. Il controller di dominio non verrà aggiunto all'elenco dei controller bloccati se non risponde ai ping CLDAP. L'ISE riduce la priorità del controller di dominio solo se non risponde.

---

Comunicazione ISE-AD tramite LDAP

ISE cerca un computer o un utente in Active Directory con uno di questi 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:

---

• Nome SAM: Nome utente o nome computer senza markup di dominio. Si tratta del nome di accesso utente in Active Directory. Esempio: sajeda o sajeda$

• CN: Questo è il nome visualizzato dell'utente in Active Directory e non deve essere uguale al SAM. Esempio: sajeda Ahmed

• Nome entità utente (UPN): È una combinazione del nome SAM e del nome di dominio (SAM_NAME@domian). Esempio: sajeda@cisco.com o sajeda$@cisco.com

• UPN alternativo: Si tratta di un suffisso UPN aggiuntivo/alternativo configurato in Active Directory diverso dal nome di dominio. Questa configurazione viene aggiunta globalmente in Active Directory (non configurata per utente) e non è necessaria per essere un suffisso di nome di dominio reale.
  • Ogni AD può avere più suffissi UPN (@alt1.com,@alt2.com e così via). Ad esempio, UPN principale (sajeda@cisco.com), UPN alternativo:sajeda@domain1, sajeda@domain2

• Nome prefisso NetBIOS: Nome di dominio/nome utente del nome del computer. Ad esempio, CISCO\sajeda o CISCO\machine$

• Host/Prefisso con un computer non qualificato: Viene utilizzata per l'autenticazione del computer quando si utilizza solo il nome del computer e si tratta solo del nome dell'host o del computer. Ad esempio, host/computer.

• Host/prefisso con computer completo: Utilizzato per l'autenticazione del computer quando viene utilizzato il nome di dominio completo del computer, in genere in caso di autenticazione del certificato. Si tratta dell'host/FQDN del computer. Ad esempio, host/machine.cisco.com.

• Nome SPN: Il nome di un client identifica in modo univoco un'istanza di un servizio (ad esempio, HTTP, LDAP, SSH) utilizzata solo per il computer.

---

Autenticazione utente in base al flusso AD:

1. Risolvi identità e determina il tipo di identità: SAM, UPN, SPN. Se ISE riceve l'identità solo come nome utente, cerca un account SAM associato in AD. Se ISE riceve l'identità come username@domain, cerca un UPN o un'e-mail corrispondente in AD. In entrambi gli scenari, ISE utilizza filtri aggiuntivi per il computer o il nome utente. 
2. Cerca nel dominio o nella foresta (a seconda del tipo di identità).
3. Mantieni informazioni su tutti gli account associati (JP, DN, UPN, Dominio).
4. Se non viene trovato alcun account associato, AD risponde con l'utente sconosciuto.
5. Eseguire l'autenticazione MS-RPC (o Kerberos) per ogni account associato.
6. Se solo un account corrisponde all'identità e alla password di input, l'autenticazione avrà esito positivo.
7. Se più account corrispondono all'identità in ingresso, ISE utilizza la password per risolvere l'ambiguità e l'account con una password associata viene autenticato, mentre gli altri account aumentano di 1 il contatore della password errato.
8. Se nessun account corrisponde all'identità e alla password in ingresso, AD risponde con una password errata.

---

Filtri di ricerca ISE

I filtri vengono utilizzati per identificare un'entità per comunicare con AD. ISE cerca sempre un'entità nel gruppo utenti e computer. Esempi di filtri di ricerca:

1. Ricerca SAM: Se ISE riceve un'identità come solo nome utente senza alcun markup di dominio, considera il nome utente come SAM e cerca in AD tutti i computer, utenti o computer che hanno un'identità come nome SAM.
2. 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.
3. Non esistono altri criteri per individuare l'utente corretto, quindi ISE non riesce l'autenticazione con un errore di "Identità ambigua". Tuttavia, se il certificato utente è presente in Active Directory, Cisco ISE utilizza un confronto binario per risolvere l'identità.

---

---

2. Ricerca UPN o POSTA: Se ISE riceve un'identità come username@domain, cerca nel catalogo globale della foresta una corrispondenza con l'identità UPN o con l'identità di posta "identity=matched UPN or email". 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".

---

---

3. Ricerca NetBIOS: Se ISE riceve un'identità con un prefisso di dominio NetBIOS (ad esempio, CISCO\sajedah), ISE cerca il dominio NetBIOS nelle foreste. Una volta trovato, cerca il nome SAM fornito (ad esempio sajeda).

---

---

4. Ricerca base computer: Se ISE riceve l'autenticazione di un computer con un'identità host/prefisso, cerca nella foresta un attributo servicePrincipalName corrispondente. Se nell'identità è stato specificato un suffisso di dominio completo, ad esempio host/machine.domain.com. Cisco ISE esegue la ricerca nella foresta in cui si trova 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, 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.

---

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
3.0	04-Aug-2026	Introduzione, titolo, ortografia, grammatica aggiornati, righe orizzontali inserite per separare le sezioni/leggibilità, testo alternativo aggiornato.
2.0	03-Aug-2022	Grammatica, struttura, traduzione automatica, stile, formato
1.0	06-Feb-2020	Versione iniziale