topic Re: 802.1X When Server Unreachable in Network Access Control

802.1X When Server Unreachable

DM812 — Fri, 17 Mar 2023 11:21:21 GMT

We have RADIUS setup on our switches with 2x RADIUS servers used for authenticating admin access to the switch's, and 1x RADIUS server used for port authentication for devices (not ISE).

When the RADIUS server for port authentication is lost, I need to the ports to fail open onto the VLAN that are statically set on the port.

I can use the "radius-server dead-criteria" command but is there anyway to specific which RADIUS server to detect on as if the 2x RADIUS servers for admin access go down, I don't want this to cause the switchports to fail open?

Re: 802.1X When Server Unreachable

MHM Cisco World — Fri, 17 Mar 2023 11:29:50 GMT

make server group
assign one server (the one that you want to detect it alive) under the server group
use this server group for the aaa auth dot1x
I think this what you need here.

NOTE:- always use LOCAL as failback if there is something wrong in your config, and also config username/password & enable passowrd for LOCAL access

Re: 802.1X When Server Unreachable

Rob Ingram — Fri, 17 Mar 2023 11:44:14 GMT

@DM812 you can use critcal authentication feature, which will authorise new sessions into the default (or dedicated) VLAN when the RADIUS server is unreachable.

Example: https://integratingit.wordpress.com/2020/12/02/802-1x-critical-authentication/

https://community.cisco.com/t5/security-knowledge-base/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515#toc-hId-1018207729

Re: 802.1X When Server Unreachable

Flavio Miranda — Fri, 17 Mar 2023 12:05:23 GMT

If I understood properly, you use on server for manage authentication to the switch (TACACS) and another server as NAC (Radius), right?
If you want to have redundancy for NAC, you need to have more the one NAC running on your network. Then, on the switch side you can add this:

aaa group server radius RADIUS

server name <Server1>

server name <Server2>

aaa authentication dot1x default group RADIUS

aaa authorization network default group RADIUS

aaa accounting dot1x default start-stop group RADIUS

aaa server radius dynamic-author

client x.x.x.x server-key 6 <key>
client x.x.x.x server-key 6 <key>

radius server <Server1>
address ipv4 x.x.x.x auth-port 1812 acct-port 1813
automate-tester username <user> ignore-acct-port idle-time 5
key 6 <key>
!
radius server <Server2>
address ipv4 x.x.x.x auth-port 1812 acct-port 1813
automate-tester username <user> ignore-acct-port idle-time 5
key 6 <key>

Re: 802.1X When Server Unreachable

DM812 — Fri, 17 Mar 2023 12:43:32 GMT

We have the below config...

aaa group server radius SwitchManagementSSH
server name NPS1
server name NPS2
!
aaa group server radius NAC
server name NAC1
!
aaa authentication login default group SwitchManagementSSH local
aaa authentication dot1x default group NAC
aaa authorization exec default group SwitchManagementSSH local
aaa authorization network default group NAC
aaa accounting dot1x default start-stop group NAC

So SSH access to the switch uses the NPS servers, whereas device auth (what is plugged into the switchports) uses the NAC server.

If the NAC server goes down (this is actually 3 servers in a cluster) but the NPS servers stay up, I want the ports to fail open to a specific VLAN.

The switchports currently have the below authentication config...

authentication host-mode multi-domain
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate 65535
authentication timer restart 10800
authentication violation replace
mab
dot1x pae authenticator
dot1x timeout quiet-period 30
dot1x timeout tx-period 10

Re: 802.1X When Server Unreachable

MHM Cisco World — Fri, 17 Mar 2023 12:46:04 GMT

Yes, that how it work,
the dot1 will check alive of server it use for auth the port not all server you config in SW.
aaa authentication dot1x default group NAC

Re: 802.1X When Server Unreachable

DM812 — Fri, 17 Mar 2023 12:53:12 GMT

Great thanks, so if I apply the below config to the switchport, it will only fail open if the RADIUS server used in the "aaa group server radius NAC" group is down due to the command "aaa authentication dot1x default group NAC"?

authentication event server dead action authorize vlan 10 (will allow data and set to use VLAN 10?)

authentication event server dead action authorize voice (will allow voice on the VLAN that is statically set on the port?)

authentication event server alive action reinitialize (once the server is back up, it will try to authenticate again?)

Re: 802.1X When Server Unreachable

MHM Cisco World — Fri, 17 Mar 2023 13:01:23 GMT

Correct

Re: 802.1X When Server Unreachable

DM812 — Fri, 24 Mar 2023 13:40:39 GMT

After testing, when I look in the MAC table it shows the Cisco IP phone and PC in both the voice and data VLANs (although both devices get an IP in their respective VLANs and ping/work fine), any ideas?

8 0087.64a9.dd3a STATIC Gi1/0/1
8 9c2d.cd38.4bbb STATIC Gi1/0/1
32 0087.64a9.dd3a STATIC Gi1/0/1
32 9c2d.cd38.4bbb STATIC Gi1/0/1

There seems to be issues with the "authentication event server alive action reinitialize" command as when added the devices drop pings and seem to re-auth even when the RADIUS servers are still down (I have an ACL on to block traffic to these servers from the local switch).

Re: 802.1X When Server Unreachable

MHM Cisco World — Sun, 26 Mar 2023 21:25:36 GMT

I will check this new Info. today

Re: 802.1X When Server Unreachable

Greg Gibbs — Sun, 26 Mar 2023 21:57:15 GMT

The legacy IBNS framework you are using on the switch does not effectively understand how to handle the failure and recovery of the AAA servers. From what I recall, the switch will simply mark the AAA servers alive after a period of time and wait for the next session failures before marking them dead again. As far as I know, these issues were never resolved in the legacy framework.

If your switch supports the IBNS 2.0 framework, you would be better converting to that configuration as it has enhancements for these scenarios as well as other functions that the legacy framework did not provide. See more information on the IBNS 2.0 framework (and specifically the Critical Authorization function) in the ISE Secure Wired Access Prescriptive Deployment Guide.