topic Re: If 802.1x fails globally?? in Network Access Control

If 802.1x fails globally??

Michael Bartholomæussen — Thu, 09 Aug 2018 08:25:09 GMT

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

Re: If 802.1x fails globally??

Rob Ingram — Thu, 09 Aug 2018 09:06:26 GMT

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

Re: If 802.1x fails globally??

Michael Bartholomæussen — Thu, 09 Aug 2018 09:49:13 GMT

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

Re: If 802.1x fails globally??

Rob Ingram — Thu, 09 Aug 2018 10:52:31 GMT

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

Re: If 802.1x fails globally??

Michael Bartholomæussen — Thu, 06 Sep 2018 13:08:08 GMT

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?

Re: If 802.1x fails globally??

Cory Peterson — Thu, 06 Sep 2018 13:10:05 GMT

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

Re: If 802.1x fails globally??

Michael Bartholomæussen — Thu, 06 Sep 2018 13:15:21 GMT

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?

Re: If 802.1x fails globally??

Cory Peterson — Thu, 06 Sep 2018 13:31:09 GMT

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.

Re: If 802.1x fails globally??

Michael Bartholomæussen — Thu, 06 Sep 2018 13:37:37 GMT

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.

Re: If 802.1x fails globally??

Cory Peterson — Thu, 06 Sep 2018 13:41:56 GMT

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

Re: If 802.1x fails globally??

Michael Bartholomæussen — Thu, 06 Sep 2018 14:10:09 GMT

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?

Re: If 802.1x fails globally??

Cory Peterson — Thu, 06 Sep 2018 14:22:45 GMT

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.

Re: If 802.1x fails globally??

paul — Thu, 06 Sep 2018 14:40:13 GMT

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.

Re: If 802.1x fails globally??

Michael Bartholomæussen — Thu, 06 Sep 2018 17:47:22 GMT

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?

Re: If 802.1x fails globally??

paul — Thu, 06 Sep 2018 17:54:15 GMT

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.

Re: If 802.1x fails globally??

Rob Ingram — Thu, 06 Sep 2018 18:05:44 GMT

If the client is issued a certificate from AD using GPO and if configured the client will automatically renew certificates before expiration, usually a couple of months before expiration. Therefore this renewal process would all be transparent to ISE, you are reliant on AD/GPO doing it's job.

HTH

Re: If 802.1x fails globally??

Michael Bartholomæussen — Thu, 06 Sep 2018 18:06:50 GMT

my thought exactly, and since MAB auth is connected, there will be no CoA. What if we imagined that a client with an expired certificate gets profiled with CorpPC_EXPRIED, and with the new certificate it gets the old profile back CorpPC, and then the new profile triggers CoA?

On the other hand, if a client has an expired certificate the machine hasn't been in contact we the domain for a long time, then there might be a valid reason to contact the IT department 🙂

I'm going to pick at this again, what if the server side certificate expires, the one ISE uses to authenticate clients, and all endpoints get MAB auth and hits the portal. How would we fix this after the certificate have been updated?