Client Management Suite

 View Only

Why Must Intel AMT Be Configured, and What is Required? 

Dec 27, 2011 11:23 AM

After receiving basic questions repeatedly over the years, the thought occurs - a foundational discussion around Intel AMT might help.   This article provides a snippet into a larger set of training materials.   The article does not cover the merits or usages of Out-of-Band Management, nor does it cover the intricacies or technical caveats some may face in successfully deploying Intel AMT.   Those topics can be referenced via other materials on Symantec Connect and so forth.  Instead, the focus here is on a few key fundamentals that may go a long way in building a core understanding and successfully implementing Intel AMT in your environment.

How Intel AMT Works

Intel AMT was originally built to provide out-of-band management within the physical chipset of a client computer.   At the introduction of Intel AMT more than 5 years ago, desktops were the primary focus of the technology.   The presentation slide shown below is a quick and simplified summary on how Intel AMT works.   In wired mode on the corporate network, Intel AMT traffic shares the same physical network interface as the host operating system.  

Communications to Intel AMT commonly occur on the same IP address, specifically when the system is using DHCP issued IPv4 addresses.   Traffic on ports 16992-16995 are directly intercepted by Intel AMT within the chipset before being passed to the host operating system... once Intel AMT is in a configured and accessible state.

If a firewall is running on the target client, in a wired mode the Intel AMT traffic occurs below the operating system and the firewall.  If the host operating system is not available, Intel AMT will continue to operate so long as power is attached and a network connection is present.

You will note the asterisk (*) and clarification that wireless traffic - 802.11 specifically - is seen by the host operating system.   In summary, only one service can own the physical network interface (i.e. the phy\mac).  This was briefly referenced in a previous post (click here).   In the case of wired LAN connectivity, the chipset was specifically built with Intel AMT integrated and connected through the wired LAN physical interface.   Per the link, only one service actively owns the communication, and often Intel AMT operates in a passive mode when the host operating system is present.   In the case of wireless LAN, this direct and tight integration doesn't exist in the chipset today.   (If you're interested to understand more on Intel AMT over wireless - let me know - would be a great topic for a future article.)


Infrastructure Considerations

A key phrase to remember "Once configured, Intel AMT is a network service awaiting an authenticated and authorized request".   

This implies that Intel AMT must be able to exist on a network whether or not the host operating system is available.   Within the Management Engine (ME) of the chipset, if Intel AMT is present and configured there is small IP stack maintaining the connection to the network.   Intel AMT enables reliable power control of the platform, booting for a network based ISO image, integration Keyboard-Video-Mouse (KVM), and more.   For this and related reasons, Intel AMT is packaged and shipped in an unconfigured state.   Only the target environment should configure Intel AMT to determine the appropriate settings... especially the authentication and authorization part.

The diagram below provides a summary of key infrastructure considerations when configuring and deploying Intel AMT in an environment.   Some of the options are configurable, other options are inherently built into the technology and not customizable.   See the configuration profile settings within the Out-of-Band Configuration Service Settings of the Symantec Management Platform to identify what settings may be configurable.

A little more detail on each quadrant:

Network Interface

  • Wired LAN within a corporate environment is preferred, and is often the required interface for initial configuration.   Since Intel sees traffic below the operating system, certain environmental variables can be set to designate internal vs. external traffic.   Specifically - the DHCP option 15 setting of the network against list of Home Domains defined during configuration.
  • Wireless LAN, specifically 802.11, is supported and can also be used for post configuration changes.   Network security settings are required along with defining or replicating the wireless profile into the firmware.   If a wireless LAN requires user intervention for access, Intel AMT may be unable to negotiate a connection (i.e. if you are at a public hotspot that requires user acceptance)
  • All communications occur across registered ports for Intel AMT, specifically 16992-16995

