So...
We are working on deploying ISE and we hit a pretty big hurdle. In ISE there is an authentication policy, and authorization policy. Apparently in ISE there is no way to restrict logins (or block access) under the authentication policy. The only restrictions are in the authorization.
what this means is that when you sync your AD forest to ISE, Lets say Joe is a generic user, and Tom is a network engineer. The only restrictions in the authorization policy is command based. What this means is that because tom is in the engineer group, he can config T and configure the network devices. Joe is a nobody and should not have access whatsoever. But joe can still log into the router. He cannot perform any commands... but he can login.
This is honestly ridiculous. How can they not restrict on the authentication policy. ACS has this functionality... but not ISE.
I DON'T WANT YOU LOGIN INTO MY ROUTERS JOE. GO HOME!!! :developers:
This is in their TACACS+ module, I take it?
I know that ACS can grant/deny access based on AD group membership. Is that not available in ISE?
Being able to log in is a pretty big deal, as once you're *able* to log in, then you can next try things to get an escalation of privileges. No login, no shot at escalation.
Version? What does TAC say?
That's ridiculous. Please keep us updated here!
I keep hearing more and more bad things about ISE, kinda scares me. I'm supposed to put something together comparing this to Microsoft and any others I find in the next couple months.
NAC in general is scary, because that's when devices that were connecting just fine since forever are going to be forced to change or be disconnected or to add their MAC address to the MAR list... or "potential security risk list" as I like to call it. People don't do NAC for fun, they do it for compliance.
Although I enjoy working with ForeScout CounterACT as opposed to Cisco ISE, there are issues in NAC that *all* vendors are going to have a tough time with, so I find myself refraining from throwing rocks at one vendor that could very easily be thrown at another.
In this case, at least it *does* TACACS+. CounterACT can't do that. If Cisco discontinues the ACS line, I don't see us going with ISE only to provide TACACS+ service. We'd either rip out our entire NAC infrastructure and go full-on with ISE, or we'd learn to live without TACACS+.
:hankhill:
Is there a reason you don't/wouldn't use the shrubbery tac_plus to get tacacs support? I never liked ACS when we used it at previous jobs. Unless you need some other features (I don't really know what all ACS does besides tacacs).
-Otanx
quick update guys,
We did work with tac, and they state that there needs a feature request put it on this. We are running 2.0.0.306.
I spoke with our local cisco pre-sales engineer, and he says they do not offer ACS anymore for free because ISE supposedly replaces the tacacs functionality of ACS. BULLCRAP!
So... tac is looking into this. I sent a request to our sales engineer to reach out to the ISE experts over in cisco land to figure this out, and make sure we aren't missing something.
Quote from: Otanx on February 05, 2016, 11:10:07 AM
Is there a reason you don't/wouldn't use the shrubbery tac_plus to get tacacs support? I never liked ACS when we used it at previous jobs. Unless you need some other features (I don't really know what all ACS does besides tacacs).
-Otanx
I can't where I am at due to licensing policies. Using a free solution was the first thing I asked when I started to at least get us by. Execs are very strict on making sure we pay for a licensed product that comes with a support contract. If it is something we need to do our jobs all we need to do is show how and ask. So we do have money budgeted for ISE or another prodcut. Other than some Linux VM's I have for network/security testing we rarely use anything else open source.
Please keep us posted. I'm going on ISE training at some stage, so will be thrown to the wolves at any point after that, if this gotcha is legit then that's one massive pothole I'm calling out well in advance.
At one of my old workplaces we ran tacplus, did the job no worries but we had an extremely bare bones setup (only 2 classes - admin and read only - no multi-tenancy or anything remotely fancy). I would question the ROI of ISE if all you really wanted is basic TACACS+ (user authentication/authorization and command logging). If tacplus scares you, then why not just use RADIUS to a commercial RADIUS server (like AD? LOL) and config archive (to syslog) feature for command logging.
The old school 'but has it got vendor support' mentality drives me nuts when there are clear, non-obscure and widely deployed open source solutions. Fine, pick the commercial solution via a clear ROI analysis (cost of time vs commercial cost) or performance/feature bake-off but too many enterprise shops just dismiss open source stuff out of hand.
Managers want to be able to hold someone accountable if they need a hotfix. Open source solutions, you're depending upon the kindness of strangers. Can't threaten to go to a competitor if they don't fix an issue. Also, if it's a vendor solution in wide circulation, it's easier to find staff that are familiar with it, reducing time spent on training.
But back to ISE and TACACS+... I want to take a look at it from a marketing/features perspective. ISE is critical to Cisco's security strategy, so adding features that the competition doesn't provide gives it an edge in the decision to buy it instead of ForeScout, Bradford, or any of the other solutions. TACACS+ is one of those. SGT is another.
Maybe there should be another thread for SGT, but I'm critical of it. It leverages AD to determine file/print access on a network level, which is a hop or two ahead of basically the same thing done on a server level. To me, it seems like a feature that isn't entirely there that solves a problem that kinda doesn't exist.
But, it illustrates the arms race going on in NAC. If a feature is added for marketing purposes, there are chances that its addition is going to be a bumpy ride for the first few versions of it. Reminds me of Microsoft's assault on Novell. It was a good while before they got networking done well enough to take Novell out of the datacenters. Not the best, but good enough.
Lynk, is there a bug ID or any official reference (doco?) you can point us to
I'll look into getting the feature request ID, but we are going to be using this for a lot more than TACACS. that was just the icing on the cake. We are working primarily on .1x wireless features, and then moving to wired... very cautiously, and very slowly
Good news is that dot1x for wireless is pretty dang easy.
Get AnyConnect on the wired Windows boxes and it'll be much better for you on the wired network. Windows native wired dot1x supplicant is hell to deal with.
quick update from our Cisco SE
Quotejust heard from the BU that they are planning on DenyAccess for the release coming this summer. It is now committed, but I know that's a little late for this initial implementation.
Thanks for update
here it is boys:
QuoteCSCuy46322 DefaultDeny access present in ACS is missing in ISE's TACACS feature.
:ckfacepalm:
How do they miss something like that?
your guess is as good as mine.
Funny but not so funny update.
You can restrict to enable mode on IOS. On nexus even if you set the permissions level to 0, they can still get into config mode.... sigh.
Oh I'm glad I'm not the only one that finds things out like this that completely throws you as to how or why it was not included initially. A real head scratcher.
:wall:
I love how the bug report says FIXED but doesn't tell you which version is fixed! link goes straight to standard download portal, not the fixed version.
Cisco must not have tested it very well to let that little mistake slip through to production. We were told not to migrate our TACACS+ functions to ISE 2.0 because of issues, but that was because we already have existing ACS infrastructure.
Perhaps you can use a temporary workaround until Cisco releases a fix. Not sure if this will work with your ISE implementation, but you could adjust the dACL applied to your users that would permit/deny connectivity to the network devices. So members of the Network Engineer group get IP connectivity to the network devices, then your device administration policies will handle authorization. Users who are not members of the Network Engineer group get a dACL that denies IP connectivity to your network devices so they never end up hitting the device administration authentication policy at all.