Introduction
In this article, we take a look at the Windows startup sequence, how it affects both machine and user network authentication, and why it has one major weakness. We also take a quick look at why deploying TEAP instead of standard EAP-TLS might be a step in the right direction.
Windows Startup & Network Authentication
I have put together an image that shows the order of operations for Windows machines during startup, and in which order certain components are run as the operating system starts up. This image is based of an old image that was once put together by Cisco, a long time ago, and I have yet to find the original source. I have put my own spin on this image to modernize it and make it a bit clearer than the original.
You can download a high-resolution PDF of this graphic here (v1.1)
Background
For maximum security and control of the users' network access, using certificates for both machine and user authentication has always been the "holy grail" and the best thing available on the Windows operating system. In more technical terms, this means running EAP-TLS authentication two times to log in to the network, once for the machine and once for the user.
But, there has always been one major issue when certificates are used for both the machine and the user authentication, which is getting the user certificate onto the machine in the first place. In most cases, computers are prepared in advance before being handed out to the user, and during these pre-configuration steps, the computer is joined to the Active Directory and a machine certificate is issued to it. However, the user's certificate only comes into play later.
Due to the Windows startup sequence shown in the image above, you may have noticed that a user's certificate is not issued and downloaded to the computer until AFTER the user has made it into Windows.
Since the User Network Authentication takes place right AFTER the user has pressed “Enter” on the Windows login prompt after filling in their login credentials, this means that the User Network Authentication will fail the first time the user logs in, which could result in the user being left without any network connectivity at all (especially on wifi).
In the case where the computer is configured to use EAP-TLS for both machine and user authentication, no user certificate will be presented to the RADIUS server at all when the first User Network Authentication takes place, resulting in Windows not connecting to the network. Since there is no user certificate available, no User Network Authentication attempt will take place.
Standard EAP-TLS vs TEAP with EAP-TLS
The scenario described above is one major hurdle to implementations of running double network authentication with certificates. Depending on your use cases, there are some workarounds, like always requiring the first login to be done on a wired connection (without any 802.1x authentication), but in this day and age most people only use wi-fi for network connectivity, and wired connections are scarce. I have run into several offices that simply do not have wired connections at all, everyone is just using wifi.
However, with the introduction of the new EAP method called TEAP and EAP chaining in Windows 10 version 2004 release in May 2020, there is new hope for running double certificate authentication.
TEAP is based on Cisco's own EAP-FASTv2 with EAP Chaining that was previously only available if you have installed the AnyConnect Network Access Manager (“NAM”) supplicant software on your Windows computer.
With standard EAP-TLS, machine and user authentication take place separate from each other, which means that the RADIUS server that is doing the authentication also treats these two authentications as two different authentications. In TEAP and EAP-FASTv2, however, you can use EAP Chaining to combine these two authentications in a way that allows the RADIUS server to make a decision based on the combination of these two authentications.
As such, there are 4 different states of a successful authentication:
User and Machine Both Succeeded
User Failed and Machine Succeded
User Succeeded and Machine Failed
No Chaining Used (similar to PEAP outer tunnel with inner EAP-TLS authentication)
This is interesting, because the Windows startup sequence is the same when TEAP is being used, and by utilizing EAP chaining, you can trigger the authentication condition "User Failed and Machine Succeeded" when the user is logging in to the computer for the first time since the user's certificate is yet to be issued and downloaded.
This gives you the opportunity to give the computer some sort of network access (authorization) that is limited, but enough to access the internal PKI/Certificate Services to get the user's certificate very shortly after the user sees the Windows desktop for the first time.
However, even with both the machine and user certificates in place, Windows will NOT automatically trigger a new, proper User Network Authentication, you will have to solve this another way.
To trigger a new authentication flow (and a proper User Network Authentication) you can either:
Reboot the computer
Log out and back in again
Unplug network wire/put back in again (for wired connections only)
Turn wired network adapter off and on again (for wired connections only)
Disconnect from SSID and connect again (for wifi connections only)
Turn wifi network adapter off and on again (for wifi connections only)
As you can see, none of the options are particularly user experience friendly, but you could probably automate some of these workarounds using scripts that are run after the first time a new user has logged into a computer.
Final Notes
I wish Microsoft would add some way to automate the last step and build it right into their TEAP implementation. It seems like such an oversight to have gone through the trouble of introducing TEAP and native EAP Chaining support to Windows 10, only to have it somewhat stumble in the end.