TACACS + ISE 2.0 Deny Access

[Marvin Rhoads]

I'm looking for the "Deny Access" shell profile that we had with ACS on an ISE 2.0 deployment with Device Admin license active.

The use case is to authenticate the users with a device admin policy but not allow them to get even privilege level 0 access to the device command prompt. In ACS 5.x we use the "Deny access" shell profile as the default Authorization. I don't see an equivalent profile (or how to make one) in ISE. The "Create New Shell Profile" section doesn't provide a place to choose "Deny Access".

This guide: Configure ISE 2.0: IOS TACACS+ Authentication and Command Authorization based on AD group membership - Cisco seems to recommend using "DenyAllCommands". However that still allows the use to login and get a command prompt on the devices.

[hslai]

Yep, this is a known issue -- CSCuy46322 DefaultDeny access present in ACS is missing in ISE's T+

It will be addressed in the up-coming ISE release. For now, you should be able to create your own T+ shell profile with no attribute. Since it's your own, it's best to give it a name other than "Deny All Shell Profile", in order to avoid name collision later in the upgrade.

[Marvin Rhoads]

Thanks for the quick and thorough reply!

That's an embarrassing one to have to explain to the customer. Still - having a work around is better than not having one.

Cheers.

[hslai]

It turns out my workaround is not effective as the deny-all shell profile needs to send deny access to NADs. Please use the workaround suggested included in the bug instead.

[Marvin Rhoads · Accepted solution]

Yes - thanks for the follow up. My customer had tried and confirmed the work around you suggested still presents an unauthorized user with a command prompt on the NAD, albeit with no ability to execute any command.

It was not a show stopper though - I am recommending they wait until ISE 2.1 for the proper fix vs. jiggering the external authentication (currently a simple AD join) to use a specific LDAP OU. That opens up other complexities such as needing to configure LDAPS to do it securely, getting proper certificates on the DC for that, etc.