Network Protocol

  • By default, Intel AMT shares the same physical network interface as the host operating system.   DHCP IPv4 addresses are shared, with only the port differentiating how traffic is routed within the chipset
  • Static IP is supported.   In general, this will require more setup.   Post a comment if you require static IP.
  • Intel AMT can have an IP address on the network and respond to traffic even when the host operating system is unavailable.   Often the bigger challenge is locating the correct IP address of Intel AMT.   Intel AMT should also have the same FQDN as the host operating system, helping to ensure DHCP leases and DNS resolution are correct.   Due to diversity of networks and situations, sometimes the FQDN-to-IP resolution fails.   Intel AMT may have an IP address, but the requesting application is unable to identify the correct address.
  • Most communications are TCP\IP based.   In general, Intel AMT is waiting for a request.   In certain situations, such as a hardware alert, Intel AMT will send out a message via SNMP or WS-Events
  • 2010 and newer generations of Intel AMT do support IPv6.   Currently, Intel AMT requires a unique IPv6 address, different than the host operating system.  Correct resolution of FQDN-to-IP is an important consideration if considering use of IPv6 with Intel AMT.

Authentication and Authorization

  • All inbound session requests of Intel AMT as a network service must be authenticated and authorized.   Within the Intel AMT firmware settings is an Access Control List (ACL).   Authentication occurs via MD5 Digest or Kerberos.   Authorization is defined by access to realms or capabilities within the firmware.   In the case of Symantec Management Platform, it expects to access Intel AMT with the highest level of Intel AMT permissions - PT Admin.  
  • User consent refers to the graphics overlay screen with 6 random digits.   This is commonly used for KVM remote control as defined by the configuration profile.   In latest generation of Intel AMT platforms, if configured in Client Control Mode, boot redirection actions will also require user consent.  

Network Security

  • Intel AMT communications can be secured and encrypted via TLS (Transport Layer Security).   This also authenticates the session.   Remember that Intel AMT is the "service", meaning that a TLS certificate with private key is created for each Intel AMT device and stored in it's firmware.   The certificate is issued specifically to the FQDN of the Intel AMT device.   More information on why TLS could be used is provided here along with insights on "how-to" are provided here.
  • Intel AMT devices can be set to ONLY communicate with defined consoles or requesting applications via Mutual TLS.  In summary, in addition to the requesting application establishing a TLS session with Intel AMT, the Intel AMT device establishes a TLS session with the requesting application. 
  • Environments that require port authentication or secure Wireless Access Point communications will commonly have a form of 802.1x.   For Intel AMT to operate on an 802.1x enabled network, it must be configured with the correct posture information  (Remember, Intel AMT can exist and operate on a network even when the host operating system is inoperable.)
  • WPA\WPA2 refers to industry standard wireless security and protection.  This is required for Intel AMT operations over wireless, and can be defined within the Intel AMT configuration profile.
  • Trusted Domains provides a list of home domains for Intel AMT to correctly detect to which environment it is connecting.   "Trust Domains" refers to the DHCP option 15 value returned with a DHCP lease reply.   If no match is found based on the domain list configured into Intel AMT, the firmware network interface will be closed.    This is called "Environment Detection" (more information and example of incorrect usage can be found here)
  • Remote Access refers to the Intel AMT ability to connect over the internet to a defined Management Presence Service.   This connection can occur on-demand, per a defined schedule, or when a hardware alert occurs... per the configuration of Intel AMT.

At first glance, the above items are a lot to think about.   Especially with initial trial or proof-of-concept environments, start with the basics.   The basics include defining a password for the Intel AMT admin account and using DHCP IP v4 (default option).    In fact, with a fresh install of the Out-of-Band Management module in the Symantec Management Platform, a default profile with the minimal settings already exists. 

Adding the security layers, Kerberos authentication, wireless settings, or use of configuration options outside of the base Out-of-Band Management configuration interface are not recommended for beginners of Intel AMT.   Understand and validate the basics first.

Configuration Options

Before contemplating how to configure Intel AMT, validate that it truly exists and needs to be configured in your environment.   See the guidance provided with the Environmental Assessment

A key advantage of the Symantec Management Platform - it does not need to own the configuration of Intel AMT and any valid configuration of Intel AMT can be used.   Plus, the Out-of-Band Management module provides components for configuring Intel AMT as needed.  Should a configuration option not be accessible, you can also use a newer version of the Intel Setup and Configuration Service as described here.   

This degree of flexibility may be beneficial long term, along with overwhelming up front.   To help with your decision, shown is a chart of configuration options with a summary explanation below.

The question has been asked - "What is the easiest way to configure Intel AMT?"   My immediate answer is "via Host Based Configuration".    The real answer is "it depends on what you have and what you are trying to do"

