ACS 4.2 for authenticating DCNM

[ATOS_GONC]

Hi,

we are using ACS 4.2 for granting access to a large number of network-devices, mostly Cisco, but also Nortel, Juniper, etc... . All working fine.

But now we are installing/testing Cisco Nexus-devices, and we can't get authentication/authorization working for the DCNM-application through ACS.

Short version:

After adding " cisco-av-pair=shell:roles*"network-admin" ", we get authenticated in DCNM correctly, and also most Core Cisco-devices, but many of the access Cisco-switches deny us access. As I understand the "*" part in the av-pair means "optional", I'm presuming this is due to an IOS-bug in those access-switches.

As we have many of those devices out there, and don't want to have to upgrade them all just for DCNM-access... Is there any other way to make this work? For example: sending the av-pair only when request are coming from an specific IP, or such?

I'm new to ACS, but have been browsing through manuals for a few hours, without much luck

BTW: shell-access to the Nexus-boxes works fine with the av-pair implemented.

Thanks for any help you can provide!

Regards,

Karl Van Hoyweghen.

[Tarik Admani]

Are you using radius to access these boxes? I can tell by your av-pair that you are most likey using radius.

If so then you can create a network access profile (should be one of the options close to the bottom), there you can create a network access profile based on the nas-ip-address for the nexus devices. From there you can choose the authorization policy from there.

Here is a guide on how to configure network access profiles.

http://www.cisco.com/en/US/partner/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2/user/guide/NAPs.html#wp1077155

Basically you want to use the radius attribute profile for the group once ACS put them into the correct group.

Also on your global network access profile configuration make sure that you grant access when there is no match.

This only works for radius, tacacs doesnt use network access profiles and I dont see a way around this.

Thanks,

Tarik Admani

[ATOS_GONC]

Hi,

>> Are you using radius to access these boxes?

Sorry for not mentioning it, but we are using Tacacs+ for authenticating Cisco-boxes.

>> This only works for radius, tacacs doesnt use network access profiles and I dont see a way around this.

Damn, and we really need the centralized users-db for the Nexus-rollout. Looks like I'm gonna have to scan the access-switches, and find out what the IOS-bug is, and start upgrading

Thanks for the information anyway!

[camejia]

Hello Jos,

As you are using TACACS+ you might have configured the "shell:roles*network-admin" under the Shell (EXEC) custom attributes on the ACS 4.x Group/User Setup. As the Nexus devices are working as expected you have confirmed that you are using the appropriate attribute format.

As per the IOS failing authorization when sending the Nexus attribute as well you are pretty much hitting the following bug if using TACACS+:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsl47365

You have two viable workarounds:

1) Upgrade all the affected IOS devices to a fixed version.

2) Add the following command to the affected IOS devices configuration:

tacacs-server attribute allow unknown

The above command will allow the IOS itself to ignore unknown attributes instead of trying to parse/decode them causing the authorization failure.

NOTE: In order to access the above listed bug a Cisco CCOiD is required.

Hope this helps.

Regards.

[ATOS_GONC]

Hi Carlos,

thank you very much for this.

I'm not going to test that now (don't want to mess-up new years eve ), but if this works, it would be a nice workaround.

I'll test the coming days...

Thanks again!

Regards,

Karl.