ISE TACACS Authentication - log in before deciding if you should have access

[ken.lambert]

I'm in the process of moving away from Cisco ACS to Cisco ISE version 2.1 for TACACS control of my network devices.  I've opened up a case with TAC but the response I got seem counter intuitive and I'm hoping for either verification of this is now the Cisco way or I just need to configure my policy sets differently.

For a switch using ACS for administration, an user will SSH to the device and if they are not in the correct AD security group, that user will get a denied access response

With ISE TACACS for administration, the user will SSH to the device and because they are a member of the AD domain they will authenticate and actually logon to the device getting a prompt.  Now that same user if they are not in the correct AD security group they will not be authorized to do anything on the switch.

According to my TAC, ISE needs to identify the user before it can decide if that user is authorized to access the device.  This doesn't sit well with me because basically anybody in my company can now login to these devices.  Outside of putting ACLs on the switches that would only allow access from certain computers, what have others done to mitigate this risk?

Thank you

[ken.lambert]

Thank you Max, I will give it a shot.

[Maximilian Usinger · Accepted solution]

Hi Ken,
In case you set up your ISE with a fresh 2.1 installation, do the following:

At the "Device Admin Policy Set", leave the "Authentication" part of a rule as it is.
In the "Authorization" part, add your AD security groups as conditions (select the right box at conditions -> create new condition -> at "select Attribute": "Name of AD connection" -> ExternalGroups -> "equals" -> Choose AD group name) and the right Command Set and Shell Profile for each security group.

Now the importand part: the last rule is the default rule, which will be used if the user is not a member of any security group that was the condition of a former rule.
Here you have to make sure that the "Deny All Shell Profile" is selected, this means if this rule will be used, the user will be blocked from access.

In case you upgraded from 2.0 to 2.1, you will maybe suffering from this bug here:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva04654/?referring_site=bugquickviewredir
Then you simply do not have a "Deny All Shell Profile" as option.
I build a workaround for my system:
I created a new shell profile, which has a "logout" as auto command and 0 as max privielege level.
I assigned this shell profile to the default rules.
This may not be the best solution, but it does what it should do.

let me know if this worked, and please rate helpful answers!

Greetings,
Max

Edit: spelling mistakes

[ken.lambert]

Found that this is the bug that is causing the issue:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva04654/?referring_site=ss

Apparently the patch is coming out today/tomorrow.

[Maximilian Usinger]

Yep, that's the same bug I mentioned in my reply concerning an upgrade from 2.0.
Where do you know from that today or tomorrow a fix will be released?

[ken.lambert]

I was escalating within TAC.  After your response I got lucky I got an engineer (third times a charm) that was aware of the bug.  

The response from TAC was it was going to be release soon (today/tomorrow).  I will post when it is released.

[Maximilian Usinger]

That is really nice, thanks for the information!
I will keep an eye on Cisco's download page :)

[ken.lambert]

Just got word that the patch has been delayed until September.  Unfortunately for me I will now need to do a fresh install.  Looks like the patch caused other issues that I don't want to track down atm.  Thank you for your help.

[Maximilian Usinger]

Oh no, was a date named when the patch might be released?
Which issues did the patch cause?
As I have a productive TACACS-deployment with around 2000 devices running, I am not able to do a fresh install :D