We are using AAA with CiscoSecure ACS 3.2. All the 'defaults' are configured to use the ACS server -i.e. aaa authentication login default group ACS local, aaa authorisation exec default group ACS local. We also dynamically map users from Windows AD into a group that don't have Shell (exec) access (these are for remote access and NOT access to routers). If one of these dynamically created users tried to telnet to a router they fail with an Authorisation failure (the desired result), if however the user attempts to gain access via the console he is permitted, he cannot enter enable mode but can do 'show' commands etc. Doing various debugs shows no AAA Auhtorisation is done for the console line, whereas it is for the VTY lines. Is the console port (line con 0) treated differently than the TTY lines (line tty 0 etc) where AAA authorisation is concerned? Is there any way around this behaviour or are we stuck? We are running various IOS versions on Routers and Switches (12.1(x) and 12.2(x)T and the behaviour is the same with all devices.
That is the expected behaviour that you are seeing. Console authorization is not active by default. Use the following hidden command to enable authorization for console seperately. By default console authorization is disabled.
Console authorization can now be turned on/off.
A hidden command is added to allow this. The command syntax is :
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...