802.1X Switchport - Server Dead Action for Low Impact Mode ACL

[Mark DeLong]

Hello,

I have configured some switches for Low Impact mode as such below:

interface FastEthernetX/Y

switchport access vlan 200

switchport mode access

switchport voice vlan 100

ip access-group ACL-LOW-IMPACT-MODE in

authentication event fail action next-method

authentication event server dead action authorize

authentication event server dead action authorize voice

authentication event server alive action reinitialize

authentication host-mode multi-auth

authentication open

authentication order dot1x mab

authentication priority dot1x mab

authentication port-control auto

authentication violation restrict

dot1x pae authenticator

dot1x timeout tx-period 10

end

During an ISE server down test, I can see that port does go to an authorized state on the next authentication attempt. My problem is that when this happens I would expect that the "ACL-LOW-IMPACT-MODE" ACL will still be in effect. This ACL is meant to give minimal access for troubleshooting the computer during a failed authentication and will not provide enough access for users to do their jobs in the case that they have lost access to the ISE servers. As the ISE is down the switch will not receive the DACL that replaces this low impact mode ACL so I'm not sure what to do. Is there a way to remove this ACL or force another ACL to be used in the case of a dead server event? I did not see any other "authentication event server dead" actions that had to do with ACLs.

Thanks!

Mark

[Alex Martin · Accepted solution]

Mark,

You need to utilize the event manager macro below in order to manipulate your default ACL on the port and put a permit statement at the very top. Once the log files show the server is back up this will remove that permit from the same ACL. Depending on your deployment you may need to look at a different log entry to ensure all radius servers are down before taking action, but the concert is the same.

event manager applet default-acl-fallback

event syslog pattern "%RADIUS-4-RADIUS_DEAD" maxrun 5

action 1.0 cli command "enable"

action 1.1 cli command "conf t" pattern "CNTL/Z."

action 2.0 cli command "ip access-list extended ACL-LOW-IMPACT-MODE"

action 3.0 cli command "1 permit ip any any"

action 4.0 cli command "end"

event manager applet default-acl-recovery

event syslog pattern "%RADIUS-4-RADIUS_ALIVE" maxrun 5

action 1.0 cli command "enable"

action 1.1 cli command "conf t" pattern "CNTL/Z."

action 2.0 cli command "ip access-list extended ACL-LOW-IMPACT-MODE"

action 3.0 cli command "no 1 permit ip any any"

action 4.0 cli command "end"

Hope that helps.

Alex

[Mark DeLong]

Alex,

Thanks for the suggestion! But I'm gonna go with an EEM script as a last resort. I'm hoping someone here in the security space knows of a solution that Cisco has already coded in and it just requires a command or an understanding of authentication feature set that I don't have. The concept of Low Impact mode on 802.1X ports is not very new nor is the "dead action authorize" behavior so I would assume Cisco has thought of something here.

Thanks for your suggestion though!

Mark

[Mark DeLong]

Alex,

With the info grgibbs gave below its clear your answer is correct. Also, I like your syslog approach better than the route tracking provided in the Cisco live doc chyps provided. It's not perfect as it doesn't track both syslog servers though that could be improved on with a couple of tracking objects and another script to mark that objects down for each individual server. I don't think I would bother going that hardcore on it though.

Thx for your info and your answer!

Mark

[Craig Hyps]

The Live session provides examples of both tracking and syslog options.  I found the syslog option a bit troublesome in practice and so also offered option to track ALLDEADSERVER but even that did not seem as full proof as tracking reachability.  The session also includes simple IBNS 2.0 examples, and agree with recommendation to review the Live session from Hari on Session Aware Networking (BRKSEC-2691 or 2692).

Note that DNA-C will be based on IBNS 2.0 as it will help add the high-value benefits of IBNS 2.0 while removing the complexities of the advanced configurations.

[Mark DeLong]

Thanks Chyps!

The more I think about it the more I think the syslog option would not be all that great either. Though I'm not sure I like the route tracking option I saw in the BRKSEC-3699 slide deck. I think an IP SLA option with a tracking object would be better. Maybe track both of the ISE PSNs with individual tracks and then have a track object that tracks the states of the two other tracks? To an extent though all of these ways are pretty messy.

