Intel,Altiris Group

Configuring Intel AMT to Work with TLS encryption 

Dec 08, 2010 04:30 PM

If security of the out-of-band management session is important, the capability exists to configure Transport Layer Security (TLS) to encrypt all Intel AMT traffic between the console and target Intel vPro technology client.   As a general guidance, use TLS if encryption is used to secure other traffic or sessions within the target environment.   TLS will introduce some latency and overhead due to the session security, but the business requirements may necessitate this decision.

Configuring of TLS will require an internal Microsoft Certificate Authority for self signed certificates.   It will also require configuring the Altiris environment with the correct settings and certificate path information.  

There are a variety of certificates which can be used in conjunction with Intel AMT.   A TLS certificate for encryption of traffic is separate from a remote configuration certificate used for the initial setup and configuration of the platform.   Other certificates can be used within the environment which will be explained in a separate article.   The important factors to remember include who has the private key, who is aware of the certificate path for obtaining the public key, who is requesting the session, and so forth.

This article provides a number of insights to help guide the reader through the process.   More insights are available in the Altiris OOBMC Implementation Guide 7.0 SP3 MR1 and Altiris Real-Time Systems Manager 7.0 SP2 User Guide.

 

TLS and Intel AMT Overview

Once configured, Intel AMT is a network based service awaiting an authenticated and authorized request.   This effectively makes Intel AMT the “server” which is responding to requests from Altiris as the “client” from a security communications point of view.   With TLS introduced into the environment, each Intel AMT configured client is assigned a WebServer certificate with the unique FQDN of the client as part of the certificate placed into the client firmware.  

During the configuration process, the Altiris Out-of-Band (OOB) Site Service makes a WebServer certificate request to a Microsoft Certificate Authority within the environment.   The Altiris OOB Site Service provides a wrapper around the Intel Setup and Configuration Service (SCS) which is used for the purpose of applying and maintaining the configuration of Intel AMT.

The following diagram provides a summary:

As a precursor to using TLS with Intel AMT in the environment, usability tests should be completed in a non-TLS configuration to reduce the number of variables within the environment.   In addition, once TLS is enabled a higher latency can be expected due to the creation of a TLS session and associated tunneling of the packets.

 

Adding TLS to the Intel AMT Configuration

Stepping through the full Intel AMT configuration process is outside the scope of this article.   With Intel AMT already configured, the following changes to the configuration profile, resource synchronization, Intel AMT systems, and connection profiles will occur.   The following steps assume that a Microsoft Certificate Authority has already been installed and registered within the environment.   The Altiris OOB Site Service with Intel SCS will perform a lookup in the Microsoft Active Directory for valid certificate authorities.

Open the target configuration profile and select the TLS tab.   Select “Use TLS” and the default options for TLS Server Authentication will already be set.   Select the pencil icon for the target server if not already populated.   Select an appropriate Microsoft Certificate Server with a default WebServer certificate template.   The following image is a summary of the steps completed.

Click the OK button to save the configuration profile to the Altiris server.

In a default Altiris 7.x environment, any changes to the configuration profile will automatically be distributed to the target client systems.   If unsure whether this will happen, check that the Resource Synchronization settings are set to “Re-configure Intel AMT if assignment changes”, that the target profile is assigned to the target client domain, the refresh cycle is set to occur more frequently, and so forth.   See the following image.

A second option is to right click on target Intel AMT system and choose the “select profile” option.   This will result in the following screen.   Notice that the client is currently listed as configured with “myprofile” and a change will be made to the “TLS profile”

If verbose logging is enabled for the Altiris OOB Site Service, an entry will appear in the logs indicating the process summarized in the first diagram above.   As noted in the screenshot below, a certificate is being retrieved by Intel SCS on behalf of the target client.   This certificate is then applied to the target client (see the latest entry at the top stating “Adding TLS certificate” amidst the series of set commands)

To validate that the TLS configuration was successful to the target client, open a web browser session to the FQDN of the client using the URL https://FQDN:16993.   When presented with the logon screen, select the lock icon to view the certificate of the Intel AMT client as shown in the following example.

The above screen confirms that Intel AMT has been configured with a TLS WebServer certificate.   If desired, select the “Log On” button and provide the appropriate credentials.

Before moving to the next section, one final item is needed: copy of the root and any intermediate certificates also known as the certificate chain.   While viewing the certificate as shown in the previous screenshot, select the “Certification Path” tab.  Select and view the details of the root certificate.  Select the “Copy to File” button and save the certificate to a Base64 .cer format.

If an intermediate certificate also exists between the root and the issued certificate, copy this certificate to a file.  

If opened in notepad, the saved certificate file will look similar to the following

If intermediate certificates exist within your environment, copy the entire text between “Begin” and “End” statements and place in bottom to top order in a single file.   Save this file with a .PEM extension.   The PEM file will be used during redirection sessions (i.e. IDE Redirect or KVM remote control) to instruct the requesting service (i.e. the Altiris server) on the appropriate certificate chain of the target Intel AMT webserver certificate.   These redirection sessions utilize OpenSSL instead of the expected Microsoft SSL libraries used for Intel AMT power control, network filtering, or hardware inventory operations.   This why you may experience a successful Intel AMT power control only operation, yet experience a failure with a redirection operation.

 

