dot1x "dead action authorize" not working as anticipated.

[s-daly]

Hello:

I'm running wired dot1x authentication on a Catalyst 3650 stack, 3.6.3 code. Everything is working fine, and authenticating as expected, when the ISE servers are reachable on the network and available. However, if the ISE servers become unreachable, I need the switch to go ahead and "fail-open" the access ports. Here is the current pertinent config:

aaa new-model
!
!
aaa group server radius ISE
 server-private 192.168.0.1 auth-port 1812 acct-port 1813 timeout 3 retransmit 3 key XXXX
 server-private 192.168.1.1 auth-port 1812 acct-port 1813 timeout 3 retransmit 3 key XXXX
!
aaa authentication login default group local
aaa authentication enable default enable
aaa authentication dot1x default group ISE
aaa authorization console
aaa authorization exec default group local
aaa authorization network default group ISE
aaa accounting dot1x default start-stop group ISE

!

! here's a port config example:

interface GigabitEthernet 1/0/39
 switchport mode access
 switchport access vlan 23
 switchport voice vlan 123
 ip access-group PRE_AUTH in
 authentication event server dead action authorize
 authentication host-mode multi-auth
 authentication open
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication timer restart 6
 authentication timer inactivity 3700
 authentication violation restrict
 mab
 dot1x pae authenticator
 dot1x timeout quiet-period 6
 dot1x timeout tx-period 3
 dot1x timeout supp-timeout 3
 spanning-tree portfast

!

ip access-list extended PRE_AUTH
 remark PERMIT DHCP
 permit udp any eq bootpc any eq bootps
 remark PERMIT DNS
 permit udp any any eq domain
 remark PERMIT PXE BOOT
 permit udp any any eq tftp
 remark CAPWAP FOR APs
 permit udp any any range 5246 5247
 remark DENY EVERYTHING ELSE
 deny   ip any any

My understanding is the "authentication event server dead action authorize" command tells the switch not to force authentication on the port if the ISE servers are unavailable, however, this is not what I'm seeing; when the ISE servers are unreachable, all the ports with dotx configured fail authentication, and no devices can access the network, in which is catastrophic:

sw1#sho authentication sessions int g1/0/39 detail
            Interface:  GigabitEthernet1/0/39
               IIF-ID:  0xC7A1C000000229 
          MAC Address:  68f7.287f.7af8
         IPv6 Address:  Unknown
         IPv4 Address:  10.2.23.21
            User-Name:  host/**hidden**
               Status:  Authorized
               Domain:  UNKNOWN
       Oper host mode:  multi-auth
     Oper control dir:  both
      Session timeout:  N/A
    Common Session ID:  0A0201170000000D0E2AFA40
      Acct Session ID:  0x00000001
               Handle:  0x34000001
       Current Policy:  POLICY_Gi1/0/39

Local Policies:
         Idle timeout:  3700 sec

Method status list:
       Method           State
       dot1x            Authc Failed

Is this a bug? Or do I misunderstand the usage of the "authentication event server dead action authorize" command? If so, what command(s) should I use to achieve a "fail-open" scenario if the ISE servers become unreachable?

 Thx.

[Javier Henderson]

Try:

authentication event server dead action authorize vlan <vlan id>

[s-daly]

Specifying a VLAN in this situation makes no difference.

[s-daly]

So, if I remove the "pre-authorization" ACL from the interface:

no ip access-group PRE_AUTH in

This fixes the problem stated above, however, this is a security problem, as there would be no immediate security on the port, during the authentication process, under normal conditions, and breaks our security policy. Is there a workaround for this, where I have a "pre-auth" ACL on a dot1x port, and have a "fail-open" scenario if ISE is unavailable?

I can't help but think most implementations of wired dot1x would want this functionality...

[jan.nielsen]

You can use templates to change the config of the port in case of inaccessible/critical situations with your radius communication

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/whitepaper_C11-729965.html#_Toc404649488

[s-daly]

The service templates certainly appear to be something that could solve this problem; I'll have to look further into it.

That said, this functionality appears to be a very complex and verbose solution for something seemingly very simple: "If RADIUS is unavailable, then permit all". I would think there would be a simpler solution...

[nspasov]

Hi there! When using "Low-Impact" mode, the pre-auth ACL is replaced with a DACL that is pushed from the RADIUS server. If the RADIUS server is unavailable, there is nothing to instruct the switch to remove that pre-auth ACL. 

So your options here are:

1. Using templates that can include a critical acl (what Jan mentioned above). 

2. Use an EEM script:

http://www.alcatron.net/Cisco%20Live%202013%20Melbourne/Cisco%20Live%20Content/Security/BRKSEC-3040%20%20Advanced%20ISE%20and%20Secure%20Access%20Deployment.pdf

3. You can also make the pre-auth ACL a bit more permissive. Not ideal and not as secure but also an option. 

I hope this helps!

Thank you for rating helpful posts!

[aukhadiev]

Hi, s-daly...

If you use multiple-authentication mode (authentication host-mode multi-auth) the critical authentication VLAN feature when the RADIUS server is down do not activate by command:

authentication event server dead action authorize vlan vlan-id

Instead of this, try:

authentication event server dead action reinitialize vlan vlan-id

Please see  - HowTo: Universal Switch Config (page 14)

[faizanshaikh.net]

Hi Aukhadiev,

I am following a same situation and using this command 'authentication event server dead action reinitialize vlan vlan-id' on my switchports to allow users to authenticate to the network in case of NAC unreachability. But I am highly concerned about security issue that can occur if a malicious user can connect to my network in this period as I am just doing basic authentication without any posture assessment.

Any help will be appreciated.

Regards,

Faizan