Using the above chart, a brief explanation of the pros\cons is provided below in reverse order (i.e. from best, to better, to good):

Host Based Config  (Best)

  • Pros: As easy as delivering software to a target client.    The entire configuration process runs via the host operating system, with the settings directly applied into the firmware.   
  • Cons: Requires Intel AMT 6.2 or higher.   Requires Intel SCS 7.1 or higher.   User consent is required for KVM, boot redirection, and forced boot options (i.e. boot PXE).   The User Consent tool and interface is not presently available within the Symantec Management Platform outside of the KVM remote control screens. The System Defense feature, known as Network Filtering within Symantec Management Platform, is disabled.  
  • Why is this the best?   Because it is the least restrictive to getting Intel AMT configured and best aligned to how system configuration operations commonly occur.   Host Based Configuration can occur via wireless, VPN, and so forth.
  • More information and demonstration available here

Remote Config Certificate (Better)

  • Pros: If systems already deployed in the environment, a certificate is acquired and configuration of Intel AMT can commence without touching the systems.  Remote Configuration is supported on all generations of Intel AMT, and natively supported by the configuration software built into the Out-of-Band Management Module.
  • Cons: Only works on the corporate wired LAN.   The acquired certificate must be designated by the DHCP option 15 value of the environment.   In some cases, customers are unable to acquire a valid remote configuration certificate.
  • Why is this listed as "better"?  It is commonly used today and has proven successful overall.   Host Based Configuration has definite advantages.

Remote Pre-Shared Key (Better)

  • Pros: Supported by all versions of Intel AMT.   Does not require a matching DHCP option 15.   OEMs can prepare a system in advance.
  • Cons: Every system must be touched to initialize the pre-shared key value in the firmware.   Configuration can only occur on over a wired LAN connection.
  • Why is this listed as "better"?  Between configuration certificate and pre-shared key, the latter can be more tedious.  

USB 1-touch

  • Pros: No LAN Connection required.   Systems can be configured during staging or once deployed
  • Cons: Not all configuration settings can be applied, specifically those that require network communications such as TLS, Kerberos, 802.1x, etc.   Each system must be touched by inserting a USB key with valid setup.bin configuration file.   Only Intel AMT 4.1 and higher systems are supported
  • Why is this listed as "good"?  For a small demonstration or deployment environment, this model is perfect.   Managed Service Providers (MSPs) often use this approach.   For more information, review the Intel SCS 7.1 User Guide.


  • Pros: No LAN Connection required.   Works on any version of Intel AMT.
  • Cons: Requires physically touching every system, entering into the Management Engine BIOS eXtension (MEBx), and selecting the correct options.   Not all configuration settings are possible, similar to the constraints of USB 1-touch.   Not recommended beyond small demonstration or deployment scenarios.
  • Why is this model listed as "good"?  It's perfect for a demonstration environment.   It works without any external software

In general, the "Best" and "Better" options are most preferred for enterprise deployment situations.  

Concluding Thoughts

Before starting your Intel AMT deployment project, have a core understanding on how Intel AMT works, Environment Considerations, and Configuration Options.   As mentioned at the beginning, this article provides only a portion of the insights and know-how in being successful with Intel AMT.   If the number of options confuse - my apologies in advance.   The technology has evolved to work with many different platforms and environments... in fact, you may see it in embedded devices (i.e. digital displays, kiosks, medical carts), in workstations, entry level servers, and more.    As the evolution has occurred over the years, new options and configuration approaches got introduced.   This may help to further explain why certificate configuration options are available only on newer generations of Intel AMT.    Starting in 2012, some Intel AMT devices will have no wired LAN ports which makes the Host Based or Manual configuration approaches the only options (personally - I recommend using the Host Based Configuration approach).

The Symantec Management Platform has a long history in working with Intel AMT.  In addition to supporting what is shown below, the Symantec Management Platform framework provides flexibility both in how Intel AMT is configured and use of external tools as needed.   For example, even though PC Alarm Clock is shown without support in the chart below, it can be used as explained here.

I sincerely hope this information has been helpful.   If you have questions or requests for additional insights - please let me know.


The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries. 

0 Favorited
0 Files

Tags and Keywords

Related Entries and Links

No Related Resource entered.