New articles for you to take a look at this week. As always, let me know if you have a best practice or known issue that you want to share or have investigated!

• Using international keyboards to create MEBx passwords via Setup and Configuration Service (SCS)

• What is the Authorized column in SCS?

• Do management workstations running the SMS console and SMS Add-on require patches as outlined in the documentation for the Intel(R) AMT Add-on for Microsoft SMS*?

The Brand Promise Validation team here at Intel came across an issue in the lab which many customers may also run into when they are trying to deploy AMT. The question was, how do I use two different ISVs to manage different aspects of my Enterprise configured AMT client fleet? Theoretically this isn't neccessarily a tough question. Based on how AMT was designed, so long as you have the same authentication and credentials setup between the different managment software, you should be able to access the AMT features. In practice, however, many management applications attempt to configure AMT in such a way that they have sole access by customizing the provisioning settings and then hide those settings away.

However, as I'm about to describe, with a little tweaking, you can force these applications to play nice together.

The main thing to remember anytime you are setting up AMT in enterprise mode is that the key to accessing AMT is having the correct certificates in place. For access that means having a Web Server based certificate template that will be used for TLS communication between the console and AMT. If you are also using PKI provisioning, you'll have to have a properly configured or purchased provisioning certificate in place (I won't be covering the details of PKI provisioning in this blog, but maybe in a future update). Lastly, for SMS and Altiris you'll also need a .pem certificate. Details on how to create a .pem certificate is included in both the Altiris help and Intel AMT Add-on for SMS documentation. A quick summary of a .PEM file certificate is taking each certificate in the chain starting at the top and concatinating those certificates into a single file. This file is used for secure TLS communication during SOL sessions.

The two management applicaitons we targetted for implementation was Altiris and SMS using the Intel AMT Add-on for SMS. The reason we targetted these apps is that we have inimate knowledge using these applications since they are used in our validation efforts and they both utilize the Intel SCS for provisioning.

Both Altiris and SMS systems should be in the same domain using the same certificate authority and have the same root certificate installed. While it is definately feasible that you could have the the two management applications in different child domains using wildcard certificates for authentication, this article doesn't cover that specific configuration.

I'm not going to go into the details of setting up Altiris and SMS or how to configure SCS for provisioning since it is assumed that if you are attempting to merge these ISVs so that they can manage AMT clients, then you should already know how to get the individual applications to work with AMT.

I started off by getting Altiris setup and configured using the built in SCS included in the OOB Management solution for Altiris. At this point I didn't have to do anything special in order to make sure that the SMS Add-on would work, I just setup Altiris as normal to manage AMT clients. Once setup, I verified that I could provision and manage my AMT clients.

Next step, on a different machine, I setup and configured SMS with the Intel AMT Add-on for SMS. I configured SMS to use it's own SQL server, however, there is no reason that you couldn't have it use the Altiris SQL server (setting up a separate instance) or a stand alone SQL server (again with a separate instance). For ease of configuration, however, I just used a separate SQL install on the same machine as SMS.

Once you have the SMSAMTUser_<sitecode> account created in active directory and have that account as well as whatever user accounts you want to use AMT via SMS added to the Intel(R) AMT groups (there are 3-5 of them depending on the version of the AMT Add-on you are using), you need to add the SMSAMTUser_<sidecode> to the Altiris SCS users list. On the Altiris system go to: View -> Configuration -> Solution Settings -> Platform Administration -> Out of Band Managment -> Provisioning -> Configuration Service Setings -> Users. Click the blue + to add a new user. Click the ... button. Select domain and type in the name query field SMSAMTUser and click Find. Select the SMSAMTUser_<sitecode> that is found in the results field and click OK. Under Role make sure Enterprise Administrator is selected. Click OK. This gives the service account for the Intel(r) AMT Add-on for SMS rights to view and modify the Altiris SCS.

On the SMS system, open up the Intel Add-on Settings dialogue box and configure it to use the Altiris Setup and Configuration Server. In order to find the URL that Altiris uses to connect to the SCS, On the Altiris machine, go to:

View -> Configuration -> Solution Settings -> Platform Administration -> Out of Band Managment -> Provisioning -> Configuration Service Setings -> Service Location.

If you have the Default URL set, you should have something like [/]<fqdn/AMTSCS. If you are using an alternative URL, copy that down. On the SMS machine, open up the Intel Add-on Settings and go to the Setup and Configuration tab. Select the Integrated Setup and Configuration radio button and type in the URL you copied down into the SCS Service URL box. Click the Set Profiles box and the AMT profiles that are setup in Altiris should pop up in a new window. Select the profiles you want to use in SMS (select all of them if you want all profiles to be able to be managed in SMS) and click OK. The list of supported profiles should now be populated with the profiles that are setup in Altiris.

