Native vPro Provisioning and Out-of-Band Control Through Agent Gateways

Out-of-band (OOB) management controls a machine below its operating system, through the management controller built into business-class hardware. It works when the machine is powered off, hung at boot, or running an unresponsive OS. Reaching that controller usually requires separate infrastructure: a dedicated management console such as Intel Endpoint Management Assistant (Intel EMA), a vendor cloud service, or a provisioning server on the network.

ET Ducky is an RMM, so its agent is already installed on each managed host. It reaches the controller through that agent rather than through separate infrastructure. The agent takes two roles in out-of-band work. On one machine it acts as a proxy gateway that discovers OOB controllers on its network and relays commands to them. On a machine whose Intel AMT is present but unconfigured, it configures AMT locally, so that host becomes manageable out-of-band with no added hardware. This post covers both: the gateway relay model, and the host-based activation stack that turns dormant vPro into a managed controller.

The agent as a proxy gateway

Any regular ET Ducky agent can serve as the OOB gateway for its network. An organization administrator enables the role in the agent's properties, and the agent begins gateway duties within one heartbeat. It runs the same gateway code as the dedicated Raspberry Pi appliance, authenticated with the agent's existing identity. No separate install, registration token, or hardware is required.

In the gateway role, the agent does two things on its local segment. It discovers management controllers, and it relays commands to them from the dashboard.

Discovery pings the local subnet and probes each responding host with a WS-Man identify request on the AMT ports (16992 plain, 16993 TLS) and the DASH port (623). A host is recorded as manageable only when it answers and the identify response carries the expected AMT or DASH signature. The signature check keeps unrelated services on those ports out of the results. A discovered controller is correlated to the agent installed on that host, so the two records line up.

The command path runs over a persistent cloud WebSocket. A power command (on, off, cycle, or graceful shutdown), an inventory read, or a console session is issued from the dashboard, pushed to the gateway, executed against the target controller, and the result is returned. Credentials for the target are not stored on the gateway. The cloud issues a short-lived relay token; the gateway exchanges it for the credential, holds the credential in memory for the duration of the command, and discards it afterward. A per-target lease prevents two gateways on one network from acting on the same device at once, and each command is attributed to an operator and recorded.

A gateway running on a managed host is available only while that host is powered on, so a dedicated appliance is the stronger choice where the managed machines themselves may be down. The agent-hosted gateway removes the setup cost where an always-on host is already present.

Discoverable is not operable

Discovery finds controllers. It does not make them controllable. A vPro laptop with AMT present but never configured answers enough of the probe to be recorded, but power and console commands stay disabled until AMT is provisioned and credentials exist. Most business-class machines ship in exactly this state: Dell OptiPlex and Latitude, Lenovo ThinkCentre and ThinkPad, HP EliteDesk and ProBook with vPro parts all carry Intel AMT in the chipset, unconfigured out of the box.

Provisioning is the step that closes that gap, and it is the part that normally needs a certificate, a trip to firmware, or a separate provisioning server. ET Ducky performs it from the host, in the agent, with none of those.

Host-based configuration over the Management Engine Interface

Intel AMT runs on the Management Engine (ME), a controller that is separate from the main CPU and reachable by the host operating system through a local interface called the Management Engine Interface (MEI), historically HECI. Intel's host-based configuration path allows a process running with local operating-system administrator rights to move AMT from the unconfigured state into Client Control Mode over that interface, without a provisioning certificate and without entering firmware setup.

ET Ducky implements this path in the agent itself. It does not use Intel Endpoint Management Assistant (Intel EMA) or a separate provisioning server; the configuration runs on the host being configured, from the agent already there. There is no bundled external tool and no separate binary to keep updated; the agent talks to the MEI directly through operating-system calls. The implementation is four layers, from the raw device up to the configuration call.

Layer 1: the MEI transport

The MEI is a message channel. A caller opens the device, connects to one ME client identified by a GUID, receives the negotiated maximum message length, and then exchanges one request and one response message per call. The two operating systems expose it differently.

Linux
  open("/dev/mei0")
  ioctl(IOCTL_MEI_CONNECT_CLIENT, { in: client_uuid[16] }
                              -> { out: max_msg_length, protocol_version })
  read() / write()

Windows
  SetupDi* enumerate GUID_DEVINTERFACE_HECI  {E2D1FF34-3458-49A9-88DA-8E6915CE9BE5}
  CreateFile(devicePath, OVERLAPPED)
  DeviceIoControl(IOCTL_TEEDRIVER_CONNECT_CLIENT, client_guid -> FW_CLIENT)
  overlapped ReadFile / WriteFile

The Windows side uses overlapped I/O because the port-forwarding tunnel in Layer 3 reads and writes the same handle at the same time. On Linux the ioctl request struct is a sixteen-byte union: the client UUID goes in, and the maximum message length and protocol version come back out over the same bytes.

Layer 2: AMTHI, the host interface command set

The AMT Host Interface (AMTHI, also called PTHI) is the command set that reports firmware state. The agent connects to the AMTHI client and uses it to confirm the machine is a real AMT device, to read its provisioning state and control mode before acting, and to verify the control mode afterward. The message framing is a twelve-byte header followed by the payload.

