ISE TACACS Deny All Shell Profile Still Not Working Correctly

[paul]

There has been a fundamental issue with ISE TACACS since the start that it doesn't allow us to deny the connection during the Authz phase like ACS did.  The main issue here is any users from your identity source is allowed to log into the device.  For example if you allow AD as an identity source, ANY AD user can log into your network devices and you have to use other methods like autocommand logout or command authorization to stop them from doing anything.

The Deny All Shell Profile was supposed to fix the issue, but it only works for systems that have an exec authorization phase like routers and switches.  For systems running Nexus OS the user still gets in. 

Seems to me like the main issue is the ISE decouple the authentication phase from the authorization phase something I don't believe ACS did (but could be wrong) and something RADIUS doesn't have a concept of. 

Let me know if there is a clean way to fix this.

[hslai]

If your ISE 2.1 upgraded from ISE 2.0, then you might have hit this bug:

CSCva04654    Restore/Upgrade of ISE 2.0 to 2.1 Removes Default DenyShell Profile

We are addressing it in the upcoming patch.

If that is not the case, please give more details or open a TAC case.

[paul]

Yes we have seen this bug on our upgrades.  The deployment I am working on is a fresh 2.1 build and the Deny All Shell Profile is there.  I guess the title of my post may be misleading.  I am not saying the Deny All Shell Profile doesn't work I am saying it only works if the authentication device has an exec shell authorization phase.  Nexus OS doesn't have an exec shell authorization phase like switches and routers do, i.e there is no "aaa authorization exec default group ISE-TACACS if-authenticated" on the Nexus.  You only have the following:

US-DCPR-CS02(config)# aaa authorization ?

  commands         Authorization for all exec-mode commands

  config-commands  Authorization for config commands

Without a exec shell authorization phase the Deny All Shell Profile work around doesn't work. 

I don't remember any of this being an issue in ACS. 

[hslai]

The ISE 2.0 bug [CSCuy46322    DefaultDeny access present in ACS is missing in ISE's TACACS feature] is found with NX-OS and it should already resolve in ISE 2.1.

Which Nexus devices did you try? I only have access to N1Kv so I can try that in my lab.

[paul]

Nexus 7K and MDS 9148

Here is the MDS login from a local user not in one of the allowed MDS admin groups:

login as: testuser

User Access Verification

Using keyboard-interactive authentication.

Password:

Cisco Nexus Operating System (NX-OS) Software

<removed the TAC and license verbiage>

US-DCPR-MDS-A#

You can see the in the logs below I am clearly getting denied in the authorization phase, but I am at the # prompt of the MDS>

[hslai · Accepted solution]

I am seeing the same problem on my ISE 2.1 and N1Kv so have asked our engineering teams to investigate. One workaround I have right now is to use ISE as a RADIUS token server and define a RADIUS policy set to deny access by default unless matching specific user groups. Additionally, a NAD created for ISE itself with the same shared secret as the token server object.

Then, update the T+ policy set for NX-OS to use this loop-back RADIUS token server as the identity source, instead.

[paul]

Thanks. I have used the RADIUS callback trick for portal AD group enforcement. In this case I am doing command authorization on the MDS and Nexus switches so even though the user gets in they can’t do anything. I was bring this up as a discussion to point out that the deny during authorization is not working right on all platforms.

Thanks