Cisco IOS/ACS5.x exec authorization

In this short blog we will see how to set up a router so that users login into it authenticate against ACS 5.x AAA server. After successful authentication, user should be automatically placed into a privilege level of fifteen.

As a first step we must make sure we don’t lock ourselves out! In other words, whatever we do we must retain at least our console access. So we create a login list for a console access and apply it:

aaa authentication login CONSOLE none

line con 0
privilege level 15
login authentication CONSOLE

This way we always have a privilege access to a console. Please note that for additional security we could omit the “privilege level1 5” and have a enable secret defined. In that case, we would have unauthenticated access to a console, and yet we would not be opened for anyone plugging into a router with a console cable.

Now we turn on AAA and define a login list:

aaa new-model
aaa authentication login ACS_TAC group tacacs+ local

What we just typed was: use a TACACS+ group named “ACS_TAC” for login authentication. This group contains one or more TACACS+ servers we will define later. If none of them is responsive, use locally define user and password for a fall back method. Of course, we need to create such user:

username help password me

Very important! This fall back method will only work if no TACACS+ server is reachable! If server is reachable, this method won’t be tried, because TACACS+ server will do all the work.

Now let’s fill this ACS_TAC group with TACACS+ servers. We only have one in this demo:

aaa group server tacacs+ ACS_TAC

Feb 20 08:29:12.043: %AAAA-4-NOSERVER: Warning: Server is not defined.

We can see a warning that there is no server with this IP address defined. So, let’s define one:

tacacs-server host key thesedaysimwatchingacriminalmindsseries

It’s time to create this router as a network client on ACS server:


And let’s create a test user:


We are now ready to test if authentication actually will work before we apply it to VTY lines:

ROUTER#test aaa group ACS_TAC sasa.popravak IchlerneDeutsch new-code
Sending password
User successfully authenticated


username             “sasa.popravak”
reply-message        “password: ”

What just happened? We sent a username “sasa.popravak” and a password “IchlerneDeutsch” to AAA server. The server responded with “User successfully authenticated”. So we know our authentication works and we may apply it to VTY lines:

line vty 0 4
login authentication ACS_TAC
transport input all
line vty 5 15
login authentication ACS_TAC
transport input all

If we now do a telnet or SSH to the router we could log in with those credentials. But now we have to provide a enable secret password. Bummer! We want to skip this… The reason? We are lazy to type it in every time 🙂

First, let’s go on the ACS server and create a “Shell Profile”. Under “Policy Elements->Authorization and Permissions->Device Administration->Shell Profiles” we click “Create”. We give this shell profile a name and description:


And under the “Common Tasks” we specify a privilege level of fifteen:


We click “Submit”.

Now we must adjust a “Default Device Admin” access policy. This policy is used when ACS receives a TACACAS+ request. By default this access policy just grants access, because there is a default implicit authorization rule that says “Permit Access”. We will now create additional rule that will use previously created shell profile. Under “Access Policies->Access Services->Default Device Admin->Authorization” we click “Create”. A dialog appears:


Here we can see a powerful rule based ACS engine! We must select at least one rule, so we just pick “Identity Group” to include all groups. For the result, we assign previously created shell profile and click “OK” and than “Save Changes”.

Now we go back to the router and state that we would like to do an exec authorization:

aaa authorization exec ACS_TAC group tacacs+ local

And use this list for VTY lines:

line vty 0 4
authorization exec ACS_TAC
login authentication ACS_TAC
transport input all
line vty 5 15
authorization exec ACS_TAC
login authentication ACS_TAC
transport input all

Let’s turn on some authorization debugging and try our access:

ROUTER#debug aaa authorization
AAA Authorization debugging is on
ROUTER#debug tacacs
TACACS access control debugging is on

Feb 20 09:20:40.831: AAA/AUTHOR (0x13): Pick method list ‘ACS_TAC’
Feb 20 09:20:40.831: TPLUS: Queuing AAA Authorization request 19 for processing
Feb 20 09:20:4
ROUTER#0.831: TPLUS: processing authorization request id 19
Feb 20 09:20:40.831: TPLUS: Protocol set to None …..Skipping
Feb 20 09:20:40.831: TPLUS: Sending AV service=shell
Feb 20 09:20:40.831: TPLUS: Sending AV cmd*
Feb 20 09:20:40.831: TPLUS: Authorization request created for 19(sasa.popravak)
Feb 20 09:20:40.831: TPLUS: using previously set server from group tacacs+
Feb 20 09:20:40.831: TPLUS(00000013)/0/NB_WAIT/8A29ED7C: Started 5 sec timeout
Feb 20 09:20:40.835: TPLUS(00000013)/0/NB_WAIT: socket event 2
Feb 20 09:20:40.835: TPLUS(00000013)/0/NB_WAIT: wrote entire 64 bytes request
Feb 20 09:20:40.835: TPLUS(00000013)/0/READ: socket event 1
Feb 20 09:20:40.835: TPLUS(00000013)/0/READ: Would block while reading
Feb 20 09:20:40.843: TPLUS(00000013)/0/READ: socket event 1
Feb 20 09:20:40.843: TPLUS(00000013)/0/READ: read entire 12 header bytes (expect 18 bytes data)
Feb 20 09:20:40.843: TPLUS(00000013)/0/READ: socket event 1
Feb 20 09:20:40.843: TPLUS(00000013)/0/READ: read entire 30 bytes response
Feb 20 09:20:40.843: TPLUS(00000013)/0/8A29ED7C: Processing the reply packet
Feb 20 09:20:40.843: TPLUS: Processed AV priv-lvl=15
Feb 20 09:20:40.843: TPLUS: received authorization response for 19: PASS
Feb 20 09:20:40.843: AAA/AUTHOR/EXEC(00000013): processing AV cmd=
Feb 20 09:20:40.843: AAA/AUTHOR/EXEC(00000013): processing AV priv-lvl=15
Feb 20 09:20:40.843: AAA/AUTHOR/EXEC(00000013): Authorization successful

We can see that authorization is successful. This is obvious from a telnet/SSH session:


And that’s all!

As a final test, we could plug our ACS server out and try our fall back method. From a router console we make sure that ACS is not available:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 0 percent (0/5)

And we try to access our router:


Now we used locally created user for authentication and enable secret for authorization.

Before I sign off, I better plug my ACS back in 🙂

Thanks for reading!

This entry was posted in AAA, ACS 5.x, ACS/RADIUS/TACACS, Cisco, IOS and tagged , , , . Bookmark the permalink.

4 Responses to Cisco IOS/ACS5.x exec authorization

  1. Darko says:

    Very, very good article, i’m going to try it in my home lab. Until my ACS EVAL days doesn’t expire.
    Can I use this configuration for other Cisco devices, such as SW or ASA, and be able to authorize for privilage 15?
    Thanks in advance.

  2. Darko says:

    Meanwhile i tested using ACS on VMware and my ASA, of course I used your post as guide ;). It’s not written detailed as yours but…

  3. Emmanu71 says:

    Thanks for this post.

    I have both two groups Admin (priv 15) and Support (priv 10).
    Admin user work perfect but I am stuck on Support user who can’t run some commands configured in “Command sets”.

    Could you help please!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s