Set Up Intel AMT for Remote KVM

Mark Berry December 13, 2014

I want to be able to make out-of-band KVM connections to computers running Intel AMT 9 (vPro). I initially thought this would require the $99 VNC Viewer Plus from RealVNC, but it seems to work fine with the free UltraVNC Viewer in combination with the free Manageability Commander Tool.

The RealVNC approach requires that you set up TLS for the connection. The UltraVNC approach can work without that, but I prefer the connection to be encrypted anyway. The RealVNC site has some decent documentation on this but I wanted to add some pictures and some info about self-signed certificates.

Update 6 October 2016 You now have to use MeshCommander for remote KVM but you still need MDTK if you want to set up TLS. See more info at the end of the article.

First, before discussing self-signed certificates, I found that if the server has an SSL certificate from a trusted certification authority, e.g. for a a web site, all I had to do was set that as the TLS certificate using the Manageability Commander Tool. I did not have to install any certificates on the client as the server’s certificate is already from a trusted root.

AMT Certs 1

Set Up AMT with Self-Signed Certificates

I decided to use self-signed certificates so I could connect to machines that don’t have a certificate from a trusted root. Self-signed certificates are also good for 20 years, so they should require less maintenance than standard SSL certificates, which may expire every year or two.

The Manageability Commander Tool version 1.32 has some simple, built-in tools for creating and installing self-signed certificates.

Create a Root Certificate

  1. From the Manageability Commander Tool, connect to a server using your AMT user and password.
  2. On the Security tab, select Certificate & CRL Store. (It may take it a moment before the button is available.)
    AMT Certs 2
  3. In the Intel AMT Certificate Store dialog, on the Certificates tab, click New.
  4. In the New Certificate dialog, click New Root Certificate….
  5. Fill in the Common name and Organization name. Set the Hash to SHA256 since SHA1 is being deprecated. Do allow it to make this a trusted certificate.
    AMT Certs 3
  6. Click Generate. You’ll be prompted about installing an unknown root certificate. Confirm that prompt with Yes.
  7. Run Certificate Manager (certmgr.msc) and you should see the new certificate under both Personal and Trusted Root Certificates. That means any certificates signed by this root certificate will be trusted on this machine only. You can import the certificate into other machines to make it trusted there.
  8. In Certificate Manager, right-click on the certificate and click Export. Export the certificate with its private key to a secure location.

Set Up TLS on a Server

Now we need to issue a certificate signed by our new CA root for each machine we need to connect to.

  1. From the Manageability Commander Tool, connect to a server.
  2. On the Security tab, select Certificate & CRL Store.
  3. In the Intel AMT Certificate Store dialog, on the Certificates tab, click New.
  4. In the New Certificate dialog, the Issuer certificate should already show your new CA root, and the Certificate name should already be populated with the name you used to connect to the server. Fill in the Organization name, perhaps using the name of the company that owns the server. Change the Hash to SHA256 and the Key size to 2048.
    AMT Certs 4
  5. Click OK and the new certificate will be installed in the server for use with AMT:
    AMT Certs 5
  6. In the AMT Certificate Store dialog, click Close.
  7. Back in the main Manageability Commander window, you can see that the certificate has been installed on the server. Click the button next to Transport Layer Security (TLS).
    AMT Certs 6
  8. In the Edit TLS Settings dialog, check Use Transport Layer Security (TLS). Click the button next to Required.
    AMT Certs 7
  9. In the Network Security Certificate dialog, confirm that the selected certificate is the one you just created above. Click OK.
    AMT Certs 8
  10. In the Edit TLS Settings dialog, click OK to confirm that you now require TLS.
  11. After a moment, the main Manageability Commander window, you can see the server is now set up for TLS.
    AMT Certs 9
  12. Repeat these steps for each machine you want to connect to.

Connect with VNC

  1. From the Manageability Commander Tool, connect to a server. You’ll need to make the ports accessible through the remote firewall. Note that if you connect to an IP address but the certificate has a different name, you’ll see a warning about a name mismatch.
  2. On the Remote Control tab, click the button next to Remote Desktop Viewer. In the Remote Desktop Viewer dialog, elect the Viewer Type and, if necessary, supply the Viewer Path. I’m using UltraVNC Click OK.
    AMT Certs A
  3. On the Remote Control tab, click the button next to Remote Desktop Settings. Set State to Enabled and Redirection Port (16993/16995) to Enabled. Make sure Standard Port (5900) is Disabled; that’s a security risk.
    AMT Certs B
  4. In the Manageability Commander Tool main window, you should now see both Take Control and Launch Viewer buttons available. (If you have a connection warning—see step 1 above—the Take Control button will be grayed out.) The Remote Desktop Settings show that we will be connecting using redirection ports.
    AMT Certs C
  5. Click Launch Viewer to establish a KVM connection to the desktop.
    AMT Certs D
  6. Click Take Control to establish a connection for remote commands, disk redirection, etc.
    AMT Certs E

Testing

As a test, I shut down a server, then used the Manageability Terminal to power it back on.
AMT Certs F

I was able press Enter then F1 to get into the BIOS.
AMT Certs G

I was even able to get into the RAID setup.
AMT Certs H

And therein lies the benefit of out-of-band control:  if the server crashes or hangs, or even if Windows updates seem to be taking forever, sometimes you can get control of the machine and even fix the issue without having to go on-site.

Update 6 October 2016:  Remote KVM No Longer Working through MDTK

This past July, I was having trouble getting KVM to work and posted this thread in the Intel forum:

Remote KVM no longer working thorugh MDTK

There was no solution for that issue, just the suggestion to instead use MeshCommander for KVM. That actually works pretty well for the “Remote Desktop” functionality, but it doesn’t (yet) let you create and install TLS certificates, so you’ll still need use the Manageability Commander Tool (MDTK) for that as described above.



3 Comments

  1. Intel RSTe Confused about Disconnected Hard Drive | MCB Systems   |  April 18, 2016 at 2:23 pm

    […] I rebooted the server and used the out-of-band KVM feature of vPro to view the pre-boot RSTe screens. The first popup screen also offered the option of rebuilding to […]

  2. Brian A Piscitelli   |  October 05, 2016 at 11:26 pm

    I followed the step exactly but I can not get any of the VNC viewers to work using TLS. If I disable TLS the remote control will work to the 1 system.

    A 2nd system it prompts me to connect and I select yes and then I just get a blank screen. That same machine keeps giving me messages that IME Remote connection keeps connecting and disconnecting. I will have to dive into that further.

    Does the CN have to match DNS name of host? Do you have a DNS suffix or any kind of name resolution to include FQDN?

  3. Mark Berry   |  October 06, 2016 at 8:31 am

    Brian, sorry about that, I think I hit the same issue in July and didn’t think to update this article once I got a workaround, which is to use MeshCommander for the KVM functionality. I’ve added an update and the end of the article above. Post back whether that works for you.

    > Does the CN have to match DNS name of host? Do you have a DNS suffix or any kind of name resolution to include FQDN?

    It’s similar to a web server. If you want to connect over the Internet, the CN would need to match the public FQDN of the server, e.g. clientserver.remotewebaccess.com. However the server itself could have a completely different internal hostname, e.g. SERVER01.ourdomain.local. BTW in this scenario, you have to forward the vPro ports on the router to the server; I forward TCP 16992-16995.

    Several of the machines I want to manage are available to me over a LAN or VPN. For those, I just use their “real” name as defined in _internal_ DNS, e.g. DESKTOP01, and don’t even bother with a domain name, though if I did, I guess I’d be using DESKTOP01.ourdomain.local.

    Does that answer the question?

Leave a Reply





*