Cisco CLI access using Radius and ISE

When releasing Cisco ISE as a “new ACS” questions quickly raised regarding the fact that there is no Tacacs+ support in ISE. With v1.0 of ISE Cisco said “Tacacs+ will come in a future version” but we haven´t seen it in v1.1, not in 1.1.1 and not in 1.2 either. Will it be added to v2.0? Maybe…

 

So, why is Tacacs+ so important? First of all we need to look at a comparison between Tacacs+ and Radius.  The similarities between the two protocols are many. Both are are authentication protocols with the purpose of validating user identity (authentication), giving differentiated access (authorisation) and logging access (accounting). However, there are also large differences between the protocols which can be read here.

 

Historically most AAA implementations uses Radius for end user access, remote access to networks and 802.1x while the primary purpose for Tacacs+ is for device administration. When logging into a Cisco (it must be a Cisco-device since Tacacs+ is Cisco proprietary) device Tacacs+ has additional functions that Radius lacks. The most obvious difference is the command authorization function of Tacacs+ which makes it possible for the managed Cisco-device to send each issued command  (for example ´show run´) to the authentication server (ACS) and wait for respons before allowing the command to be executed or not.

 

So, when migrating from ACS to ISE, Tacacs+ can no longer be used and there is no way to allow or disallow specific command on a Cisco device.

 

In my opinion Tacacs+ is used for device administration authentication because “we have always done it that way”. But, command authorization is rarely implemented. And in most cases when command authorization is in used, the ACS policy just saids “these users are allowed to do all commands” and “these users are not allowed to access the device at all.”.

 

So, what CAN we do with Radius based device administration authentication? This is possible:

  • We can make each user allowed exec (CLI) access or not.
  • We can give each user session a specific privilege level.
  • We can do accounting to log which user accesses each device when.
And if we configure ISE to send a specific privilege level (0-15) to the device, we can also move commands to specific privilege levels and by that give access to specific commands for specific users.
The configuration example I provide below is based on a Cisco-switch that uses Radius to authenticate exec (CLI) logins. By sending back a privilege level (in this case 7 or 15) to the device depending on which group the user belongs to, we make the users having different access.
What I do NOT do in this example is moving commands to specific privilege levels. I also do NOT authenticate the user from an external source (i.e Active Directory) but the users and groups are created locally on ISE.
The devices uses are a Cisco ISE (VM) v1.1.1 and a Cisco 2960 switch.

Configuration of the switch

Below are the configuration changes I have made to a switch in production environment. I have removed all non-relevant configuration. The goal with the configuration is to authenticate access using Radius and having a local authentication as a fallback. This means that if the ISE is non-responsive it is possible to login with the locally created user after a short timeout.

 


username jimmy password 0 MyLocalPassword

A local username/password is created for fallback.

aaa new-model

This enables aaa configuration commands in the device
aaa authentication login default none

This command is important. It states that if not configured elsewhere no login is being uses. Practically this allow us to access the device from console no matter what.

aaa authentication login VTY group radius local

A new authentication list “VTY” uses radius primarily and “local” as fallback.

aaa authorization exec default none

The same for authorization. By default we don´t do it.

aaa authorization exec VTY group radius local

A new authorization list “VTY” uses radius and local.

aaa accounting exec default start-stop group radius

For each cli login (exec) we send an radius accounting packet. “start-stop” means that we also send a note when the user logs out.


radius-server host 192.168.1.106 auth-port 1645 acct-port 1646 key cisco
radius-server source-ports 1645-1646

We define the radius server and the key to use to communicate with ISE.
!

line con 0
line vty 0 15
authorization exec VTY
login authentication VTY

Specific on the vty lines (telnet/ssh access) we apply the authentication and exec authorization lists above. Note that this does not apply to con(sole) which still uses the default lists that does “none” authentication/authorization.

Configuration of Cisco ISE

 

Below are the steps to configure Cisco ISE. The screen dumps below are from a newly installed fresh ISE config. In case of an in-production ISE please make sure that your changes does not impact existing functionality!

 

First step is to configure Radius. We define a new device, gives it a name, enter its ip address and the same radius key that is defined in the device (See above). 

 

Next step is to create a device group. The purpose is to give all device that will use this configuration a specific attribute to use in the policy created later. By doing this we make sure that is is only devices in this device group “Managed Cisco-switch” that are allowed to use the authentication policy. We create a new device group and adds our switch to the group.

 

Next step is to create a policy element called “Allowed protocols”. Exec logins in cisco-devices uses the PAP/Ascii protocol and by creating a policy only allowing this protocol we minimize the risk of our policy (not yet created) conflicting with other policies.

 

Now is the time to create the authentication policy. This is the first step in the login authentication process and the authentication policies differentiates different login sequences. This policy called “Cisco CLI-access” simply states that”if the device is in our group ‘Managed Cisco-switch’ and the radius NAS-port is ‘Virtual’ we allow only the PAP-protocol and authenticate the login by using the Internal Users database.

 

