Ok, last time we configured our ACS server and a router to authenticate users when they try to log in via VTY line. Now we will change a little bit that scenario and make some changes in the ACS toward something that matches more a real life scenario.
We will be using the same layout from previous blog.
What we will do is this: we will disable the default access services – Default Device Admin and Default Network Access. We will do so just to show that we can create our own access services. Sure, we can use the default ones. Then we will create our own access service that will allow members of Device Admin group authenticate against local database (we are still using local database, but not for a long). When they try to escalate their privileges to level 15, each of them will use a separate enable password stored on the ACS instead of all of them using the same enable password stored locally on the router. Of course, we will make our scenario resilient to the ACS failure.
First, let’s disable the default access services – Default Device Admin and Default Network Access. Go to Access Policies, click the rule, select Disabled for a status, and hit OK. Do that for another rule and click Save Changes:
Let’s now create an Identity Group called Device Admin and two users: sasa.popravak which is member of Device Admin group, and user slavisa.popravak, which is a member of default All Groups group:
Important thing about creating users is that we need to specify two passwords: Password and Enable Password. These password can be the same, but it is more secure if they were different:
We will now create a brand new access service called DEVICE-ADMIN. This service will use internal database for authentication, and for authorization result that will be returned to an AAA client, we will create a Shell Profile called PRIVILEGE_15. This profile will allow user to jump to privilege level, given that they know their enable password. First, let’s create a Shell Profile. Under Policy Elements->Device Administration->Shell Profiles we click Create. In the opened dialog, under the General tab we give it a name, and under the Common Tasks, we select Maximum Privilege to be 15:
Now we create our access service. Under Access Policies->Access Service we click Create. In the Step-1, we give a Name, select Device Administration for the service type. We select Identity and Authorization for the Policy Structure:
We click Next for the Step-2. In this step, we only need to specify Allow PAP-ASCII for Allowed Protocols:
After we click Finish, we will be presented with the option to modify Service Selection Rules to activate service we just created. We will go for Yes:
Then under Access Policies->Access Services->Service Selection Rule we click Create button and fill in the fields as shown bellow:
We could reorder this rule and click Save Changes:
Now we need to adjust Identity and Authorization settings for this service. For Identity, we will select Internal Users:
And for Authorization, we need to create a rule with conditions we want. We want to allow only members of Device Admin group to be able to use this service. We click Customize, remove Compound Condition and add Identity Group. We remove Command Sets and click Ok:
Then we click Create and fill in the form:
We need to make sure that the Default rule denies access:
That’s all on the ACS side. Now the router. This is what we will add to the previous configuration:
aaa authentication enable default group tacacs+ enable
This will call the AAA server any time a user types enable command. If a AAA server is unavailable, we could still enter the privilege mode, if we know local enable password. So, let’s test this:
And for a user not member of the Device Admin group:
Now what if we would like to use a RADIUS protocol for this? There is a catch! With the TACACS+, every user can have a separate enable password. With the RADIUS, however, there can be only one enable password on the ACS server. For this to work, we need to modify our ACS rules, create a special user called $enab15$ (dollar sign-enab15-dollar sign) with a password of our choosing.
First, let’s revert all back to the default configuration on the ACS. The easiest way of doing so is from the CLI executing command “acs reset-config”. Be ware that this command will remove any licenses, as well as configuration. I will revert parts of configuration manually.
After that, first we will create this special user – $enab15$:
We will use the predefined access service Default Network Access. If we would like to create our own service, it would have to be of type Network Access. For Identity, we will use Internal Users. For Authorization, we will leave the defaults, which is the default rule that just assigns the Permit Access for the Authorization Profile.
On the router, we need to switch from TACACS+ to RADIUS, and define a RADIUS server:
no aaa authentication login default group tacacs+ local
no aaa authentication enable default group tacacs+ enableaaa authentication login default group radius local
aaa authentication enable default group radius enableradius-server host 192.168.168.12 key spop123
Now, we can test again our login attempt:
And to prove above points, let’s check AAA logs:
Which verifies that we authenticated with sasa.popravak, and then entered the privilege mode with $enab15$. With the TACACS+, that was not the case.
Thanks for reading!
popravak 