I do agree the C3PL is cleaner about this. And from what you guys have been saying it is the way forward (or at least until DNA-C). So I'll have lab it up and learn it. I'll probably look to implement it on my next big greenfield. The more I look at it the policy seems a little long but it makes sense as long as you know the auth process. And its probably pretty much copy/paste once you learn it well enough. Also, you definitely save on lines of config over all. Not too mention who doesn't hate port configs that are so long they take up almost the whole pager.

Thanks!

Mark

[Greg Gibbs]

Hi Mark,

With the legacy IBNS function on the switches, there is no built-in mechanism for the switch to replace the pre-Auth ACL (used for Low Impact Mode) with a permissive ACL when the switch loses connectivity with all RADIUS servers. The only way to replace the ACL is using an EEM script as Alex suggested.

You should also be aware of a limitation in earlier code where the RADIUS server is marked ALIVE temporarily when it's still down, which causes an issue with the EEM script. See the following link and search for 'automate-tester probe-on' for a description of the issue and fix.

Demystifying RADIUS Server Configurations - Cisco

The newer Policy Aware IBNS (a.k.a. IBNS 2.0) has a built-in feature to replace the pre-Auth ACL with a Critical ACL on RADIUS server communication failure.

IBNS 2.0 Deployment Guide - Cisco

[Craig Hyps]

You may also want to review the last section of BRKSEC-3699 which reviews failover for this scenario.  It covers sample EEM scripts, use of IBNS 2.0 as well as other options to handle this scenario.  Reference version of session is posted to CiscoLive.com - latest version from Barcelona 2018.

[Mark DeLong]

Thanks, Chyps!

I'm going to totally watch that VOD when I get a chance. I did skim the slide deck and saw the eem and C3PL answers you mentioned. Thanks for your help, dude!

Mark

[Mark DeLong]

Grgibbs,

Amazing answer! Sorry I gave the correct answer to Alex as he was right first. If I could have given two I would have certainly gave you one too. The docs were great. I'm going to see if I can find the video on that live presentation when I get chance. So far I just skimmed through the slide deck.

The IBNS 2.0 doc definitely gives the type of answer I was looking for for Critical ACL fallback. And my switches have new enough code to support it on this project. That said, I found that you have to convert all your authentication code to the new format to use the critical ACL functionality....which is problematic in the least. Also, the policy maps look absolutely heinous to configure. I know you can convert it but that's not really my style (being a ccie and consultant, I am expected to know it). I need to lab up that new format extensively before I can deploy that to my customers if I decide to.

What I found really odd was the IBNS 2.0 doc is dated 2013 for its last update. But I haven't see any ISE training or documentation reference this identity access format in switches. I have been learning and labbing ISE for a about a year now. Nothing I have read or watched mentioned this new format. Not the ISE device configuration references (Cisco Identity Services Engine Administrator Guide, Release 2.3 - Switch and Wireless LAN Controller Configuration Requ…) or the SISAS cisco official VOD class, or anything else I have read...So did this configuration model not catch on as far as you know? It does seem overly complicated like a lot of Cisco's configuration methodologies that use way too much policy/class hierarchy (ZBF, PFR, etc).

The Demystifying Radius server configurations seems great. I'm gonna give that a read to. I was already using the automate-tester command but I added the "probe-on" into my template. It totally makes sense for bigger deployments. No need to have a crap ton of radius probes running all the time. I also added the "radius-server deadtime 10". It defaulting to zero would have really messed up a script based on the syslog messages. Thanks a million for mentioning that behavior!!

Thanks!

Mark

[Greg Gibbs]

Hi Mark,

IBNS 2.0 has been around for awhile. It did have a slow adoption as some of the bugs were worked out, but has become general best practice for greenfield deployments by Cisco Advanced Services. It does take some getting used to and adds a bit of complexity, but it also solves some of the inherent problems in the legacy IBNS functions.

It also reduces a lot of configuration bloat as you configure the policy one place and simply attach it as a template to the interfaces.

It's a couple of years old, but there is a really good Cisco Live presentation on IBNS 2.0 that breaks down a lot of the structure and functionality.

IBNS 2.0: New-style 802.1X and more - BRKSEC-2691

Cheers,

Greg

[Mark DeLong]

Thx, Greg! That is the one thing that seemed nice about it....a lot less port config. I'll give it a watch and see about using it on my next project! Thanks for the info!

Mark

Sent from my android phone. Please excuse my brevity.