Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.
During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.
We apologize for the inconvenience while we perform important updates to the Community.
I have a few questions regarding TACACS+ and ACS server configs, and I'm hoping someone can offer me some guidance...
Below is a TACACS config on a router in a client's network:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable
aaa authorization exec default group tacacs+ if-authenticated none
A few things...
1.) I dont see any aaa accounting commands, so I am wondering if accounting is not being leveraged, or if there is another way of providing command accounting without explicitly configuring it on the device.
2.) I know that to log onto the device, they use an RSA Token. Correct me if Im wrong, but enabling RSA ID tokens for authentication through ACS is done at the ACS server itself. In other words, the RSA funtionality will not be reflected in the device's aaa configs, but instead in the application's configuration...correct?
Lastly, I see the following globally enabled configs on the router:
privilege exec level 0 dir
privilege exec level 0 write terminal
privilege exec level 0 write
privilege exec level 0 traceroute ip
privilege exec level 0 traceroute
privilege exec level 0 ping ip
privilege exec level 0 ping
privilege exec level 0 terminal monitor
privilege exec level 0 terminal
privilege exec level 0 show crypto sockets
privilege exec level 0 show crypto isakmp profile
privilege exec level 0 show crypto isakmp key
privilege exec level 0 show crypto isakmp policy
privilege exec level 0 show crypto isakmp sa
privilege exec level 0 show crypto isakmp
privilege exec level 0 show crypto ipsec security-association-lifetime
privilege exec level 0 show crypto ipsec security-association
I'm not sure how this figures into the aaa config. Why would these authorization commands be configured locally on the router when aaa authorization is already being leveraged centrally on the ACS server (aaa authorization commands in the config)?
Can anyone provide some good insight into this?
Thank you very much in advance
1) If there are no aaa accounting commands then they are not using the accounting component of ACS. Traditionally that meant that they were not maintaining any records of command usage. In 12.3T a new capability was introduced to create a log of config changes. This link has information about that feature:
We do not have enough information to know whether they are using this feature or not.
2)You are correct that enabling RSA tokens is done on the ACS and there is not anything about it in the router config.
Lastly) I would not say that commands to set privilege level were authorization commands. And I would note that the only authorization command in what you posted is the authorization in which the router asks ACS for authorization to start an EXEC process for the user who is logging in. There is no command authorization in what you posted.
And why they would want those commands to be available at privilege level 0 is another good question.
Thanks again for your expertise.
With regard to the last point, what is the purpose of those privilege exec commands? I always thought of them as local command authorization in the absence of a centralized rights and privileges authority, ie aaa. My interpretation of those commands is that they offer an administrator the right to enter the commands listed if they meet authentication requirements for that particular privilege exec level.
enable password level 5 PASS5
So, if an administator who logs onto the device authenticates successfully to that privilege level, he/she will be allowed authorization to enter the below commands.
privilege exec level 5 dir
privilege exec level 5 write terminal
privilege exec level 5 write
privilege exec level 5 traceroute ip
privilege exec level 5 traceroute
privilege exec level 5 ping ip
privilege exec level 5 ping
privilege exec level 5 terminal monitor
privilege exec level 5 terminal
privilege exec level 5 show crypto sockets
privilege exec level 5 show crypto isakmp profile
privilege exec level 5 show crypto isakmp key
privilege exec level 5 show crypto isakmp policy
privilege exec level 5 show crypto isakmp sa
privilege exec level 5 show crypto isakmp
privilege exec level 5 show crypto ipsec security-association-lifetime
privilege exec level 5 show crypto ipsec security-association
And, fo course, you would use this methodology in the absence of a centralized mechanism, like aaa.
Where am I going wrong?
"And why they would want those commands to be available at privilege level 0 is another good question"
Because a lot of companies outsource operations
to another companies but their engineering still
wants to know what going on. That's exactly
what we are doing here where I work.
"You are correct that enabling RSA tokens is done on the ACS and there is not anything about it in the router config."
you need to install RSA Agents and put the
sdconfl.rec file in the %windows\system32
directory in order to do this. Very simple
thing to do.
"Because a lot of companies outsource operations
to another companies but their engineering still
wants to know what going on. That's exactly
what we are doing here where I work."
Samir, that is exactly whats going on here, too. I wonder if we work in the same place. LOL
So, are you saying that those privilege exec commands are for those people who do not have accounts on the ACS server? If you read my second question/post above to Rick, you will see where my confusion is. In short, I thought these privilege exec commands are used in the event that aaa, a centralized controlling authority, is not being used...
It is not the case that the privilege commands are for people who do not have accounts on the ACS. The way the router is configured anyone must authenticate through ACS to start an exec session on the router. So to enter (or execute) any commands a person must go through ACS. What the commands do is to alter the privilege level required to execute them. Most of these commands are reserved to privilege 15 by default. This configuration makes those commands available to anyone who is logged in on the router.
There may be another reason too for configuring the local privileges.
In the ACS, if you need to control command authorization to a set of users, then you need to use shell command authorizations sets but the privilege level needs to be set at 15.
If it is set to anything less than 15, it looks for the privilige commands condifured locally on that device
so it is quite possible that the users might not have been assigned a privilege level of 15 and hence these commandsare configured locally
OK, I think I got it now...
So, when I configured TACACS a year or so ago, I remember that I created an exec shell for command authorizations for each group of people. I would create the group, place the members in that group, and then bind that group to a set of authorization privileges defined in the exec shell.
So, what I was wondering is why the TACACS administrators couldn't just do the same thing with the engineering department. Namely, create a group, place engineers in that roup, and bind the group to an exec shell that offers limited access, instead of having to resort to changing the privilege level and configuring locally.
After Narayan's post, I think I got it, though: when creating an exec shell, you MUST assign a privilege level of 15. So, to allow for users to execute specific privilege 15 commands, but still keep them confined to a lower privilege (say, privilege 0), you must configure the privilege level as 0 locally on the router and specify the commands that the limited user will have access to.
Did I get that right?
If so, I have one question? Why would Cisco create that limitation of requiring privilege 15 in the exec shell? Seems a little counter-productive...
Victor you got that perfectly right :-)
By default, the Cisco IOS software command-line interface (CLI) has two levels of access to commands: user EXEC mode (level 1) and privileged EXEC mode (level 15). There are no specific commands defined for other privilege levels. you may want to assign sh interface to priv1 while i may think of assigning it to priv3. So the ACS on its own would not be able to make the authorization decision.
So its better to use priv15 providing full access which can then be restricted to specific commands using the shell sets
"So its better to use priv15 providing full access which can then be restricted to specific commands using the shell sets"
OK, so then that goes back to my approach: Configure the exec shell with privilege 15, BUT specifically define the commands that users who use that shell are authorized to have access to.
If they chose this appraoch, then configuring the commands locally on the router would not have been necessary, correct?
So, there are 2 approaches then...yes?
If you are using command authorization then privilage doesn't matter.
Best way to set it up is to give all user priv lvl 15 and then define what all commands user can execute.
Note : Having priv 15 does not mean that user will able to issue all commands.
We will set up command authorization on acs to have control on users.
This is how your config should look,
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ if-authenticated
aaa authorization commands 1 default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa authorization config-commands
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
Check out this link