cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1201
Views
0
Helpful
16
Replies

If 802.1x fails globally??

Hi All,

 

If it should happen, that something goes wrong and ISE cant authenticate devices on switch ports via 802.1x, what immediately actions could remove 802.1x from switches or allow all devices onto the network?

 

Best regards,

Michael

1 Accepted Solution

Accepted Solutions

Hi,

In the event that the switch is unable to communicate with ISE,  the switch will mark the radius servers as dead. If you have the interface level commands configured such as:-

 

 authentication event server dead action authorize vlan 11
 authentication event server dead action authorize voice
 authentication event server alive action reinitialize

 

...existing authenticated sessions will continue, any new connections made will be authorized (data to vlan 11 (in this example) and voice).

 

HTH

 

View solution in original post

16 Replies 16

Hi,

In the event that the switch is unable to communicate with ISE,  the switch will mark the radius servers as dead. If you have the interface level commands configured such as:-

 

 authentication event server dead action authorize vlan 11
 authentication event server dead action authorize voice
 authentication event server alive action reinitialize

 

...existing authenticated sessions will continue, any new connections made will be authorized (data to vlan 11 (in this example) and voice).

 

HTH

 

Makes perfect sense if ISE fails. Thanks for the info.

You'll probably want these global commands, to detect if the aaa server is dead and then mark it as down:-

radius-server dead-criteria time 5 tries 4
radius-server deadtime 30

HTH

I'm back on this topic.

I had an case were my switches were running with auth open, but the GPO that sets 802.1x on clients weren't deployed yet. Testing a policy for MAB and guest portal, all the users failed dot1x, and then got to MAB. All the users got redirected to the portal.

Luckily this only happened to a handful of users, so the impact were limited. But if all 500+ users got hit, how would they recover?

If MAB is still working then ISE is still working, the outcome you saw is what is expected.

But if all the users hits the guest portal they're "stuck" here.
What I did, was I disabled the redirect, and then ran "clear auth session" on the affected swtiches. Then the users shouldn't unplug their cable to trigger dot1x.
Could it be done with a port bounce from the end devices overview?

Your production switches should be in monitor mode, while in monitor mode you should have all results in your policy set to "permit access". This will allow you to test policy and ensure everyone is hitting the correct policy. Anyone hitting the wrong policy can then be fixed/remediated before going to enforcement mode where they can lose network access.

 

Working through a methodology of Monitor mode and moving to enforcement mode will help to alleviate any issue you may run across.

 

 

Also only test on a non production switch so you do not affect users.

I get what your saying, and my switches are running in monitor mode. Despite the PermitAll at the end of every policy, users fails 802.1x, and then do MAB. Then the wired mab -> redirect catches the request and sends the users off to the portal. Like you wrote before, this is expected.

 

If you are in monitor mode there should be no redirect setup. Can you share some screenshots of your policy?

I restricted the policy to only be applied to my desktop switch. NAS 192.168.2.25.

The GUEST_REGISTRATION is the redirect, and GUEST_PORTAL_ACCESS allows the users afterwards.

 

Lets just imagine that the certificate for dot1x expires and all wired endpoints are redirected to the portal. Then we change the certificate, and all endpoints need to trigger dot1x again?

 

You can change settings in ISE and build a policy to allow the authentication of expired Certs, then when they go to authorization you can give them limited access to renew their Certs, this will avoid them being sent to the webauth portal.