Hi again!
In this post of the software series, we'll review the Local Manageability Service (or LMS). The LMS could have had his own dedicated post, but it is hard to write about LMS without talking about a driver called Intel MEI or HECI -- the origins of LMS are tightly tied with HECI and local access methods, so we will cover them together.
If you remember the first post in the series, we wrote that most of the operation of Intel AMT is/can be done remotely without the need for software: "
But some special features (like agent presence, local user notification etc) require local access to Intel AMT, and the software provided with it enables this access.
The most common way of communicating with a hardware device is via a device driver. This is software that opens to the Operating System the interface to the hardware devices of a system, translating Operating System commands to the specialized protocol and communication type required by the hardware.
Intel AMT technologies hardware devices have a driver, which carries all dialogues between the local operating system and this planar PCI device -- this driver is called the Intel Manageability Engine Interface (Intel MEI), formerly known as the HECI driver (for Host Embedded Controller Interface).
However, the hardware protocol is very specialized and limited, and writing agents or software to speak with AMT over this protocol would not only be cumbersome, but would require from our ISVs to learn yet another interface.
The best solution to this problem is to open, for local access, the same interface which is used for remote access: The HTTP (through SOAP or Ws-Manageability) protocol described in the Intel AMT SDK. Doing that gives us the following advantages:
- Unified protocols for local and remote commands
- Consistent settings for local and remote
- Unified authentication
- As the remote protocol is HTTP based, this gives us the same level of security we have on remote on the local communications (Kerberos/Digest authentication, TLS cryptography...).
Enter the LMS.
Most Operating Systems will not route local communications externally. That is, when network packets are destined to an addresses in the same host, the Operating System will create the connection within the OS, without trace of it in the external LAN interfaces.
When an application wants to send HTTP requests to Intel AMT from the OS, its counterpart to receive these requests within the OS is the Local Manageability Service. The LMS is a Windows Service that listens to communications to Intel AMT ports (16992 and 16993) and forward them (enveloped in Intel MEI messages) to the Intel AMT HW Device.
The great thing is that the messages reach Intel AMT as they are, and the control over traffic and all the other network or security mechanisms are performed centrally by Intel AMT.
Intel AMT on local will present a new level of protection: Only the relevant network interfaces are available, all the rest are blocked to prevent malicious or erroneous use.
The info in the table below was extracted from the Active Platform Management Demystified book, and it enumerates the interfaces open in local and the blocked ones (note: it also varies a little bit between projects):
In the next blog post, we'll wrap up the relationship between all Intel AMT software, and then prepare for the differences in the next Intel AMT version, version 6.0.
See you there!
In this post of the software series, we'll review the Local Manageability Service (or LMS). The LMS could have had his own dedicated post, but it is hard to write about LMS without talking about a driver called Intel MEI or HECI -- the origins of LMS are tightly tied with HECI and local access methods, so we will cover them together.
If you remember the first post in the series, we wrote that most of the operation of Intel AMT is/can be done remotely without the need for software: "
Intel AMT is basically a hardware/firmware solution where everything happens on the insides of the computer in hardware and embedded software. The main interface is the network card - you control Intel AMT remotely".But some special features (like agent presence, local user notification etc) require local access to Intel AMT, and the software provided with it enables this access.
The most common way of communicating with a hardware device is via a device driver. This is software that opens to the Operating System the interface to the hardware devices of a system, translating Operating System commands to the specialized protocol and communication type required by the hardware.
Intel AMT technologies hardware devices have a driver, which carries all dialogues between the local operating system and this planar PCI device -- this driver is called the Intel Manageability Engine Interface (Intel MEI), formerly known as the HECI driver (for Host Embedded Controller Interface).
However, the hardware protocol is very specialized and limited, and writing agents or software to speak with AMT over this protocol would not only be cumbersome, but would require from our ISVs to learn yet another interface.
The best solution to this problem is to open, for local access, the same interface which is used for remote access: The HTTP (through SOAP or Ws-Manageability) protocol described in the Intel AMT SDK. Doing that gives us the following advantages:
- Unified protocols for local and remote commands
- Consistent settings for local and remote
- Unified authentication
- As the remote protocol is HTTP based, this gives us the same level of security we have on remote on the local communications (Kerberos/Digest authentication, TLS cryptography...).
Enter the LMS.
Most Operating Systems will not route local communications externally. That is, when network packets are destined to an addresses in the same host, the Operating System will create the connection within the OS, without trace of it in the external LAN interfaces.
When an application wants to send HTTP requests to Intel AMT from the OS, its counterpart to receive these requests within the OS is the Local Manageability Service. The LMS is a Windows Service that listens to communications to Intel AMT ports (16992 and 16993) and forward them (enveloped in Intel MEI messages) to the Intel AMT HW Device.
The great thing is that the messages reach Intel AMT as they are, and the control over traffic and all the other network or security mechanisms are performed centrally by Intel AMT.
Intel AMT on local will present a new level of protection: Only the relevant network interfaces are available, all the rest are blocked to prevent malicious or erroneous use.
The info in the table below was extracted from the Active Platform Management Demystified book, and it enumerates the interfaces open in local and the blocked ones (note: it also varies a little bit between projects):
| Interface | Local | Remote |
| General Information | Available | Available |
| 3rd Party Data Storage | Available | Available |
| Event Log Reader | Available | Available |
| Firmware Update | Available | Available |
| User Access Control | Available | Available |
| Local Agent Presence | Available | Blocked |
| Endpoint Access Control | Available | Blocked |
| Local User Notification | Available | Blocked |
| Other Interfaces from Intel AMT SDK | Blocked | Available |
In the next blog post, we'll wrap up the relationship between all Intel AMT software, and then prepare for the differences in the next Intel AMT version, version 6.0.
See you there!
Articles in the Intel® AMT software series:
- The software bundled with Intel AMT
- The notification area icon - understanding the pop-up
- Configuring the notification area icon & app
- More configurations (disabling) of the Intel AMT icon
- Detailed information to the user with the User Notification Service
- How the UNS works
- UNS Error Messages and how to fix them
- Newfangled Intel Management and Security Status
- Intel Management and Security Status (IMSS), advanced configurations
- Intel AMT software: LMS, HECI, MEI... why do I need those?
- Wrapping all Intel AMT software together