Dans le cadre d’un déploiement , la collecte de donnée cliente stipulait que les admins doivent arriver en mode privilégié après une authentification réussie .
Ici commence mon périple…

Voici un exemple de conf fonctionnel :

aaa new-model
aaa authentication login AUTHENT group tacacs+ local
aaa authorization exec AUTHORIZ group tacacs+ local if-authenticated

line console 0
login authentication AUTHENT
authorization exec AUTHORIZ

line vty 0 15
login authentication AUTHENT
authorization exec AUTHORIZ
transport input ssh

Ici dans , ma conf , le switch va interroger un serveur d’authentification via le protocole Tacacs+ ( propriétaire Cisco ) , si et seulement si ce serveur est injoignable , on utilise les comptes locaux implémenter au sein du switch.
Le problème c’est qu’en appliquant ces régles correctement , et en testant via le port console , je me suis rétrouvé à perdre plus d’une heure car j’arrivais systématiquement en mode Invité , avec un prompt ’switch>’ .
Encore une fois , le but étant d’arriver directement en mode privilégié , avec un prompt ’switch#’ ; cela évite à l’admin d’arriver en mode , nouvel utilisateur et de rentrer un nouveau password pour accéder au mode enable.

Et voila le truc :
En mode CLI ( donc en console ) , même si des paramètres d’autorisations sont configurés et correctement appliqués , le switch va bypasser la phase qui correspond à la ligne :
aaa authorization exec AUTHORIZ group tacacs+ local if-authenticated
En clair , la commande fonctionne bien comme on veut , tant qu’on accède à l’équipement via un remote accès telnet/SSH ….
En mode console , vous tomberez toujours sur le mode invité après un login réussi !

Rester bloqué sur une subtilité telle que celle ci est juste….. lamentable .
Mais sa m’aura appris quelque chose. ;)