Clarification on the behavior of AMT in wired 802.1X networks

[SDohm]

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 state802.1X behaviorPowered offAMT promptly negotiates 802.1X and the device is reachable over the network.Powered on, network adapter disabled in OSAMT 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" = noNeither 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.

[MichaelA_Intel]

blablub44

Hi blablub44,

I'll do my best to answer your questions, hopefully reducing confusion:

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?

The best answer I have is at this link:

https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments/activepassivemode.htm Intel(R) AMT SDK Implementation and Reference Guide

What is the purpose of this periodical AMT-based 802.1X login?

If the operating system is down, AMT still needs to be able to make a connection and needs the ability to be authorized.

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?

No, this setting can be changed under the advanced wired 802.1x settings:

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?

No, there is no option for this.

Regards,

Michael