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.
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.
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
Current privilege level is 15
Connection closed by foreign host.
macse00372:~ jimmy$ telnet 192.168.1.6
Connected to 192.168.1.6.
Escape character is '^]'.
User Access Verification
Current privilege level is 7
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! 🙂