This is a great document I stole from my coworker, Gareth Bevan. He really knows his stuff regarding AMT and Infrastructure services. Clicking on a drawing enlarges it so you can see it better. Reply with questions if you want more info.
Big Dave
This document covers the following IT components:
Figure 1 shows all of the components needed to deploy AMT.
Figure 1: AMT Components (Click figure to enlarge)
The vPro platform allows a management console to control certain aspects of the device, such as power control, system defense and down the wire inventory. In order to be manageable, the device must become know to the management console. The process by which this occurs is called provisioning.
Data for this document was gathered using the following equipment:
During AMT provisioning the AMT ME acts as the server and the management console (which can purchased from various ISVs) acts as the client.
Figure 2: AMT Client Server Architecture
This somewhat counter intuitive relationship comes up again and again when integrating AMT into the environment and should be remembered.
Figure 3 Provisioning Flow
Table 1 Hello Packet Back Off
Figure 4 Hello Packet Back Off
Figure 5: DHCP Interaction Sequence
Table 2: DHCP Discover Options
If the firmware is preconfigured with the hostname, then the host name option is also set.
ToDo:
IP Stack Mas
Describe IP stack masking
Power up w/OS
Power up w/o OS
If the provisioning server IP address was not entered during the AMT ME setup process, then the AMT ME makes a DNS request for the name "ProvisionServer". If the requested name cannot be resolved by the DNS server, then a second request is made for "ProvisionServer.DomainName". AMT expects to either find the IP address of the provision server in this way, or by having it set explicitly in the AMT ME configuration process.
Once the IP address of the provisioning server has been resolved, the AMT ME sends a "Hello" packet to the provisioning server, which then to the AMT ME and begins the provision process.
Figure 6 Certificate work flow
The certificate issued is a regular SSL or web server type certificate. The management console acts as the web client and the AMT ME acts as the web server when the management console "manages" the AMT device. With the exception of the very first "hello" message, all communication is initiated by the management console. See Figure 4.
Figure 7 AMT Client/Server relationship
In order to be able to connect to the AMT device via SSL, the name in the AMT device has to match the name in the SSL certificate. When the system is first provisioned the FQDN name in the certificate is set to the same value as the DHCP option 81 value (see AMT Interaction with DHCP). The UUID of the AMT device is also included in the certificate. Example values are shown below.
CN = fmamt2poc-42.dtedev2.addev.intel.com
CN = Device (UUID: DA3EEC5D-C27A-11DB-BBDA-717DBE360018)
O = Intel® Active Management Technology
The certificate order in the MTLS PEM file is:
Figure 8 CRL Filtering
Certificates should be revoked under the following circumstances:
AD integration allows the management console to push AD user principles to the AMT device, which then uses Kerberos to authenticate the support users. In order to participate in the Kerberos trust domain, the AMT device must itself be a domain member. This is accomplished via the AD schema expansion. The expansion allows the AMT device to be its own entity in the Active Directory. Back inks are provided to connect the AMT device to the Windows machine account.
Once the AMT device is a domain member then authorized domain users manage the AMT devices as shown in Figure 7.
Figure 9 AMT / AD Integration
Big Dave
Overview
This document describes the interaction of Intel Active Management Technology (AMT) with a corporations Information Technology infrastructure. As all companies are different, and so are their IT deployments, this documents concentrates on what information Intel AMT technology exchanges with IT standard infrastructure and how this information is used. This will give IT professionals at various companies the knowledge they need to successfully integrate Intel AMT into their environments.This document covers the following IT components:
- Dynamic Host Control Protocol (DHCP)
- Domain Naming System (DNS)
- Public Key Infrastructure (PKI)
- Active Directory (AD)
Figure 1 shows all of the components needed to deploy AMT.
Figure 1: AMT Components (Click figure to enlarge)
The vPro platform allows a management console to control certain aspects of the device, such as power control, system defense and down the wire inventory. In order to be manageable, the device must become know to the management console. The process by which this occurs is called provisioning.
Data for this document was gathered using the following equipment:
| Item | Version |
| vPro machine | HP 7700 slime line |
| BIOS | 2.05 and 2.09 |
| AMT ME BIOS extension | 2.4..0000 |
| AMT Enabled Firmware | 2.1.3.031 |
| |
|
AMT Provisioning
An AMT device must be provisioned before it can be managed. The sequence of steps (described in more detail in later sections) is as follows: (todo: add timing of AMT messages)- 1. The Amt device is configured with
- a. Hostname
- b. Domain name
- c. Address of the provisioning server
- 2. AMT device acquires an IP address lease from the DHCP server
- 3. The DHCP server registers the AMT device name in DNS
- 4. The AMT device sends a "hello" packet to the provisioning server
- 5. The provisioning server looks up the FQDN of the host in DNS (how this is done varies by vendor)
- 6. The provisioning server requests a TLS certificate from the CA for the AMT device
- 7. The provisioning server loads this certificate, together with the rest of the management profile on to the AMT device.
During AMT provisioning the AMT ME acts as the server and the management console (which can purchased from various ISVs) acts as the client.
Figure 2: AMT Client Server Architecture
This somewhat counter intuitive relationship comes up again and again when integrating AMT into the environment and should be remembered.
Provisioning Message Flow
The AMT device initiates the AMT provisioning process (see Figure 3). Based on the configuration information in the BIOS of the device the AMT device obtains n IP address from the DHCP server, which in turn registers the device in DNS. AMT then send sends a "hello" packet to the provisioning server. On receipt of this packet the provisioning server begins the provisioning process. First the FQDN of the device is obtained. In Figure 3 below this is done utilizing DNS. Vendor solutions differ on how exactly this process is performed. Once the FQDN has been obtained the provisioning server requests a certificate with that name from the CA. Once the certificate has been created, the provisioning server pushes down the profile information (including the cert) to the AMT Device.Figure 3 Provisioning Flow
Hello Packet Back Off
If the initial "hello" packet does not make it to the provisioning server, the AMT device will retry as shown in Figure 4. For the first five minutes the AMT device sends the "hello" packet every minute. For the subsequent fifty minutes, the packet is resent every 10 minutes. Finally the AMT device backs off to send the packet every hour for the next 5 hours. After this point he AMT device gives up.Table 1 Hello Packet Back Off
| Time between packets | Number of attempts |
| 1 minute | 5 |
| 10 minutes | 5 |
| 1 hour | 5 |
Figure 4 Hello Packet Back Off
DHCP
AMT uses DHCP to auto configure the AMT Management Engine (ME) IP stack prior to provisioning.AMT Interaction with DHCP
The AMT ME behaves as a standard DHCP client. The interaction between be AMT ME and the DHCP server can be seen below.AMT and DHCP interaction sequence
The AMT ME follows the standard DHCP message exchange pattern as shown in Figure 2.Figure 5: DHCP Interaction Sequence
DHCP DISCOVER
During the DHCP discover phase, the AMT device sends a request to the network for a DHCP server. The following table lists the options passed from the AMT ME during the DISCOVER phase.Table 2: DHCP Discover Options
| DHCP Option | Name | Value (Decimal) |
| Parameter-Request-List | Domain Name Server | 6 |
| |
Router | 3 |
| |
Subnet Mask | 1 |
| |
Domain Name | 15 |
| |
TFTP Server | 66 |
| |
Boot file Name | 67 |
| |
Boot File Size | 13 |
| |
NetBIOS over TCP/IP Name Server | 44 |
If the firmware is preconfigured with the hostname, then the host name option is also set.
DHCP OFFER
The DHCP server then returns the requested options to the AMT ME. Depending on how the provisioning server is entered into the AMT ME during setup, the Domain Name is used by the AMT ME when attempting to create the Fully Qualified Domain Name (FQDN) of the provision server. The remainder of the options are used to complete the DHCP request.DHCP REQUEST
The AMT ME next makes a REQUEST for the IP address offered by the DHCP server. Along with the previously mentioned options, the DHCP request also contains a request for the FQDN (option 81). The form of the FQDN will be either the hostname concatenated with the domain name returned by the DHCP OFFER, or the FQDN of the AMT device as entered into the AMT ME during setup. Note that the FQDN can also be entered into the AMT ME buy an agent running on the operating system of the AMT client, or by the provisioning server. This means that the FQDN requested may not be in the domain specified in the DHCP OFFER message.DHCP ACK
The DHCP server then reconfirms the information set to the AMT ME in the REQUEST and OFFER messages.DHCP Interaction with a host Operating System
The above interaction describes the behavior of the AMT device before the host O/S boots up. It is probable that the host O/S will also interact with DHCP. It should be noted that the AMT ME and the Host O/S share the IP stack. That is, there is only one IP address allocated to the AMT ME / O/S pair by the DHCP server.ToDo:
IP Stack Mas
Describe IP stack masking
Power up w/OS
Power up w/o OS
DNS
The AMT ME does not update DNS. Instead it uses DHCP option 81 (see DHCP REQUEST above) to update DNS with it hostname. The first use of DNS by the AMT ME is an attempt to find the provisioning server.If the provisioning server IP address was not entered during the AMT ME setup process, then the AMT ME makes a DNS request for the name "ProvisionServer". If the requested name cannot be resolved by the DNS server, then a second request is made for "ProvisionServer.DomainName". AMT expects to either find the IP address of the provision server in this way, or by having it set explicitly in the AMT ME configuration process.
Once the IP address of the provisioning server has been resolved, the AMT ME sends a "Hello" packet to the provisioning server, which then to the AMT ME and begins the provision process.
PKI
Why AMT uses PKI
AMT uses SSL server certificates to encrypt traffic between the provisioning server and the AMT ME. These certificates are requested by the provisioning server when the AMT device is first provisioned (see Figure 3). The provisioning server requests the certificate from the pre-configured Certificate Authority (CA). The service that runs the AMTConfig service on the provisioning server will require enrollment permissions for the certificate template on the CA.Figure 6 Certificate work flow
The certificate issued is a regular SSL or web server type certificate. The management console acts as the web client and the AMT ME acts as the web server when the management console "manages" the AMT device. With the exception of the very first "hello" message, all communication is initiated by the management console. See Figure 4.
Figure 7 AMT Client/Server relationship
In order to be able to connect to the AMT device via SSL, the name in the AMT device has to match the name in the SSL certificate. When the system is first provisioned the FQDN name in the certificate is set to the same value as the DHCP option 81 value (see AMT Interaction with DHCP). The UUID of the AMT device is also included in the certificate. Example values are shown below.
CN = fmamt2poc-42.dtedev2.addev.intel.com
CN = Device (UUID: DA3EEC5D-C27A-11DB-BBDA-717DBE360018)
O = Intel® Active Management Technology
PKI Trust
In order for various PKI enabled features to work properly, trust must be established at various points. The following sections describe how this is done for various use cases.SOL / IDE-R redirection
In order for the AMT redirection features (SOL and IDE-R) to be used, the certificate PEM file must be installed on the management console. The order of the certificates in the PEM file is important. The issuing CA comes first, followed by its signing CA and ending with the root of trust for that certificate chain. These certificates are not read from the windows certificate store. The PEM file must be included.Mutual TLS
The AMT ME can be configured to require the management console to produce a client authentication certificate for management operations. This allows the AMT ME to authenticate the management console. A special type of certificate is used for this purpose. The certificate must- be issued by a CA in the PEM file trust chain
- contain the client authentication OID (1.3.6.1.5.5.7.3.2)
- contain the AMT OID (2.16.840.1.113741.1.2.1)
The certificate order in the MTLS PEM file is:
- 1. PFX file
- 2. Issuing CA certificate
- 3. Root CA certificate
CRL Checking
AMT can also be configured to check CRLs. However due to the scarcity of space on the AMT device, the CRL checking is actually done by the management console. The serial numbers of relevant revoked certificates are then pushed down to the AMT ME in a proprietary format. See Figure 5 CRL Filtering.Figure 8 CRL Filtering
Certificate Revocation
AMT device certificates are not revoked by the management console.Certificates should be revoked under the following circumstances:
- When the certificate is replaced using "Maintenance Polices"
- When an AMT device is re-provisioned
- When a certificate is request during provisioning, but provisioning fails for some reason
Active Directory
Integration with Active Directory (AD) is currently optional for vPro systems. Integration with AD enables use of AD user accounts to manage the AMT device. Without AD integration a set of user id and passwords are created by the management console to allow support users to log on to the AMT device to perform maintenance.AD integration allows the management console to push AD user principles to the AMT device, which then uses Kerberos to authenticate the support users. In order to participate in the Kerberos trust domain, the AMT device must itself be a domain member. This is accomplished via the AD schema expansion. The expansion allows the AMT device to be its own entity in the Active Directory. Back inks are provided to connect the AMT device to the Windows machine account.
Creating the AMT ME account in AD
The machine account is created in the domain by the management console when the AMT device is provisioned. The service account which runs the management console must have sufficient permissions in the AD to allow this.Once the AMT device is a domain member then authorized domain users manage the AMT devices as shown in Figure 7.
Figure 9 AMT / AD Integration