Network Management

OK, nothing in the forums nor KB for this.  I am setting up AirWave (the packaged VM) version 7.4.5, reading the V7.4.0 AirWave User Guide.  I have set up my server as a TACACS client, and when authenticating I see in the CS-ACS logs that I am successful.  However, the rest of the steps (AMP UG page 50, steps 4-7) look perhaps out of date for CS-ACS 5.3.

I daresay *somewhere* I need to make my userID (and others) have the 'Admin' role in AirWave, but that isn't immediately obvious.  Anyone have better steps to follow than the current manual?

Thanks.

I'm not sure it's possible in post-4.x versions of ACS.  AirWave expects ACS to return a role along with successful authentications, and in older versions of ACS, we could create custom attributes that would do that.  Like

role="AMP Administrator"

role="Monitoring of APs on the east coast"

Is there a way to do that in newer versions of ACS?  I haven't seen how to do it, but if there's a way I'd love to know how to do it.

The most common way to authenticate AirWave users today is with RADIUS.

OK, I figured it out (and I'm no CS-ACS expert by any means).  This works on CS-ACS 5.3, YMMV, etc.

In my CS-ACS Access Policies for AirWave, in the applicable Authorization 'rule' under 'Results' was specified 'Permit Access' which is the default Shell Profile.  The default Shell Profile cannot be modified.  As near as I can tell the Shell Profile 'Permit Access' the only one in use in any rule, in our CS-ACS implementation.

However we also have other Shell Profiles defined (in Policy Element | Authorization and Permissions | Device Administration | Shell Profiles).  One of the Shell Profiles is 'Network Operations' (the Shell Profile names roughly correspond to the groups who access devices managed by CS-ACS, but I cannot see anywhere where those are mapped to actual AD Groups.  There are also corresponding Network Access Authorization Profiles - exactly the same names as the Shell Profiles - but again I am not sure how one is mapped to these.  I am not sure that is needed, read on).

Back to Policy Element | Authorization and Permissions | Device Administration | Shell Profiles: Network Operations.  I looked in the "User Guide for Cisco Secure Access Control System 5.2" and searched 'custom' - Chapter 9: Managing Policy Elements on page 9-27 describes how to create a Custom Attribute.  I edited the 'Network Operations' shell profile, clicked the Custom Attributes tab, and filled in an Attribute of "role" and made it mandatory, static value, and entered a value of "Admin" (matching the Admin role in AirWave), and saved the change.

I then went back to the Access Policy for AirWave, in which the first rule is for my Network Operations group.  In the edit dialog for that rule at the bottom, I changed "Shell Profile" from 'Permit Access' to 'Network Operations' and saved the change.

Voila - AirWave can be accessed with my CS-ACS credentials!

So one can create custom attributes in CS-ACS V5.  As soon as you said "post 4.x versions" I was afraid it wouldn't, it does sound awfully RADIUS-ish.  But it can be done in V5.x too.  Since these custom attributes are probably returned to other TACACS clients, and since 'Admin' is a bit nebulous, I may go back and create an 'AMP-Admin' role in AirWave, the same as 'Admin,' and change CS-ACS to return THAT so it is more obvious what the attribute is for.

Thanks for the response!

Thanks for this post it realy helped me out.  I also found that if you don't want to give everyone Admin privliges you can set the role = Audit.  That way users can see much of the info without editing it.

I know this is an old post but just wanted to say Thanks.  This worked for me.

Although, I would like to know why I have to make is "Mandatory" for this to actually work?  I can't just put this as an "Optional" attribute in my current Shell Profile so I will just have to massage the Access Rules I have to incorporate rules for Airwave.

If I leave the option as "Mandatory" then I can't access some of my devices (ie, some Cisco switches).

Thanks again for doing the research!