TEAP Problem with Windows 10, ISE 3.2 and EAP Chaining...

Consider the following scenario:

• You want to implement port-based authentication for both users and computers using certificates installed in their respective certificate stores (EAP-TLS).
• As the hardware team in your company handles the computer onboarding process, they join the computer to the domain. Consequently, the policy that applies the required configuration for certificate autoenrollment is implemented before the computer is sent to the user's office.
• To ensure proper authentication of users and computers, if the computer is sent to the user's office without first installing the user's certificate, the authentication process for the user will fail.

One possible solution to this limitation is to leverage the EAP Chaining feature (TEAP with EAP-TLS as the inner method). In this context, you want to limit the computer's network traffic if the user fails authentication but the computer succeeds. Specifically, if the user logs into the computer and it successfully passes authentication, the computer should only have access to the network to contact the Certificate Authority (CA) and install its required certificate.

To implement this scenario, I created the following authorization policy and enabled EAP Chaining under TEAP in Allowed Protocols section:

And the client computer is configured as follows:

After conducting the configuration described above and sending the computer to the user's office, the user powers on the computer. As a result, the following events occur in ISE:

Everything is normal up to this point. Now, when the user logs into the computer and successfully installs the required certificate in the certificate store (a process that occurs automatically due to autoenrollment), the second authorization policy does not match, resulting in a loss of connection to critical network services.

After conducting an in-depth investigation, I discovered that after the user logs in, the operating system enters the authentication phase by sending six consecutive EAPoL-Start messages without receiving any response from the switch. At this point, after approximately one minute, the endpoint repeats this process and then stops sending EAPoL-Start messages.

From this finding, I concluded that the issue lies with the switch, not the operating system. Consequently, I proceeded with my investigation by analyzing the switch's configuration. Initially, I removed all unnecessary 802.1X configurations from the endpoint-facing interface and tested again. This time, everything worked perfectly! I realized that one or more configurations on the interface were causing the issue. After thoroughly examining all the commands, I identified the one causing the problem: dot1x timeout ratelimit-period. This command, dot1x timeout ratelimit-period, defines the rate limit period, which throttles EAP-START packets from misbehaving supplicants. By using this command, the switch interprets the second round of EAPoL-Start messages from the endpoint (during user authentication) as coming from a malfunctioning endpoint and subsequently throttles the messages.

Conclusion: If you are using user-based authentication alongside computer authentication, avoid using the dot1x timeout ratelimit-period command.

I hope this is useful for you!