request  header (12 bytes, little-endian)
  u8  major = 1
  u8  minor = 1
  u16 reserved = 0
  u32 command            (OR'd with 0x04000000)
  u32 length
response header
  same 12 bytes, response bit 0x00800000 set in command
  u32 status             (0 = success)
  data...

commands used
  17   GetProvisioningState
  107  GetControlMode        0 none, 1 client, 2 admin
  0x67 GetLocalSystemAccount

Layer 3: the local management tunnel

The configuration call in Layer 4 is a WS-Man request, which is HTTP. Before AMT is provisioned there is no network path to its WS-Man service; the only route to it is over the MEI. Intel's Local Manageability Service normally bridges that gap by forwarding local TCP ports 16992 and 16993 to the ME. ET Ducky does not depend on that service being installed. It connects to the ME's LME client and speaks the same port-forwarding protocol the service uses, binding those ports on the loopback interface itself.

The protocol is Intel's AMT Port Forwarding (APF), the same channel model as SSH port forwarding. The ME asks the host to forward a port; the host binds it on 127.0.0.1; a local connection to that port opens an APF channel to the ME, and bytes are relayed in both directions with per-channel flow control. The result is a working http://127.0.0.1:16992/wsman endpoint backed by the firmware, with nothing installed and nothing bound to a routable address.

Layer 4: the setup call

With the loopback endpoint up, provisioning to Client Control Mode is one WS-Man call to the IPS_HostBasedSetupService class. For client mode without a certificate it takes two parameters: the password encryption type, and the new admin password as a digest.

read  IPS_HostBasedSetupService
        CurrentControlMode   must be 0 (unprovisioned)
        AllowedControlModes  must include Client

call  Setup(
        NetAdminPassEncryptionType = 2,   HTTP Digest MD5
        NetworkAdminPassword       = MD5("admin:" + realm + ":" + password)
      )
        return 0 = success

The agent generates the admin password itself, never displays it, and stores it encrypted in the platform. It is never chosen by an operator or returned to the browser. After the call returns success, the agent reads the control mode back through AMTHI to confirm the machine is now in Client Control Mode.

Authenticating the local call

The WS-Man calls on the loopback are still HTTP, so they carry a digest handshake. Before AMT is provisioned there is no admin account to authenticate with, so the credentials are retrieved from the firmware. AMTHI command 0x67 (GetLocalSystemAccount) returns the account the ME issues for local setup: the username $$OsAdmin and a firmware-generated random password. The agent reads that account and uses it for the digest authentication on the preflight read and the setup call. This is the account Intel's host-based flow is designed around; it is not a fixed default.

Control modes and the consent code

Host-based configuration produces Client Control Mode. Client mode covers remote power, serial-over-LAN, and KVM, which is what most remote remediation and reimaging needs. It carries one constraint set by Intel: a KVM or redirection session prompts for a six-digit consent code shown on the target's own screen, entered when the session starts. Removing that prompt requires Admin Control Mode, which AMT only allows through a provisioning certificate or a manual firmware setup. That is a separate, advanced path and is not what host-based activation produces.

The serial console

Once a device is provisioned, it exposes a text serial console over AMT Serial-over-LAN (SOL). SOL is part of the AMT redirection protocol on ports 16994 and 16995. The gateway opens a redirection session to the controller, authenticates, starts SOL, and relays the framed serial bytes to the dashboard, where they render in a terminal. The redirection client is part of the gateway code, so the console needs no external tool on either end.

Because SOL is a real out-of-band channel, it runs independently of the operating system. It reaches POST output, the firmware setup menu, boot device selection, and text-mode recovery on a host whose OS is not running. It is a text channel; a graphical view of a running desktop is the KVM path, which under Client Control Mode carries the consent-code prompt described above.

Packaging and sources

The whole stack is operating-system calls and in-process protocol code. There is no native binary to ship, restore, or version; the transport is P/Invoke to the platform libraries, the tunnel and the redirection client are managed code, and the same assembly runs in the dedicated gateway and in the agent-hosted gateway.

The protocol constants are taken from published sources rather than inferred. The MEI transport and the AMTHI framing follow the Linux kernel MEI sample and Intel's open Local Management Service and MEI transport library. The port-forwarding tunnel follows the APF implementation in MeshCentral's agent, which is Apache-2.0. The setup call follows Intel's AMT SDK class reference. The client GUIDs, the connect IOCTL, and the message layouts are copied from those references and pinned in the code, not written from memory.

What a technician sees

The engineering above surfaces as a short workflow. Dormant vPro machines appear under Network Discovery, in the OOB candidates view, read from what the installed agents already report with no network scan. An operator clicks Provision on a row; the agent runs the stack on that host and reports the result inline. On success the machine moves into the Out-of-Band tab and is managed through the gateway like any other AMT device, with power, inventory, and a serial console available on the row.

Setup, eligibility, and the discovery views are described in the Out-of-Band Management and Network Discovery documentation.