Multiple AAA authetication groups to TACACS

Cory, The F5 configuration seems straight forward. Unfortunately is the ACS side of things i'm struggling with. I'm running 5.3 ACS, can you point me to any doc's that show me step by step out to configure the ACS side of the house for remote role. I have been searching the net but I seem to find only 4.2 docs.

The first link in my comment contains some screenshots of ACS 5.3. I don't know of any walk-through documents, but the process is involves creating a shell profile where you set the custom attribute that you defined on the remote role configuration. Then you would apply that shell profile to an ACS user group (Access Policies > Access Services > Default Device Admin > Authorization, then click on the group to modify. Towards the bottom, there'll be a field to specify a shell profile).

This has been tough for me to get configured. I have it configured appropriately in f5. However in ACS I'm having a tough time. TACACS is using an External AD group to do the authentication. The authorization policy that is correctly allowing me into the F5 is working. However when i add the F5 attribute ot the shell profile associated with the authorization policy it isn't making me an admit. I have read alot on here about the role map name matching the group name verbatim on the ACS. But the ACS does't have a group, it's just using AD.

Our ACS server also uses AD on the back end, but from the perspective of getting auth working between BIG-IP and ACS, it's not relevant. As long as the authorization policy you build correctly links the desired identity group with the appropriate network device name/group and applies the shell profile you created, then it should work. Are you seeing passed or failed log entries within ACS?

I definitely see the correct Authorization policy get used because every time I try I see the hit count of the policy increment. But its just a catch-all that matches anything and allows you access as long as you are parent of the external AD group "net" . We don't specify a specific identity group.

You may not need to reference any identity groups. Your authorization policy can just reference your BIG-IP hostnames (compound condition) and you should be able to apply the shell profile based on that.

I'm sorry, I feel really dumb cause I feel as if I should picking this up. The only thing defined in my authorization policy is the policy name under the column name. that the external groups under AD1:ExternalGroups which has the "contain any (companyname/user/net). When I click on that policy I then have my Shell profile "NET_ACCESS" that has my costume attributes. I dont konw where I would put the BIGIP hostnames

The more I think about this, identity groups are going to be needed. The remote role name is going to need an identity group name to match against. You may need to create at least one identity group to get this to work.

You conculsion matches up with many others online how have run into this issue. name of the remote role map must match the identity group, how ever it seem that in ACS 5.4 you no longer need identity group. http://www.cisco.com/c/en/us/td/docs/net_mgmt/cisco_secure_access_control_system/5-4/migration/guide/migration_guide/Migration_Configure.htmlwp1053328 From what I have read on that site I would only use the identity group. If i'm read this cisco doc correctly I would need to add usesr to the identity group which in my perspective defeats the external group from AD.

You may be able to create just one identity group and specify all users, but then everyone would have access to your BIG-IP appliances. You're the first I've heard of using ACS 5.4+. We're going to be testing out ACS 5.5 in the coming weeks. Maybe I'll get a chance to test this out myself in the near future. Would authenticating directly to AD from your BIG-IP be an option?