If 802.1x fails globally??

[Michael Bartholomæussen]

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

[Rob Ingram · Accepted solution]

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

[Michael Bartholomæussen]

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

[Rob Ingram]

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

[Michael Bartholomæussen]

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?

[Cory Peterson]

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

[Michael Bartholomæussen]

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?

[Cory Peterson]

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.

[Michael Bartholomæussen]

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.

[Cory Peterson]

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

[Michael Bartholomæussen]

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?

[Cory Peterson]

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. 

[paul]

The other option if you don't want to accept expired certs is you could profile these devices as AD domain joined devices using the AD profiler.  This assumes they are AD domain joined.  Then in your MAB rule you could give them enough access to renew certs.

[Michael Bartholomæussen]

With both solutions, clients will be allowed to renew their certificates, but will or can ISE trigger CoA when a new certificate is issued to the client? Or is it necessary to trigger dot1x on the port to process the client again?

[paul]

ISE won't trigger anything because it doesn't know anything about the cert renewal. That is all via the client talking to AD/PKI. I am not sure what the client will do honestly. I have seen clients periodically retry Dot1x and if they do the switch will attempt to authenticate the device with Dot1x and switch out of MAB. The other thing you could try (not sure if I would do this) is cranking down the reauth timer on the rule you use for this expired cert situation.