TACACS+ e device administration policy

Quando devi gestire l’accesso amministrativo agli apparati di rete (router, switch IOS/IOS-XE, firewall), la scelta del protocollo AAA non è indifferente. TACACS+ e RADIUS risolvono entrambi Authentication, Authorization e Accounting, ma con filosofie profondamente diverse. In un contesto di device administration, TACACS+ è quasi sempre la risposta corretta, e questa unità spiega perché e come implementarlo in Cisco ISE.

TACACS+ vs RADIUS: le differenze che contano

La distinzione fondamentale è che TACACS+ separa completamente le tre funzioni AAA, mentre RADIUS fonde Authentication e Authorization in un’unica transazione. Questa separazione è ciò che abilita l’autorizzazione per singolo comando (per-command authorization): ogni comando digitato dall’amministratore può essere inviato all’ISE per una verifica in tempo reale prima di essere eseguito.

Due punti sono ricorrenti all’esame. Primo: TACACS+ cifra l’intero corpo del pacchetto, non solo la password, quindi username, attributi e comandi viaggiano protetti; RADIUS lascia in chiaro tutto tranne la password. Secondo: il trasporto TCP di TACACS+ garantisce affidabilità della sessione, adatta al dialogo interattivo comando-per-comando.

Abilitare il Device Admin Service in ISE

Il servizio TACACS+ non è attivo di default. Servono due passi:

1. Licenza Device Administration installata (è una licenza dedicata, distinta dalle Base/Plus/Apex o dalle Tier attuali).
2. Abilitare il servizio sul nodo PSN: Administration > System > Deployment > [nodo] > Policy Service, spuntare Enable Device Admin Service.

Senza questo flag, il PSN non risponde sulla porta TCP 49 e ogni tentativo di login amministrativo fallisce, spesso in modo silenzioso lato device.

Struttura dei Device Admin Policy Set

La configurazione delle policy vive nel Work Center dedicato: Work Centers > Device Administration > Device Admin Policy Sets. La struttura ricalca quella dei policy set RADIUS ma con oggetti specifici:

• Authentication Policy: valida l’identità contro un identity store (Internal Users, Active Directory, LDAP).
• Authorization Policy: assegna il risultato, composto da:
  • TACACS+ Profile (Shell Profile): definisce il privilege level (default e maximum), l’auto-command, timeout. Es. privilege 15 per full admin, 1 per read-only.
  • Command Set: elenco di comandi in permit/deny con logica di default (grant/deny sui non elencati). È qui che si costruisce l’autorizzazione granulare per-command.

Un tipico risultato di autorizzazione combina uno Shell Profile (che fissa il privilege level all’ingresso) e uno o più Command Set (che filtrano cosa l’admin può effettivamente eseguire).

Configurazione lato device gestito

L’errore più comune non è in ISE ma sul device: dimenticare la configurazione AAA. Il device deve essere censito come Network Device in ISE (con la shared secret corretta) e configurato lato IOS/IOS-XE:

aaa new-model
tacacs server ISE-PSN
 address ipv4 10.1.1.10
 key <shared-secret>
aaa group server tacacs+ ISE-GRP
 server name ISE-PSN
aaa authentication login default group ISE-GRP local
aaa authorization exec default group ISE-GRP local
aaa authorization commands 15 default group ISE-GRP local
aaa accounting commands 15 default start-stop group ISE-GRP

Le righe aaa authorization commands e aaa accounting commands sono ciò che attiva realmente il per-command authorization e l’accounting granulare. Il fallback local è una best practice per non restare tagliati fuori se l’ISE è irraggiungibile.

Trappole tipiche d’esame

• Scenario: serve loggare e autorizzare ogni singolo comando eseguito dagli operatori. → La risposta è TACACS+, non RADIUS: solo TACACS+ offre per-command authorization e accounting granulare grazie alla separazione AAA.
• Scenario: gli admin si autenticano ma il login TACACS+ fallisce con “connection refused” verso ISE. → Verificare che Enable Device Admin Service sia attivo sul PSN e che la licenza Device Administration sia installata: senza, la porta TCP 49 non risponde.
• Scenario: l’admin fa login ma ogni comando dà “Command authorization failed”. → Manca il Command Set appropriato nell’authorization policy, oppure il device ha aaa authorization commands senza fallback e ISE nega i comandi non elencati.
• Scenario: gli utenti si autenticano ma entrano sempre con privilege level 1. → Lo Shell Profile non imposta il privilege level corretto (max privilege 15), oppure non è associato al risultato di autorizzazione.
• Scenario: policy configurate perfettamente in ISE ma il device non applica nulla. → Manca la configurazione aaa sul device gestito (in particolare aaa authorization/accounting commands) o il Network Device ha una shared secret errata.