Next step is to setup the .PEM certificate file that was used in Altiris for the Intel AMT Add-on for SMS. Copy the .PEM file used in Altiris to the SMS system. If you don't know where you .PEM file is located in Altiris, go to:

View -> Configuration -> Solution Settings -> Real-Time Console Infrastructure -> Configuration.

Click on the Intel(r) AMT Connection Settings tab. Under Redirection Security you should see a box next to the Trusted CA certifcate location. That box should have the path to the .PEM file. Once you have copied that file to your SMS system (doesn't matter where you put the .PEM file on your SMS box, so long as you remember where you put it) open up the Intel Add-on Settings dialogue and click on the Security tab. Check the Enable Intel(r) AMT secure Connection (TLS) box. In the CA Certificate Path put in the path to the location of the .PEM file that was copied onto the SMS system. Click Apply.

That is the basicis of what needs to be done. Once you have discovered the AMT clients in SMS and they are populated in the collection, right click on All Systems and go to All Tasks -> Intel(r) AMT Tasks -> Discover Systems. Now when you right click on an AMT system and go to All Tasks -> Intel(r) AMT Tasks you should see the list of AMT functions you can perform such as Asset Identification Information, Power Control Operations, etc.

In order to get SOL/IDE-R to work and System Defense to work, you'll need to go into the Intel(r) Add-on Settings in SMS again and setup the location of the ISO images that will be used for IDE-R and the System Defense file that will be used to filter packets using Circuit Breaker. Creating the System Defense file is covered in the Intel(r) AMT Add-on for SMS documentation and will not be explained in detail here. The repository for the ISO images needs to be a network share and can either reside locally on the SMS system (still mapped to the network share location) or can reside in a central repository. If you want both Altiris and SMS to use the same set of images just use the same network path to the ISO images for both applications.

That's it. In my environment I'm able to manage AMT machines with either management application. The only slight gotcha (and this is more a security feature of AMT) is that if one management application is currently managing a client (ex. using SoL) then the other is unable to break in and use the client. The gotcha part of this is that neither management application gives a clear indication that the system is currently in use by another management application, the attempt to manage just fails with an authentication error.

Here's the weekly update of issues posted to the Known Issues, Best Practices, and Workarounds wiki:

• Is an IDE-R recommended over a WAN?
• Can the Default provisionserver naming conventions be changed?
• The Intel(R) AMT Add-on for Microsoft* SMS is unable to communicate with the SCS over a standard HTTP connection
• Ctrl + P prompt missing when CMOS battery unplugged

Well, it probably won’t work if you stick it there, but the
truth is that there are a lot of certificates used in AMT, and knowing where to
put those certificates and their private keys can save a lot of hair pulling
down the line.

AMT Certificates

Let’s start with the AMT system itself.

TLS Certificate

If the SCS profile calls for TLS to be enabled then a
private key and certificate are generated at the SCS and then installed on the
Amt device as part of the provisioning process. This certificate and key are
then used in future communications between the SCS and the AMT device and the
Management Console and the AMT device. I’m going to use the SMS Add-on as an
example of the management console because it uses gSOAP libraries which have
addition certificate storage requirements.

802.1x Certificate

If the SCS profile calls for and 802.1x certificate then a
private key and certificate are generated at the SCS and installed on the AMT
device as part of the provisioning process. This certificate and key are used
to allow the AMT device to connect to an 802.1x protected network without the
host operating system being available.

Mutual Authentication Root Certificate (MTLS Root)

The MTLS root certificate is used by the AMT device to
validate the mutual authentication certificate provided by the SCS or
management console after provisioning has completed. (Assuming of course that
the SCS profile used for provisioning configures MTLS). This certificate is
installed during the provisioning process. Note only the certificate is
installed – there is no private key installed for this certificate.

h1. Remote Configuration

The remaining two certificates on the AMT device are used
for Remote Configuration. This feature is available in AMT 2.2, 2.6 and 3.0.
(Note that does not include 2.5).

Remote Configuration Root Certificate (RCFG Root)

Actually this is not a whole certificate. It’s just the
certificate thumbnail, referred to as a hash. The certificate hashes can come
from a couple of places:

·{font:'Times New Roman'}
The AMT systems come with default certificate
hashes from VeriSign, GoDaddy and Comodo.

·{font:'Times New Roman'}
Your OEM can place a certificate hash of your
choosing on to the AMT devices you buy as part of their manufacturing process.
E.g. if you have your own PKI and wish to use your own root certificate.

{font:Symbol}·{font:'Times New Roman'}


You can
manually enter the certificate hash into the MEBx screen.

The advantages and disadvantages of each of these methods
are best left for another discussion.

This certificate is used to validate the remote
configuration certificate provided to the AMT device by the SCS service that is
trying to provision the AMT device. The details of this validation are somewhat
complicated and also best left to another discussion.

Remote Configuration Self Signed Certificate

Finally the remote
configuration processes requires the AMT device to generated its own self
signed (i.e. there is no certificate authority involved – and hence no trust
established) certificate to serve as a TLS/SSL certificate in place of the Pre
Shared Key (PSK) that was used to protect provision in earlier version of AMT.
Both the certificate and the key are generated locally on the AMT system.

SCS Certificates

Once we get to the server side, certificates become more
interesting as we have to know which Windows certificate store to put the
certificate and private key.

The SCS requires four certificates.

SSL Certificate

The SCS service runs as a web service within IIS.
Connections to the service can be carried out by the SCS console or by an ISV
supplied UI. To secure this traffic the SCS service requires that these web
services be protected by TLS/SSL. The SSL certificate is the same type used to
secure other web servers like amazon.com or eBay.

This certificate is installed in the Windows certificate
store of the service account used to run IIS. If you use the IIS “Server
Certificate” this is a two step process. First the IIS server generates the
private key and a certificate request. The private key is stored in the IIS
service account key store, and the request is stored in a text file. The
certificate request is then sent to the CA who issues the certificate. The
wizard then installs the certificate and matches it up with the private key.

TLS Root

The TLS root certificate is the root certificate from the
certificate chain that issued the TLS certificates to the AMT devices. This may
or may not be the same as your MTLS Root, depending on how you issue your
certs. This certificate is used to validate the TLS certificate provided by the
AMT device when the SCS connects to the device to perform some function after
initial provisioning. This could be re-provisioning or one of the maintenance
tasks that the SCS performs – like setting the AMT system time.

There is no private key associated with this certificate.
The certificate should be stored in the “Trusted Root Certification
Authorities” folder of the SCS service accounts certificate store.

Mutual TLS Authentication Certificate

This certificate is used by the SCS to authenticate itself
to the AMT devices. Both the certificate and the private key should be stored
in the SCS service accounts “Personal” certificate store. The root certificate
of the chain must be installed on the AMT device during provisioning to allow
this authentication mechanism to work correctly.

Remote Configuration Certificate

This is the most interesting of the three SCS service
certificates. This is because the certificate needs to be in two certificate
stores – but the private key only needs to be in one. The SCS service presents
this certificate to the AMT device to start remote provisioning. As this is a
mutually authenticated TLS session, the SCS service must have access to the
private key. So the certificate and private key should be installed in the SCS
service accounts certificate store.

To configure SCS for remote configuration, a utility called
“loadcert.exe” is run. This utility lists the certificates in the local
computer store and you select the one you want the SCS service to use for
remote configuration. The utility then make a registry entry containing the
thumbnail of the certificate. The SCS service looks at this registry entry and
then looks up the selected certificate in the SCS service account certificate
store. Because the loadcert.exe utility reads from the local computer store,
the remote configuration certificate needs to be installed in there. But,
because it is only read by the utility to extract the thumbnail, the private
key does not have to be installed in the local computer store.

SMS (Management Console) Certificates

Certificates for the SMS Add-on are complicated by the use
of the gSOAP libraries. GSOAP is a cross platform, open source web services
development toolkit. Because it is cross platform it does not (obviously) use
the windows certificate store. Instead it uses a file format called PEM (from
the Privacy Enhanced Mail system). PEM files store certificates and keys as
base-64 encoded strings. This makes them easy to manipulate (with things like
notepad) and portable between systems. The following discussion assumes a 3
level PKI hierarchy, with a root CA, policy CA and an issuing CA. If there is
sufficient interest I can talk about PKI hierarchies on a separate thread.

As the SMS is also a windows program, it also needs its
certificates in the windows store.

h2. Mutual Authentication Certificate (MTLS)

If the AMT profile the SCS calls for mutual TLS, then the
management console needs to supply an MTLSS certificate. This certificate, and
its private key, needs to be installed in SMS Add-on Service account
certificate store. This allows the SMS Add-on service to access the key for
operations such as power management. Because
the windows certificate store can “walk certificate chains”, only the MTLS cert
needs to be installed. Windows will work out where to get the rest of the chain
from on its own.

This is not true for the PEM file. In order for the gSOAP
library to have access to the certificate chain, all the chain entries must be
placed in the file (in the right order).

TLS Root Certificate

When a connection to the AMT device is made, it presents its
TLS certificate. In order for the Management console to trust the certificate,
the root certificate the issued the AMT certificate must be installed in the
“Trusted Root Certification Authorities” folder in the SMS Add-on’s certificate
store. . Because the windows certificate
store can “walk certificate chains”, only the TLS root cert needs to be installed.

Again, this is not true for the PEM file. In order for the
gSOAP library to have access to the certificate chain, all the chain entries
must be placed in the file (in the right order).