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
server 10.1.10.153
!

Feb 20 08:29:12.043: %AAAA-4-NOSERVER: Warning: Server 10.1.10.153 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 10.1.10.153 key thesedaysimwatchingacriminalmindsseries
!

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

image

And let’s create a test user:

image

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

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

USER ATTRIBUTES

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

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:

image

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

image

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:

image

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#
ROUTER#debug aaa authorization
AAA Authorization debugging is on
ROUTER#debug tacacs
TACACS access control debugging is on
ROUTER#

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 10.1.10.153 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:

SNAGHTML90e754

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:

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

And we try to access our router:

SNAGHTML977cef

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!

Advertisements
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.
    BR
    Darko

  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… http://the-packet.blogspot.com/2013/07/cisco-device-access-authentication-asa.html

  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:

WordPress.com Logo

You are commenting using your WordPress.com 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