802.1x is a network access control standard that some networks have enabled depending on whether they have 802.1x capable network equipment and also what is called an AAA or RADIUS Server to serve as a gatekeeper for which systems are allowed on to the network. The conundrum with AMT is in order to get Out of Band (OOB) access to a vPro system the network port will be closed unless what is called a supplicant will negotiate versus that RADIUS Server and have the port opened. As vPro will typically be leveraged when the system is powered off or when the OS is broken/unavailable, there needs to be a different mechanism to be able to open the port, so remote network access is possible and doesn't lock out the useful AMT functionality. 802.1x support is enabled in the firmware, however it is necessary to configure it in order to take advantage of it.


Earlier this week, a document was posted on the vPro Expert Centre - provides a really great introduction to 802.1x and all the associated details. I suggest going through that document as a precursor to the following blog posting as I won't be getting into 802.1x basics here. I will focus on the steps taken to implement what is the 1st AMT 802.1x enablement in a LANDesk environment. That document will have rightfully noted that LANDesk does not support 802.1x. Does that mean that you have hit a road block? - the answer is NO.


Just this past week, the steps I am about to describe were implemented and validated to work successfully in a production customer environment, for what can be considered the 1st AMT 802.1x implementation in a LANDesk environment...


Components Required:

  1. Microsoft WinRM 2.0 (both on vPro client on Server from which you will be executing a post provisioning script)
  2. Microsoft Active Directory
  3. Microsoft Enterprise Certificate Authority (unless you are using EAP-PEAP with MSCHAP v2)
  4. RADIUS Server(could be Microsoft IAS/NPS or Cisco ACS; in this case we used IAS - make sure it is setup to use AD based authentication)
  5. Intel Genscript tool
  6. Intel WS-MAN Translator (optional - was not used in this instance, but is generally recommended for volume deployment)


LANDesk Specific Steps Required:

  1. Latest version of LANDesk is recommended - LDMS 8.8 SP3
  2. vPro systems need to be successfully provisioned in non-TLS mode(TLS mode can also be accommodated, but a step is required thereafter to have certificates ignored as part of the 802.1x configuration; as long as you are willing to accommodate it, I would recommend provisioning in non-TLS mode for the purposes of this 802.1x solution). The reason you need to use non-TLS or circumvent TLS is that the certificates issued by the built-in LANDesk certificate authority don't have a notion of certificate revocation lists (CRL). It is technically possible to craft it in, but that would get quite complicated. Later on when WinRM is used to execute the script, the 1st thing it does when it observes a certificate is to see whether the certificate is still valid or whether it has been revoked. Since there is no CDP (CRL distribution point) field in a LANDesk issued certificate that check fails and the script will never execute. That is why you want to provision in non-TLS mode.
  3. Post provisioning step is required to be performed either in a non-802.1x environment (such as a staging area) or when the 802.1x authentication has already been negotiated(e.g. OS supplicant); otherwise this is a 'chicken and egg' scenario where the 802.1x credentials
    can't be placed on the vPro system because 802.1x is blocking it.


Post Provisioning Steps Required:

  1. Configure and generate 802.1x post-provisioning vbs script using the Intel Genscript tool
  2. Execute the vbs script either locally on the vPro client or from another system which has permissions and network connectivity to the provisioned vPro system:

    • If you are executing the script from a remote system, make sure you have Microsoft WinRM installed and properly configured on that remote system as well as on the vPro client. If you use the remote execution approach, it is more conducive for a 1:1 or limited number of systems.
    • If you are executing the script locally on the vPro client you need Microsoft WinRM installed and configured only on the vPro clients. You will also need to have the Intel WS-MAN Translator installed on a system on your network. The reason for that is that the AMT Architecture is set to receive provisioning configuration data from remote over the network through SOAP envelopes. Therefore the translator is used to reflect the configuration from local execution and 'trick' the Intel Management Engine to believe it is coming from remote. The reason you would use this local execution approach in the 1st place is that you could distribute that the script just like any software distribution package and execute it on volume.


Configuring Microsoft WinRM:

  1. Make sure you have WinRM version 2.0 (and not 1.1) - if you are using Windows 7 on clients or Windows Server 2008 on Servers it will already be embedded with the OS.
  2. The configuration steps you require on WinRM will allow a smooth execution of the post-provisioning script; they are:
    • winrm set winrm/config/client @{AllowUnencrypted = "True"}

    • winrm set winrm/config/client @{TrustedHosts = "*"}


Configuring and Generating the Post Provisioning Script:

  1. Most of the 'magic' takes place with configuring this post-provisioning script...
  2. You will need to use the Intel Genscript tool which has been used in past to introduce not natively support AMT features in the context of other management consoles as well.
  3. The high level steps you will be configuring in the script are:
    • Connection parameters to remote vPro system - in this case it will be http digest credentials over http connection over port 16992 as LANDesk doesn't have a notion of Kerberos.
    • Import root certificate so that any certificate that will be used thereafter can be trusted
    • Pointing to a certificate authority and certificate template to have 802.1x certificates generated on the fly for each vPro system that has the script executed against; alternatively you can point to a single already generated certificate
    • Create an 802.1x credential - this will be used to generate an AD account that will be used for authentication when connecting to the remote vPro system. This is not to be confused with the vbs level script connection that is mentioned 3 steps above which is not AD based.
    • Create a wired 802.1x profile in which you select the appropriate EAP protocol your RADIUS Server is using
  4. Execute the script with the following syntax: cscript 802.1x-script.vbs /host: hostname /domain:domainname  (you can also use /IP:ipaddress  the domainname is required, otherwise the script won't execute)
  5. I have attached a sample script that we have generated which you can use a reference point. It is specifically setup for running on a remote system and imports a certificate rather than points to a certificate template.
  6. A document that provides a step by step guide for configuring the script using Genscript will be made available by a fellow Intel colleague over the next couple of weeks. Stay tuned.


The other thing to mention is that this solution is in parallel to LANDesk and LANDesk LDMS will not be aware per-se. That should generally not cause an issue, but the solution would need to be maintained 'manually' if AD passwords are changed for example. Also, if there are any certificate revocations taking place, LANDesk will not be aware of them, so in general this is to be considered a standalone solution.