I am experimenting with using Intel AMT as the sole 802.1X supplicant for the whole device. The goal is to remove the need for the operating system to know anything about 802.1X, as it is ideally completely handled by AMT.
The results so far indicate that AMT is not suitable for that purpose, and I require some clarification on configuration options within AMT regarding 802.1X.
My main source of confusion comes from the configuration option "Enable 802.1X for AMT even if host is not authorized for 802.1X" in the advanced wired 802.1X settings. How is that detected? How will AMT behave? What exactly does authorized mean in this context?
Environment:
- Windows Server 2016 acting as Active Directory, Certificate Services, Network Policy Server (RADIUS), as well as providing DHCP and DNS
- Cisco Catalyst 2960 acting as a 802.1X-enforcing switch
- Dell Latitude E7470 acting as the client
- AMT v11 is provisioned and has valid and working 802.1X credentials (EAP-TLS)
- Host OS (Windows 10) does not have any 802.1X credentials (This is intended!). The 802.1X supplicant service (Wired AutoConfig) is enabled but deactivated for the network interface.
The device shows the following behavior:
| Device state | 802.1X behavior |
|---|---|
| Powered off | AMT promptly negotiates 802.1X and the device is reachable over the network. |
| Powered on, network adapter disabled in OS | AMT promptly negotiates 802.1X and the device is reachable over the network. |
Powered on, network adapter enabled in OS "Enable 802.1X for AMT even if host is not authorized for 802.1X" = yes | Windows cannot negotiate 802.1X since the supplicant is not even enabled. AMT negotiates 802.1X every ~300s, the device is reachable and manageable over the network for ~100s before AMT issues an EAP Logoff, disrupting the connection. During this time, the operating system is still not able to use the network. |
Powered on, network adapter enabled in OS "Enable 802.1X for AMT even if host is not authorized for 802.1X" = no | Neither Windows nor AMT ever respond to EAP messages. No connectivity (as expected) |
The third case is the interesting one here. Note that AMT does not answer the Switch's Request Identity Messages, but rather initiates the 802.1X Session on its own issuing EAPoL Start messages.
What is the purpose of this periodical AMT-based 802.1X login? Do I have to be lucky as an Admin to connect to the device just in the right moment or tell my customer to turn their device off to properly administrate it?
And finally, is there any option I missed, that would allow the Host OS to freely use an unlocked network connection once AMT has dealt with the 802.1X authentication?
I am thankful for any input.