Update the Connection Profile

With the Intel AMT client properly configured, the Altiris Connection Profiles must be updated to utilize TLS.   Open the desired connection profile and update the AMT protocol to support “Secure Mode”.  

Notice the statement “Specify if secure AMT redirection is required”.   Select the “Browse” button for Trusted CA certificate location.   Browse to a select the PEM file created previously.  

Once you save the connection profile and re-open, the “Last uploaded…” statement will appear.

If using Intel AMT 6.x systems for KVM remote control, the WSMAN protocol must also be updated with the same settings.   As shown in the following screenshot for the WSMAN protocol, “Secure Mode” is selected with port 664 and the PEM certificate file has been uploaded for the protocol.

The Altiris server is now ready to communicate over TLS to target Intel AMT systems.

 

Validate Connectivity via Real-Time System Manager

Open the Resource Manager of a target client system.   Select “View” followed by “Real-Time” to access the Real-Time Console.   For the target client and associated connection profiles, the supported protocols will appear with a status indicator.   Ensure that the connection profile with secure mode settings is selected.

In the example below, an HP 6930p laptop shows that WMI and AMT protocols are responding correctly.   The DASH protocol has an error which is benign for this situation.   DASH protocol is used for the KVM remote control which is not supported on Intel AMT 4.x within the HP 6930p system.

As a quick comparison, the following screenshot shows a Dell e6410 which includes Intel AMT 6.x and supports KVM remote control.   Notice that all three protocols have an OK status.

Additional operational tests will help to further confirm that the TLS communications are working within the environment.  

 

Troubleshooting Tips

If during your operational tests there are errors about the certificate or a redirection session fails, check to ensure the target client is still configured and responding by using browser based approach mentioned at the beginning of this article.  Secondly, ensure that all of the supported protocols match the desired communication protocols.   Boot redirection will require AMT whereas KVM remote control will require DASH.

If the following screenshots look familiar, this means the AMTredirection service is either not registered or is presently not running.   These errors will also occur if Intel AMT communications are not responding between the Altiris server and the target client.

The amtredirection service error may occur after a recent update to the Altiris OOB, PPA, RTSM, or related modules.  To fix the error perform the following items:

  • Run “amtredirectionservice.exe /Service” from the directory \Program Files\Altiris\Pluggable Protocols Agent to ensure the service is registered
  • Start the AMTredirection Windows Service.   This can be done via “net start amtredirectionservice.exe” command or via the Windows Services window.

In my own lab environment, I found that Intel AMT communications failed after forcing a stop and start of the AMTredirection service.   I chose to reboot the server.   Further investigation into why Intel AMT communications failed from the Altiris server to the clients may have revealed a better answer.   For example, for TLS communications over Intel AMT the FQDN of the target client must be resolvable to the correct IP address.   The requested FQDN will also be used to validate the certificate in the client firmware.   Checking to ensure the target client can be pinged by FQDN may be another troubleshooting step to consider.

Incidentally, after I rebooted my Altiris server I realized FQDN-to-IP resolution of the clients was indeed at fault.   After correcting this infrastructural error, all communications and functionalists were once again working correctly.

 

Concluding Thoughts

Encryption of the Intel AMT communications may be desirable based on business requirements.   As with any encryption or security setting, operational latencies should be expected.   Similarly, ensuring the functionality of the solution prior to applying the security settings will help to remove variables.

From an interoperability perspective, if Intel AMT was configured by Microsoft SCCM within your environment, this article along with a previously posted series (see http://www.symantec.com/connect/articles/part-1-configuring-ad-integration-and-kerberos-authentication-intel-vpro-technology) are the key ingredients needed to utilize Intel AMT in a multiple management console environment.

Additional insights can be obtained from the Symantec documentation, working with Symantec support, or posting back to this community.

 

The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

 

Statistics
0 Favorited
2 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Dec 15, 2010 04:30 PM

Yes.

From an interoperability standpoint - let SCCM continue to own\manage the vPro configuration.

Two key items to remember: SCCM communications to vPro require Kerberos and TLS. 

For the Kerberos aspect - getting ITMS setup to use Kerberos credentials - see http://www.symantec.com/connect/articles/part-3-configuring-ad-integration-and-kerberos-authentication-intel-vpro-technology

For the TLS aspect - Focus on the "Update Connection Profile" and latter half of this article for TLS support

If an environment will be totally migrated off of SCCM, it is best if the ITMS environment own the configuration.   This will require a reconfiguration of the firmware from SCCM to the Altiris environment.  

This will also allow you to drop the Kerberos and TLS requirements of the configuration - which may be preferrable from a communication, environmental structure, and other reasons.   The downside of no TLS or Kerberos is security will be lowered... but a simple question to ask here "Do you encrypt traffic on your network?".   In general - the answer is no.   Second question to ask - "How many systems to be managed are outside of the Active Directory environment?".   In general - this answer will vary but most environments do not have a 100% requirement\success of all managed clients residing within the Active Directory domain.

Related Entries and Links

No Related Resource entered.