Cisco ISE raramente vive isolata: le identità degli utenti stanno quasi sempre in un directory aziendale. Un identity store è la sorgente contro cui ISE valida le credenziali (autenticazione) e da cui recupera gruppi e attributi (per l’autorizzazione). Saper scegliere lo store giusto e concatenare più store in una identity source sequence è competenza centrale del blueprint SISE.
Join ad Active Directory
Il join ad Active Directory (AD) è il caso più frequente. ISE si unisce a un AD join point, che rappresenta una foresta; all’interno si definiscono uno o più scope per raggruppare domini e semplificare le authentication policy multi-dominio. Durante il join ISE crea un machine account nel dominio e stabilisce un canale sicuro (Kerberos/LDAP over SSL) verso i domain controller.
Dopo il join, in ISE si recuperano esplicitamente i gruppi e gli attributi che si vogliono usare nelle policy: i gruppi AD non compaiono automaticamente nelle authorization rule, vanno prima importati nella lista dei “Groups” del join point. Lo stesso vale per gli attributi utente (es. department, title), utili come condizioni di autorizzazione granulari.
AD supporta autenticazione con password (PAP, MS-CHAPv2, EAP-MSCHAPv2, PEAP) e, tramite lo stesso join point, la validazione di certificati e il lookup del soggetto nel directory.
Alternative: LDAP, internal store e certificate profile
| Store | Autenticazione supportata | Uso tipico |
|---|---|---|
| Active Directory | Password + Kerberos, group/attribute retrieval | Utenti di dominio |
| LDAP | Bind (password) o lookup, no MS-CHAP | Directory non-AD (OpenLDAP), lookup certificati |
| Internal Users | Password | Guest, account locali, admin |
| Internal Endpoints | MAB (MAC address) | Dispositivi senza supplicant |
| Certificate Authentication Profile (CAP) | Nessuna password: si fida del certificato | EAP-TLS |
LDAP è la scelta per directory non-AD: si configura il bind (anonimo o con service account), la subtree di ricerca e gli attributi di gruppo. A differenza di AD, LDAP non gestisce MS-CHAP, quindi con protocolli basati su hash challenge (es. PEAP-MSCHAPv2) serve AD o l’internal store.
Il Certificate Authentication Profile è particolare: in EAP-TLS la “credenziale” è il certificato client, già validato per catena e revoca. Il CAP definisce quale campo del certificato (es. Subject - Common Name o SAN) usare come principal username, e opzionalmente attiva la Binary Certificate Comparison confrontando il certificato presentato con quello archiviato in AD/LDAP.
Identity source sequence
Una identity source sequence è una lista ordinata di store. ISE prova il primo; se l’utente non esiste, passa al successivo, fino a trovare una corrispondenza o esaurire la lista. Esempio: prima AD, poi LDAP, poi Internal Users. Serve per ambienti eterogenei dove le identità sono distribuite.
Punto d’esame decisivo: il comportamento su “user not found”. Nelle opzioni avanzate della sequence si sceglie tra:
- Do not access other stores in the sequence and set the “AuthenticationStatus” to ProcessError — interrompe.
- Treat as if the user was not found and proceed to the next store — continua lungo la sequenza.
Quest’ultima è quella che rende funzionante il fallback tra più directory.
Come si combinano authentication e authorization
L’authentication policy specifica quale identity source (o sequence) validare le credenziali. L’authorization policy usa poi gruppi e attributi recuperati per assegnare il risultato (VLAN, dACL, SGT). Sono due fasi distinte: prima chi sei (credenziale), poi cosa puoi fare (gruppi/attributi).
Trappole tipiche d’esame
- Join ad AD fallisce con errore di orario o “clock skew” → il problema è il time sync: Kerberos tollera al massimo circa 5 minuti di scarto tra ISE e i domain controller. Allineare NTP su ISE e AD prima di rifare il join.
- Join fallisce o i DC non vengono trovati anche se il ping funziona → è DNS: ISE deve risolvere i record SRV del dominio (
_ldap._tcp,_kerberos._tcp) e le PTR inverse. Configurare i DNS interni AD, non un resolver pubblico. - Un gruppo AD esiste ma non è selezionabile in una authorization rule → il gruppo non è stato recuperato nel join point: importarlo esplicitamente nella lista Groups. I gruppi servono all’autorizzazione, non a validare la password (autenticazione) — non confondere le due cose.
- PEAP-MSCHAPv2 fallisce contro un server LDAP → LDAP non supporta MS-CHAP; la credenziale hash non può essere validata. Usare AD o Internal Users per questi protocolli.
- In una sequence con AD+LDAP l’utente presente solo in LDAP viene rifiutato → l’opzione su user-not-found è impostata su ProcessError: cambiarla in “proceed to the next store” per abilitare il fallback.