ISE 2.1 Device Admin Authentication Policy (Tacacs)

[Martin Jelinek]

Hi all,

I'm working on migration of ACS (tacacs) to ISE 2.1 (latest release with available patches). As opportunity doing a lot of cleanups therefore ACS Migration utility is not an option I'm using. Configuration is being done from scratch.

What I struggle with is actual fact to restrict access to Network devices (switches, routers, firewalls, wireless bridges, access-points,...) to only certain users based on AD group membership.

I have no troubles with Authorization policies where everything works as expected and no issue in there.

What I do struggle with is fact that AUTHENTICATION policy is really useless and not granular.

- with current setup it looks (confirmed) that all users from all groups we have discovered from Active Directory can actually login to network devices with success because authentication policy cannot be restricted to specific AD group. Of course once such user wants to do something then Authorization is in place and basically he cannot do anything.

How I can restrict authentication to prevent ALL users from successful authentication (Device Admin == Tacacs part)??

Is this even possible?

I tried to configure Authentication Compound Condition to list ALL AD groups with "OR" statement to make sure only valid AD groups for Tacacs can login, however testing shows that this is NOT being accepted and only Default option is performed by policy for a user. Such compound condition I used in Authentication policy.

Is this a bug/feature of ISE2.1 that Authentication cannot be used in this way?

Or how you guys are using authentication policy under Device Admin (Tacacs) part? Maybe there is a different way I have not considered to use, maybe just need to be kicked to change my mind and do it in a different way.

So far looks stupid that anyone can basically authentication because ISE is used as well as Radius server to authentication users for wireless connection and therefore AD group with all users is discovered to ISE therefore all can authenticate successfully. :-/

Am I missing anything?

Thanks for any hints!!!

[Rahul Govindan]

You are correct that there is no way to create an Authentication alone policy on ISE based on AD group membership.You would still have to use Authorization policy to drop the users that don't match existing policy. This was not possible in ISE 2.0 and was fixed in 2.1.

https://quickview.cloudapps.cisco.com/quickview/bug/CSCuy46322

Create a default policy with action as "Deny all Shell profile" and this should drop the existing session if it does not match any other prior conditions.

[Martin Jelinek]

Hi Rahul,

Yes, I'm aware of this addition in ISE 2.1 with "Deny All Shell Profile" and using it. However this won't prevent user from successful login to the network devices (Switches, Firewalls, NX-OS,...). Even with this they are still able to login, they can't do anything (no commands due to authorization failure).

Therefore ISE2.1 doesn't provide a way how to prevent users to even login (authenticate) via Tacacs+ to our network devices.

I though maybe only option might be to use different Joint for AD connector, however not an option in our structure we have in place for Radius used on ISE. And I cannot create new Joint with different name but for same domain to use it.

Any other possibility to achieve it or will need to wait if Cisco add some more things into Tacacs integration in ISE?

Thanks for any hints ;-)

Martin

[Rahul Govindan]

You may be right. This may be a difference in how NX-OS  and ASA OS vs IOS works.

One option i can think of is proxying the TACACS authentication to the ISE again as a Radius request. You would have to configure the ISE as a Radius Token server and also as a Network device. This way the ISE receives the TACACS Authc request, forwards it as a Radius request back to itself and then falls through the Radius Authc and Authz policy - where you can define a AD group based authorization check. Haven't tried this for this purpose but something worth looking into.

[Martin Jelinek]

Thanks, nevertheless this will complicate all policies unnecessarily. Will try to evaluate it again options we have.

@Ray - thanks for notifying me with ISE 2.2, didn't notice it is already out there.

Will see, I believe we can somehow live with current behavior even though I'm not happy about it. Since Cisco spent years with ACS can't believe there is a problem to implement similar logic into Authentication policy with AD group membership as it is for Authorization policies. Maybe it is planned for future releases, can't believe this is not something desired by other companies using ISE as a replacement for ACS.

Thanks for replies.

[Raymond Zwarts]

When I get anything useful back from TAC I will comment here.

[Rahul Govindan]

Stay away from ISE 2.2 for now if you are running 2.1. There are a major upgrade issues that could mess up the system.

Also, looking at this a little more, I found a thread on Cisco communities that had the same workaround as I had mentioned.

https://communities.cisco.com/thread/70638?start=0&tstart=0

From that discussion, looks like the engineering teams are investigating this issue to bring feature parity between ACS and ISE.

[Martin Jelinek]

Thanks Rahul, Ray

Well I still do believe there are more companies using different platforms from Cisco like standard IOS based devices and as well NX-OS platforms of WLC. Where there is different approach in terms of authorization.

Even ISE allows you to choose this in Tacacs Profiles (Common Task Types) to match design of WLC or NX-OS.

Cisco should improve approach how Device Admin service of ISE actually operates. It can't be so problematic to improve authentication part.

I will try to check that related post, which is 6 months old, therefore not sure if someone still working on this from Cisco developers... :-/

Martin

[Raymond Zwarts]

As I am having the exact same issue (not AD but LDAP external users) and migrated to ISE because ACS is not the way forward in Cisco's marketing strategy I added this thread into an already existing TAC case with all sorts of mishaps when trying to use ISE (2.2.0) as a replacement for ACS.

[Martin Jelinek]

Seems that this issue I noted above had been fixed in 2.2 as far as I've tested in the LAB. Problem was that due to one bug CSCvc15000 ISE was sending wrong reponse for authentication (ACCEPT) instead of REJECT this seems to be working fine in 2.2 release as I've tested so far.

Planning upgrade in our production to use this version.

Martin