Thanks for the comprehensive Windows supplicant screenshots. You are doing EAP-TLS User Authentication. It means that when the PC boots up and gets to the Windows Login screen, there will be no 802.1X sent to the switch. This explains the MAB. If the MAB causes an access-reject from ISE, then the switchport won't be in a good state and the PC might not have an IP address. Once the user logs into Windows, the supplicant will kick in - but by this time it's too late because the Cisco switch already has a session - and there was no Layer1 link down/up to cause the switch to restart the NAC. So, your solution to bounce the port is just that - Link Down/Up to cause the NAC process on the switch port. And then hey ....! User auth from Windows kicks in and the EAP-TLS does its job.
If your machines are domain joined, then change your supplicant to use Machine Authentication. This will ensure that the PC gets the NAC out of the way while PC is booting up.
There is another mode called User/Machine auth - this does both. But it means that you will get a NAC event during boot up to auth the machine, and then a NAC event when the user logs on. If you don't need to NAC every time the user logs on, the just do machine auth.
I will caution though ... what happens if the laptop goes to sleep after you've logged in and working for a while? Then come back from sleep and log into windows ... network will not work. Because the login event didn't trigger NAC event.
This is one reason to do both user/machine auth together, as long as you have a machine cert (always the case for domain joined machines) as well as user certs (pushed by Group Policy).
There are further complications if the user switches between wired and wireless, and mixes EAP methods (like EAP-TLS for machine auth and EAP-PEAP for user auth) - in those cases you will need Cisco AnyConnect client software.
OR ... the future ... ISE2.7 and Windows 10 (May 2020 release) using TEAP. The solution to all of the above.
