Introduction
In recent months, interest in the Intel® vPro™ technology Remote Configuration option has raised a number of common questions. This posting provides a quick answer to some of the most common questions, and hopefully will provide an easy reference. For an overview of Remote Configuration, take a look at the following links\posts:
Provisioning, or Configuration, is the process of authenticating an Intel® vPro™ system into a target environment. The process occurs “out-of-band” from the operating system to ensure that unauthorized applications cannot take control of the powerful features of Intel® vPro™ technology. Without the provisioning or configuration process, the core management technology and associated usage models are not available. A common desire is to configure the technology without physically touching each system.
What is the core purpose of Remote Configuration?
In an enterprise mode configuration, three core requirements must be met to provision an Intel vPro client.
- Authentication of the Intel vPro firmware to the provisioning environment
- Defining of the configuration parameters, primarily via the provision profile
- Obtaining and Mapping unique identifiers - firmware UUID to the operating system FQDN
Remote Configuration accomplishes the first main step of authentication, similar to the previous (and still existing) approach of pre-shared keys (e.g. PID\PPS). The key difference is that Intel vPro clients capable of remote configuration can be configured WITHOUT touching the system. Remote Configuration utilizes an x.509 v3 certificate on the ProvisionServer with a matching root certificate hash in the Intel vPro firmware to establish a security trust for the purpose of enabling an initial encrypted configuration session.
What is the difference between Remote Configuration and pre-shared key?
Pre-shared keys are a defined key pair (e.g. PID\PPS) that was generated by the ProvisionServer and distributed to the clients. The distribution process requires logging into the Intel MEBx (e.g. the firmware interface), changing the default MEBx password, and entering a total of 40 alpha-numeric characters. This process can be done manually, via a setup.bin file (e.g. USB one-touch), or pre-loaded by a vendor. When the system starts up, the pre-shared keys are used to authenticate the firmware to the provisioning environment.
Instead of physically touching and modifying the system, as the name suggests – Remote Configuration enables a “hands-off” configuration. Whether pre-shared key or remote configuration, a successful provisioning process will generate a new pre-shared key set which is used for authenticating future reprovisioning and partial unprovisioning sessions. Performing a full unprovisioning will return the firmware to a remote configuration state.
What is a certificate thumbprint or certificate hash?
Every issued certificate has a unique 40 character identifier referred to as the
thumbprint. This identifier is a hash value unique that particular certificate. In the case of Intel vPro and Remote Certificate, the root certificate hash (aka thumbprint) is stored in the firmware with a matching root certificate known by the ProvisionServer. The actual provisioning certificate loaded is specific to that ProvisionServer (i.e. the leaf certificate)with a mapping up to the root certificate from the issuing certificate authority. Therefore, during the provisioning process the ProvisionServer receives all certificate hashes known by the client as part of the initial authentication to establish a security chain of trust. Each of the received certificate hashes is compared to the known root certificate.
What is the recommended sequence in client deployment to configuration of the Intel vPro technology?
Every production environment will have unique requirements and considerations. The following recommended steps are for reference, and have been validated as “best case” approach. Variances to individual environments will exist.
- Client system identity defined (e.g. FQDN defined, client joined to domain\forest, etc)
- Client management agent installed and registered (e.g. Microsoft, Altiris, LANDesk, HP Openview, or other client management solution within your environment)
- If the client management agent has any out-of-band discovery or other capabilities - enable those
- Method or sequence established to define the default provision profile and provisioning script. Each client management environment may have a unique approach. Intel provides reference tools and scripts - such as RCT.exe which will be addressed more below.
If following the core steps above, the Intel vPro client system will have been established in the environment and the configuration of the underlying management technology will occur more smoothly. There are supporting articles on this site (Intel vPro Expert Center),
Altiris Juice or other materials which address provisioning approaches, common troubleshooting techniques, and so forth.
Does Remote Configuration require the ProvisionServer DNS record?
Technically – no, neither does the pre-shared key provisioning approach. This is a recent change enabled by the Remote Configuration Tool available at
http://softwarecommunity.intel.com/articles/eng/3751.htm and also referenced in the following Altiris Juice article -
http://juice.altiris.com/article/3612/using-intels-rct-tool-restart-amt-hello-packets-enterprise-provisioning. Among the many functions of RCT.exe is the ability to send or restart hello packets to a specified address.
The ProvisionServer DNS record allows the Intel vPro system to discover the location of the provisioning service by resolving to the assigned IP address. The ProvisionServer DNS record is an Alias/CNAME record. For many environments this is sufficient. However, for complex environments wanting to direct when and where hello packets are sent, the RCT.exe utility may be preferred. The RCT.exe utility has more options\capabilities beyond starting\directing hello packets - this will be addressed in more detail in a future posting.
As indicated above, some client management agents have out-of-band discovery or related capabilities. One example is the Altiris out-of-band task agent, which can also initiate remote configuration sessions. However, this agent requires a ProvisionServer DNS record to be defined.
What is the reference to TLS-PKI, TLS-PSK and RCFG?
These are shorthand versions for Remote Configuration vs. Pre-shared key. TLS-PKI refers to “transport layer security public key infrastructure”, another name or indication of certificate based authentication. An additional abbreviation is PKI-CH, where the CH refers to certificate hashes. TLS-PSK refers to “transportation layer security pre-shared key”, another name for pre-shared key based authentication. RCFG refers to “remote configuration”.
To what value is the Intel MEBx password changed when using Remote Configuration?
If the MEBx password is still default (e.g. admin), it must be changed to a strong password as part of the provisioning process. If a password is not defined by the administrator, the password to which the MEBx is changed is located in the IntelAMT database, in the profiles table. This will require database administrative privileges to access.
If using the Intel SCS console, the General tab of the Provision Profile has an Advanced button. Within the Advanced settings, a custom MEBx password can be defined for the environment. Strong password requirements will apply for the new MEBx password – at least 8 characters, at least one number, at least one capital, at least one special character, etc.
What versions of Intel vPro support remote configuration?
Versions 2.2, 2.6, and 3.0 support remote configuration. They also support the pre-shared key authentication process. At this time, only the Intel MEBx v3.x will show the remote configuration options through the client interface.
How do I know if the incoming hello packets are pre-shared key or remote configuration?
There are a few ways to determine what type of provisioning is allowed. Within the Intel SCS provisioning console under the General tab is an option to enable Remote Configuration. If this option is disabled, remote configuration hello packets will be ignored.
If verbose logging is enabled on the General tab of the provisioning console, all messages will be shown in the provisioning logs. Version 2 incoming packets are pre-shared key based, and primarily contain the PID (e.g. provisioning identifier or index), the UUID of the system, and what version of Intel AMT. Version 3 incoming packets are remote configuration based. Their primary contents are all of the certificate hashes from the Intel vPro client system, along with the UUID of the system and what version of Intel AMT.
Does Remote Configuration require you to be a certificate expert?
No. However, if you have certificate expert in your corporation, they will have a greater appreciation and insight into what is occurring, how to obtain the certificates, and so forth.
What core items MUST be defined in the provisioning certificate?
Remote Configuration utilizes a Server Authentication Certificate, issued by an approved Root Certificate Authority. The thumbprint, or certificate hash, of the Root Certificate Authority is stored in the firmware of the Intel vPro client providing a list of “approved” certificate authorities. In addition, the following core properties must be set
- Certificate OU = Intel(R) Client Setup Certificate OR the Certificate OID set to 2.16.840.113741.1.2.3. These values specify the purpose of the certificate.
- Maximum encryption key size for the PKI of 2048 bits. Most environments will likely use 512 or 1024 bit certificates.
- The DNS domain suffix of the certificate must match the DHCP option 15 DNS suffix setting. Although certificates are issued to a server, a portion of the authentication process will be tied to the DNS suffix.
- Sufficient business details to request the certificate. Issuing of certificates requires establishing your identity with the certificate authority
Is DHCP option 15 required for Remote Configuration to work?
Technically – no. However, if the DNS suffix is not specified by DHCP option 15, then the DNS suffix must be entered into the MEBx under the PKI settings. The specified DNS suffix – whether received by DHCP option 15 or manually entered via the MEBx, is compared to the DNS suffix of the provisioning certificate as part of the authentication process.
DHCP option 15 defines the connection specific DNS suffix which may be separate from the primary DNS suffix and DNS suffix search list. Thus a company may have DHCP option 15 set to “xyzcompany.com”, with a provisioning certificate issued to “ProvisionServer.xyzcompany.com”, and able to provision a system with a primary DNS suffix of “location1.xyzcompany.com”. During the remote configuration authentication process, the DNS suffix of the provisioning certificate and the DHCP option 15 are matched among other validation steps.
Can an internal certificate authority be used for Remote Configuration?
Technically – yes. However, this will require the matching root certificate hash to be loaded on the target Intel vPro systems requiring some type of intervention or customization of the systems. Additional certificate hashes can be loaded in Intel AMT 3.x systems by using the USBfile.exe utility and setup.bin file. The following article makes reference to this capability -
http://communities.intel.com/docs/DOC-1210.
What resources or guidance are available for acquiring one of the core external certificates?
A few articles have been posted on the Intel vPro Expert Center from some of the “experts” who have stepped through the process. These steps have proven helpful to both certificate experts and those with minimal certificate awareness.
What if I have a non-public, non-registered, or internal .local domain? How do I validate my domain ownership with the issuing certificate authority
It is best to refer to your preferred external certificate authority as each may have different policies. The core challenge is that a certificate authority cannot issue a certificate until a
domain proof of ownership is established. This is inline with the role and expectations of the certificate authority, as they are acting in external and third party role to validate your domain. This situation commonly occurs for internal domains with a
.local suffix.
An external certificate authority will commonly have a form and associated process to establish domain proof of ownership. The form will require the requestor to include name of corporation, key managerial signature and contact information, submission of form with corporate letterhead, or other items as part of the domain proof of ownership.
What is the cost of an external certificate?
The cost will vary based on the provider of the certificate and the industry of your business. However, consider that a single certificate will provision all remote configuration capable systems within a DNS domain suffix without requiring a desk-side visit.
Additional certificate hashes can be added to the system?
Technically – yes. However, this is presently supported only by Intel AMT 3.x systems and requires some method to enter the 40 character certificate hash: manually, via customized setup.bin, service provided by manufacturer or distributor, etc. In addition, if the custom certificate hashes are not burned into the firmware at time of manufacturing, they reside in a non-persistent storage of the firmware. If a full unprovision is done on the client, the non-persistent store is erased whereas the base certificates in the persistent certificate hash store are retained.
The following image of the an Intel AMT 3.0 MEBx shows the persistent certificate hashes. This menu is accessed via the MEBx, selecting Intel AMT Configuration > Setup and Configuration > TLS-PKI. You can also enter custom root certificate hashes is so desired.
Additional certificate hashes can also be loaded into Intel AMT 3.x systems by using the USBfile.exe utility and setup.bin file. The following article makes reference to this capability - http://communities.intel.com/docs/DOC-1210.
To what certificate store must the remote configuration certificate be loaded?
The Local Computer certificate store is where the remote configuration certificate must be loaded with the associated private key of the certificate. The AMTconfig service logon account must have access to the Local Computer certificate store. The LoadCert.exe utility is used to complete the association process of the remote configuration certificate to the provisioning service.
Must the intermediary and root certificates be loaded on the ProvisionServer?
This is highly recommended, especially if the ProvisionServer is unable to connect to the Internet to validate the certificate chain. Each external certificate authority has individual instructions to obtain the intermediary and root certificates.
The thumbprint or certificate hash of the root certificate must match one of the certificate hashes on the Intel vPro client, which are sent in the hello packet. During the certificate import process, select “Automatically select the certificate store based on certificate type”. The Remote Configuration certificate will be placed in the Personal certificate store of the Local Computer.
What if the acquired certificate is configured incorrectly?
Most external certificate authorities provide a short time period to validate an issued certificate, allowing for a new certificate to be issued at no additional cost if any errors are found. Please refer to your select certificate provider.
How many remote configuration certificates can be associated to a ProvisionServer?
Currently only one certificate per instance of Intel SCS is supported. Future versions of Intel SCS are expected to support more than one remote configuration certificate.
Are wildcard certificates supported?
At this time (circa March 2008), the provisioning service does not support wildcard certificates although some versions of the Intel vPro firmware currently do. More information is available on page 67 of the Intel AMT SCS Installation and User Manual.