Il modello di autorizzazione Device Admin in ISE

Quando ISE fa da server TACACS+ per l’accesso amministrativo agli apparati di rete, la fase di authorization produce due risultati distinti e complementari:

  • Shell profile → definisce chi sei nella sessione: il privilege level con cui atterri sull’apparato e gli attributi di sessione.
  • Command set → definisce cosa puoi digitare: l’elenco dei comandi CLI consentiti o negati.

Entrambi vengono restituiti dalla Device Admin Authorization Policy in base a chi è l’amministratore (gruppo AD/interno), a quale device sta accedendo e da dove. La separazione è voluta: un amministratore junior e uno senior possono condividere lo stesso shell profile ma ricevere command set diversi, o viceversa.

Shell profile: privilege level e attributi di sessione

Nel shell profile la sezione Common Tasks espone due campi chiave:

Campo Significato
Default Privilege Livello EXEC su cui l’utente atterra a inizio sessione (0–15)
Maximum Privilege Livello massimo raggiungibile via enable
  • priv 1 = user EXEC: comandi diagnostici di base, nessuna configurazione.
  • priv 15 = privileged EXEC: accesso completo, configure terminal incluso.

Se imposti Default Privilege = 15, l’operatore entra direttamente in enable mode senza digitare la enable password. Se invece imposti Default Privilege = 1 e Maximum Privilege = 15, l’operatore parte in user EXEC ma può salire a priv 15 (in quel caso il device chiede a ISE l’autorizzazione all’enable). Nel Custom Attributes puoi spingere ulteriori coppie AV TACACS+ (es. idletime, timeout, autocmd).

Punto cruciale: il privilege level da solo non filtra i singoli comandi. Definisce la “soglia di ingresso”; il filtro fine per comando è compito dei command set.

Command set: permit/deny per gruppo di amministratori

Un command set è un elenco ordinato di regole con tre colonne: Grant (Permit / Deny / Deny Always), Command e Arguments (che accetta regex). Sopra all’elenco c’è il flag decisivo:

Permit any command that is not listed below

  • Deselezionato (default deny) → tutto ciò che non è esplicitamente permesso viene negato. Approccio whitelist, il più sicuro.
  • Selezionato (default permit) → tutto è consentito tranne ciò che neghi esplicitamente. Approccio blacklist, pericoloso.

Esempio: un command set “NOC-ReadOnly” con permit show .* e default deny consente solo comandi show, negando configure, reload, write.

Prerequisito fondamentale (spesso dimenticato): i command set funzionano solo se l’apparato invia le richieste di command authorization a ISE. Su IOS/IOS-XE serve:

aaa authorization commands 15 default group tacacs+ local

Senza questa riga, i command set non vengono mai consultati: l’apparato applica solo il privilege level dello shell profile e l’amministratore può digitare qualsiasi comando fino al suo livello.

L’abbinamento nella policy di autorizzazione

Nella riga della Device Admin Authorization Policy, il campo Results contiene uno shell profile e zero o più command set. Con più command set, ISE ne fa l’unione delle regole permit e applica la logica di negazione: Deny Always ha la precedenza assoluta e non può essere sovrascritto da un permit in un altro set.

Trappole tipiche d’esame

  • Scenario: un command set ha “Permit any command that is not listed below” selezionato con solo pochi deny. Risposta giusta: è troppo permissivo — l’amministratore può eseguire qualsiasi comando non esplicitamente negato; per un profilo restrittivo va deselezionato (default deny + whitelist esplicita).
  • Scenario: shell profile con Default Privilege 15 ma i comandi restano bloccati/non filtrati come atteso. Risposta giusta: il device non ha aaa authorization commands 15 default group tacacs+; senza command authorization abilitata i command set non vengono valutati.
  • Scenario: shell profile assegna priv 1 ma l’admin deve gestire l’apparato in configurazione. Risposta giusta: mismatch di livello — occorre Default o Maximum Privilege 15 (o adeguato), altrimenti l’utente non raggiunge il privileged EXEC e i permit configure del command set sono inutili.
  • Scenario: due command set assegnati alla stessa regola, uno con permit reload e l’altro con deny always reload. Risposta giusta: Deny Always vince sull’unione — reload è negato.
  • Scenario: l’utente deve poter fare enable ma ISE nega il salto a priv 15. Risposta giusta: verificare il Maximum Privilege dello shell profile (deve consentire il livello richiesto) e che l’enable authorization sia gestita via TACACS+.