04-20-2012 03:31 PM
ArubaOS 6.0 added support for TACACS+ "session authorization". In looking through the user guide today, I realized that it never got documented, and so people may not know this exists.
We do not support per-command authorization against a TACACS server, where each time a CLI command is issued, the controller would check with TACACS to see if that user is allowed to execute the command. What we do instead is allow a TACACS+ server to return a management user role at the time of initial authentication, similar to returning a RADIUS attribute.
How it works:
First, enable session-authorization under your TACACS server definition:
aaa authentication-server tacacs "tacacs-server" host 10.1.1.1 key db145da5ec23300702e tcp-port 4949 session-authorization
Once this is enabled, the controller will send a TACACS authorization request to the server after the initial authentication exchange is done. The request will include two fields, which you'll need to configure on the TACACS server as a matching rule:
The controller expects to get a response back which grants access, and which contains the following:
where <role> consists of one of the following:
- root Super user role
- read-only Read only commands
- location-api-mgmt location-api-mgmt
- network-operations network-operations
- guest-provisioning guest-provisioning
- no-access Default role, no commands are accessible for this role
Hope that is helpful to someone!
Jon Green, ACMX, CISSP
05-04-2012 12:04 PM
So there is no way of doing this through authorization of the shell? For example, with cisco based devices we pass back a priv level of 15 that sets us into enable mode when we log into a device.
05-04-2012 12:36 PM
I don't think we use the levels. The problem is that on Aruba, there's really nothing you can do from "command mode". The "enable" is a bit silly to have, especially given there's no equivalent for the WebUI. Way back in the early days we had intended to make the non-enable command mode useful for something, but it just never happened. We went with the idea of administrator roles instead.
That's why the "enable bypass" really doesn't weaken security, and why we don't use TACACS privilege levels.
Jon Green, ACMX, CISSP
09-18-2012 08:50 PM
Did you ever use Cisco ACS as TACACS server for test ?
How to config these two matching rule on ACS ?
And other question is,if possible to force first time login user to modify password ?
12-10-2014 04:50 AM
Trying to configure the parameters in the Cisco ACS server (184.108.40.206) based on your inputs given in your post. As I have don't have much experience and exposure on Cisco ACS, Unable to make it work.
Objective is to authenticate the users against the Cisco ACS (TACACS+) to obtain the necessary roles to login in to the controller.
Customer's requirement is to permit L1 Engineer to create and provide login credentails to the Guest who are visiting their office on the Guest provisioning Page. Rest of the admin user should gain access to the controller GUI for routine functions.
Can I get some direction in configuring the ACS based on the above requirement?
Attached is the snapshot from my Cisco ACS server based on your suggestions given.