The ‘Radius:NAS-Port-Type=Virtual’ means ‘only for cli login’ and is a precaution to not interfere with other authentications like 802.1x and RAS/Dialin.

 

Now we have configured everything that has to do with the authentication process. Next step is to configure authorization.We create 2 different authorization policy results called “Shell_priv_15” and “Shell_priv_7”. And here is the secret behind all this: the policies sends either the Cisco AV-pair “shell:priv-lvl=15” or “shell:priv-lvl=7” to give different privilege level access. Also we send “Radius:Service Type=Login”.

 

Now we create an authorization policy putting it all together. The rule states that “if user is member of the CiscoCLIUsers-group we use the authorization profile Shell_priv_15 (and sends the radius attributes defined in that)” and the same for Lvl7CLIUsers members.

 

We also need to create the two different user groups and 2 users, on member of each group. Don´t forget to enter passwords for each user.

 

 

Now everything is in place and a CLI login to the switch prooves wanted functionality.

 


User Access Verification

Username: CLIuser1

Password:

sw1#sh pri
sw1#sh privilege
Current privilege level is 15
sw1#
sw1#exit
Connection closed by foreign host.
macse00372:~ jimmy$ telnet 192.168.1.6
Trying 192.168.1.6...
Connected to 192.168.1.6.
Escape character is '^]'.
User Access Verification

Username: RestrictedCLIuser1

Password:

sw1#sh priv
sw1#sh privilege
Current privilege level is 7
sw1#

 

So the user CLIuser1 gets privilege level 15 and user RestrictedCLIuser1 will only get privilege level 7.

 

Finally, how does this look like in the ISE logs? If we look into the Live Authentications log we see the that the user CLIuser1 is successfully authenticated (green line) and that the Authorization profile Shell_priv_15 was applied. The same goes for the other users login. Unfortunately not in the screen dump below, though. 🙂

 

 

Also, since we enabled radius accounting for exec on start-stop, an accounting packet is sent to ISE on every successfull login and logout of the switch CLI. This is logged and can be seen in the report “RADIUS Accounting” as seen below.

 

 

 

 

This post prooves that AAA Radius for Cisco device administration serves as a good alternative to Tacacs+. However there is one major drawback with doing what I explained above: In order to allow different Authorization profiles to access different sets of CLI commands the commands needs to be “moved” to different privilegels. In the example above, even if the RestrictedCLIUser1 gets privilege level 7, there are no command available on that level. By default there are only commands assigned to privilege level 1 (the commands available at the > prompt) and level 15 (the commands available at the # prompt). And moving commands to different privilege levels is a local configuration in each device (in comparison to Tacacs+ where we could put the ” command policy” central on the ACS”). The drawbacks with this are obvious:

 

  • Since the configuration is local it needs to be managed on each device which is messy without some kind of management tool that makes all device´s configurations consistent.
  • The commands for moving commands to privilege levels are messy and tricky to configure. This is an obvious for an upcoming post. Stay tuned! 🙂
Tagged with: , , ,
Posted in Cisco Security
4 comments on “Cisco CLI access using Radius and ISE
  1. Aaron says:

    Good article Jimmy.
    I’m having a bit of trouble, partically with the allowed protocols section. It won’t accept the settings that you have in the screenshot. I’m trying to set mine up so that i can use specific AD groups to have access to switches and routers. At the moment, it’s any AD user

    • Trinity says:

      &nMLs; &nbpp;DObNUsE CHILIMAN,     POTENTIALUL DUMNEAVOASTRA CA PRIMAR SI AL PRIMARIEI SECTORULUI 1 CA INSTITUTIE SUNT MULT MAI MARI ……NU VA PUTETI LAUDA 8 ANI DIN 12 …EVENTUALI CU ZUGRAVIREA( ANVELOPAREA) BLOCURILOR DIN SECTORUL 1. VA MULTUMESC SI CRED CA SE POT REALIZA MULT MAI MULTE IN SECT.1.

  2. LTLnetworker says:

    ‘Radius:NAS-Port-Type=Virtual’ is not suitable to identify a device admin connection. ASA puts it in the RADIUS Access-Request for Cisco VPN Client and AnyConnect connections too.

    ASA# debug radius

    Radius: Type = 61 (0x3D) NAS-Port-Type
    Radius: Length = 6 (0x06)
    Radius: Value (Hex) = 0x5

    RFC 2865:
    “Virtual” refers to a connection to the NAS via some transport protocol, instead of through a physical port.

    http://ltlnetworker.wordpress.com/2014/08/31/using-cisco-ise-as-a-generic-radius-server/

  3. ISEnewbie says:

    I made it all the way to authorization policy but now I’m stuck. How do I choose users from an external identity source?

1 Pings/Trackbacks for "Cisco CLI access using Radius and ISE"
  1. […] Another good article on this topic:Cisco CLI access using Radius and ISE […]

Leave a Reply to Aaron Cancel reply

Your email address will not be published. Required fields are marked *

*

Signuppp

[mc4wp_form id="2457"]
Website Security Test