ISE Node Failure and Pre-Auth ACL best practices

[alfonso.cornejo]

Hi,

Is there a best practice about how to give access to the users when the ISE node fails and the user ports have a Pre-Auth ACL configured?

I've been working on this but I can't find a way to do it, I have this configuration for radius, port and Pre-Auth ACL:

Radius:

radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server dead-criteria time 5 tries 3
radius-server host 192.168.0.211 auth-port 1645 acct-port 1646 test username test-radius key 7 XXXXXXXXXXXX
radius-server deadtime 2
radius-server vsa send accounting
radius-server vsa send authentication

User Port:

interface FastEthernet1/0/1
switchport access vlan 100
switchport mode access
switchport voice vlan 200
ip access-group PRE-Auth in
authentication event fail action next-method
authentication event server dead action reinitialize vlan 100
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication open
authentication order dot1x mab webauth
authentication priority dot1x mab webauth
authentication port-control auto
authentication violation protect
mab
dot1x pae authenticator
dot1x timeout tx-period 2
storm-control broadcast level 25.00
storm-control action shutdown
spanning-tree portfast
spanning-tree bpduguard enable
end

Pre-Auth ACL:

ip access-list extended PRE-Auth
remark DHCP
permit udp any eq bootpc any eq bootps
remark DNS and Domain Controllers
permit ip any host 192.168.0.215
remark Deny All
deny ip any any

When the ISE node is down, this is the status of the auth in the port:

ISE-SW#sh authentication sessions int f1/0/1
Interface: FastEthernet1/0/1
MAC Address: f0de.f1b2.a0a6
IP Address: 172.16.1.2
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Critical Auth
Vlan Policy: 100
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A800DC0000002B009E2129
Acct Session ID: 0x00000030
Handle: 0x7500002B

Runnable methods list:
Method State
dot1x Authc Failed
mab Not run

Critical Authorization is in effect for domain(s) DATA and VOICE

The device is authorized but it has no access no the network unless I remove the Pre-Auth ACL.

I found this post from 2013 https://supportforums.cisco.com/t5/aaa-identity-and-nac/ise-node-failure-pre-auth-acl/td-p/2235177 but the authentication event server dead action reinitialize vlan X does not allow the traffic when the Pre-Auth ACL is there.

Any suggestions?

Regards,

[agrissimanis]

Unfortunately there is no straightforward solution for this, at least not with IBNS 1.0 (that is using the traditional "authentication" interface level commands). One possible solution is to move to IBNS 2.0 configurations (look for Critical ACL on AAA Failure in that document, that is the feature you need). IBNS 2.0 is much more flexible and powerful, but also very different in terms of configuration.

With the classic style configs, there is also an option to get around that problem. You can use EEM scripts to look for "All RADIUS servers dead" events and add "permit ip any any" to your pre-auth ACL, then when the ISE nodes are reachable again you can remove the rule. Something like this:

event manager applet default-acl-fallback

 event syslog pattern "%RADIUS-3-ALLDEADSERVER" 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-DEFAULT"

 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-DEFAULT"

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

 action 4.0 cli command "end"

 Both optoions are platform/IOS version dependant though

[alfonso.cornejo]

Hi,

Thank's alot for your suggestion! I'll try both of them to see wich one is better for my enviroment.

What do you think about using closed mode?

Thanks in advanced.

Regards,

[nspasov]

In addition to what was already suggested, I would also recommend you check the following thread:

https://supportforums.cisco.com/t5/aaa-identity-and-nac/ise-aaa-failures-for-2960s-switches-in-low-impact-mode/td-p/2892430

There are a few other options that you could use.

I hope this helps!

Thank you for rating helpful posts!

[agrissimanis]

The move to IBNS 2.0 will require some effort to get it right I think, but in future the classic style configs will probably be deprecated anyway, so it needs to be done at some point ;)

EEM wold be a quick win, if your switches support it.

I never really seriously considered closed mode, but I guess it depends on the environment. We have wide range of devices and access requirements so closed mode is just not a good fit in our scenario.