ANM shell (CLI) tacacs+ ACS 5.2?

[palton]

Hi

I Have setup ACE with RBAC via CLI as well as via ANM. It's integrated with Microsft AD. Everything works now except one single thing.

I need the ANM operating (shell access to ANM) system to do AAA via tacacs+ to ACS 5.2 and get it working. Tacacs requests are retrieved in ACS but I'm not sure how shell profile is supposed to handle the ANM cli, it doesnt work as any regular IOS box, as far as I know. I tried to use a shell profile working for IOS, providing priv 15. Didn't work. The box only got read and write priv. ANM cli got two different roles defined, Admin (full access) and operator (user, view only).  Those roles can be seen when doing show users via cli. I guess thats whats needed to be sent as attributes.

The application/GUI works great to provide different roles via ACS sending correct attributes. I wonder what is supposed to be sent from the ACS and how it should look like for ACS to provide info to the ANM cli with admin and operator role?

[Tarik Admani]

Hi,

It looks like you can use the similar format of creating the av-pair that you did for the ACE, here is the example of the av pair that you need send back:

ANM=Role1 Domain1 Domain2 Domain6

Here is the guide that will help piece the rest of this together, i would think creating a seperate shell profile along with a seperate authorization policy for the anm devices in order to trigger this response.

Even though this is for acs 4.2 building the av pair is the same.

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/application_networking_manager/4.2/user/guide/UG_admin.html#wp1547054

Thanks,

Tarik Admani

[palton]

thx for answering, but it wasn't what I'm wondering.I might not described it well enough.

I'm not talking about the ANM application now, I'm talking about the appliance operating system (where the ANM runs upon). The ANM goes on top of the OS in the virtual appliance I use. The ANM and Applicance shell is tww different AAA clients. They have nothing to do with each other, more than they bot will use the same ACS. They will still have same src ip and use tacacs, from an ACS point of view. multiple attributes will be needed for providing but ANM application and appliance

When logging into appliance shell (via CLI), there are two roles, admin (read/write) and operator (read only). ANM application got a lot of different roles predefined via GUI. This is what I'm trying to explain. Different AAA clients in the same appliance box.

In the shell you can configure local users (local database) that are mapped to one of the two roles (admin or operator). Then there is the possibility to use a tacacs server for AAA. I need to find out how this mapping is done via attributes ( I guess its by using attributes and not providng a shell with priv 15?) from ACS 5.2. I tried the shell profile for a IOS box, and also tried to send just the role as Attribute: Shell: , Mandatory and Value: Admin

As there is nothing more in the shell than that to provide, there is no organization, context, domains etc there..

I don't find any documentation regarding this..

[Tarik Admani]

I understand what you are saying, one thing that I can suggest is to take the logs of both authentication requests: cli and web. There has to be a unique av pair that is sent in the authentication request that we can use to build our policy around.

We can run a pcap if that is something that is simple to setup on your network...if not, please follow these steps to get the right debugs turned on. Please ssh into the ACS and follow these commmands:

acs-config (login with your web credentials after about 45 seconds of waiting)

debug-log runtime level debug

exit

exit

To turn off the debugs, follow the same steps above, using "debug-log runtime level warn".

Reproduce the issue (both with cli and www) and note the timestamps seen in the monitoring tab.

Download a support bundle and make sure it is unencrypted and only the "include debug-logs" is checked.

Once that is complete you can open the acsRuntime.log file that matches the time the events took place.

There should see the tacacs attributes that are being sent in the authentication request, or you can send those to me or open a TAC case to get help with building the appropriate policy.

Do you have the attributes you need to get the web application authorized?

Thanks,

Tarik admani

Message was edited by: Tarik Admani