I work as IS Manager for a fairly small company that just acquired 20 computers - HP rp5800 models with VPro technology for easy and secure management of the same. Enabling AMT features in the bios was a no-brainer and connecting to the boxes via Commander and VNC was a breeze, too.
The problems started when we decided to use Self signed Certificates for both client and server authentication - TLS. We couldn't find ANY recent documnetation on how to actually do this on our platform:
Intel Management Engine BIOS Ext v7.0.0.0054
Intel ME v18.104.22.1685
MDTK 7.0.11340.2 (Commander, Director, Outpost)
The whole VPro/TLS implementation process is very confusing to us. We are in a workgroup environmnet, NO domain, NO Active Directory. We've tried everything we could think of, and all the steps worked by themselves, but in the end we could not connect the "dots". IE creating self signed cert. worked, copying the hash into the BIOS worked, but the authentication failed :-(
We have a few basic questions with regards to VPro, and maybe a simple flow chart would help to guide is in the right way. We would like to use static IP addresses in the BIOS and in the operating system, as well. Is it possible to do this, because some documents call for DHCP and option 15 (domain name) populated.
There is zero documentation on self signed certificates and how to use them for the latest 7.x environment. Do we have to use "paid" certificates from third party CA or can we use our "self signed"? If self signed cert work how do we create them and install them properly?
If we don't use a DHCP server , does it mean we can't use remote configuration, therefore USB key is the only option to enetr settings into the BIOS?
We have installed a dedicated 2003 server with DHCP with option 15, it works fine, as far as DHCP goes. We also installed a the Certificate Authority add-on to it, that seems to work fine too. All the management tools are also installed onto the W2K3 server, including RCFG.
We have all the tools and utilities from Intel, but we couldn't get this bloody thing to work properly. The latest MDTK includes "Director" which is capable of creating self signed certificates, but we have NO proper documentation on how to properly do it, meaning what goes where, what options to choose, if this vs. if that... The "Commander" tool also has the capability of creating certificates but every time we use it gives us an error message...Seems quite buggy...
To make the long story short, we need some kind of guidance with our project:
Static IP configuration
2 way authentication with self signed certiciates (TLS)
7.x AMT platform
Sounds simple, but we've been banging our heads against the wall for almost 2 months. It's time to ask for some help. We e-mailed Ylian last night about our problem, but on a second thought it might be better to post a question here as well, so the others can see the potential solution to our problem, too.
Any info, guidance, flow chart or anything related to our problem will be greatly appreciated.
Thanks a million,
Message was edited by: Robert S.
Lets start with the question of having to touch each system. If you want to create your own provisioning certificate you will need to touch each one. This is needed to insert your own custom root CA thumbprint so that AMT will trust your provisioning cert. You don't ahve to do this if you can purchase a provisioning certifcate from a third party. If you want to order a provisioning certificate from a third party you will need to make sure that your current DNS domain is a publicly registered one. That's a requirement for the verification process that third party CA's use.
Have you looked at doing host-based configuration instead of remote configuration? No provisioning certificate is required for this provisioning mode. All you need it local admin rights to run it on your vPro clients. One thing to keep in mind with host-based configuration is that user consent for KVM Remote Control and boot redirection (IDER sessions, boot to PXE, etc) is manditory and cannot be disabled.
As for DHCP versus static IP addresses, you are in good shape with AMT 7. You have two options when you configure your clients. You can either go into the MEBx and specify the IP address, or, make sure you install the AMT driver stack, which will detect the OS network settings and apply them to the Management Engine for you.
For details on creating your own provisioning certificate for remote configuration, take a look at the SCS 7.1 user guide available in the Intel AMT Setup and Configuration Service here: http://software.intel.com/en-us/articles/download-the-latest-version-of-intel-amt-setup-and-configur... http://software.intel.com/en-us/articles/download-the-latest-version-of-intel-amt-setup-and-configur.... The details are in apendix B. You can find a lot of other useful information in this guide as well.
Well nice anwser there but i you have older AMT cards the public Root thumbprint is no longer valid.
so you're verisign or godaddy cert is useless.
We want SCCM to configure the AMT cards but now you tell me it is not possible.
The link you gave does NOT have any "Appendix B," not that I can find.
It takes you to a general one-page blurb about "downloading the latest scs."
"Download the latest version of Intel® Setup and Configuration Service (Intel® SCS)"
Am I missing something?
Can you please give more info on WHERE (or 'how') to find that Appenix B with steps for creating self-signed certs?
Also, greatly appreciated if someone can clafiry this:
1) Sounds like *IF* we use the stock thumbprints that are somehow embedded in ...? BIOS ?? - then we DON'T have to 'touch' each machine,
2) We [do] have to touch each machine IF we use our own self-signed certs (to put thumbprint on each client)
3) My understanding was that the ENTIRE PROCESS, start to finish (in SCCM at least) could be set up UNSECURE - i.e., NO certificates needed, not even for provisioning - yet, when I go to SCCM options, we are FORCED to point to a certificate. This is yet another case of Microsoft and vendors FORCING a decision for us! If I do NOT want secure communication between the server and the clients it is provisioning, it should be MY CHOICE.
Otherwise, they are just trying to "sell certificates." (obviously they have stock in Verisign & other cert providers)
4) OLDER AMT clients may have outdated "public thumbprints," so that, even those will have problems and need to be 'touched,' if certs don't match somehow.
5) Someone, PLEASE provide a "direct, working link" to docs about setting up our own self-signed certs - thanks! (or help me understand how to find Appendix B on the link that you provided)
Here is a direct link to that PDF Dan was mentioning:
There, in appendix B, you can get more informaiton on remote configuration.
Now for your questions:
1. Correct. If you purchase a Provisioning Cert from (VeriSign, GoDaddy, etc..) there is no need to touch your systems.
2. Correct. If you do not want to purchase a Provisioning Cert, you will need to generate your own internal Provisioning Certificate and touch each system to input the Root Hash into the MEBx.
3. SCCM requires you use certificaftes for Provisioning and also requires that you set up an internal CA to support TLS.
4. Correct. you will want to check this matrix to see the Firmware level required for the specific Provisoning Certificate.
5. http://software.intel.com/en-us/blogs/wordpress/wp-content/uploads/2011/03/IntelR_SCS_7.0_User_Guide... http://software.intel.com/en-us/blogs/wordpress/wp-content/uploads/2011/03/IntelR_SCS_7.0_User_Guide...
I hope these answers help!
I agree to my friend here. There arent any clearcut documents about remote provisioning vPro clients using SCCM especially when it comes to using self created certificate from an internal CA. There is this one thing that has been troubling me for long, and that is the certificate based authentication and I just cant get the Remote Configuration to work. As you are already aware that the Intel MeBX are preloaded with a few standard certificates from external vendors like GoDaddy, Verisign, Comodo and so on but thhen there are a lot of people like myself who do not wish to purchase certificates from the above mentioned vendors. We really want to use a certificate from an internal CA based on our existing Windows Active Directory Infrastructure if possible. I would really appreciate if you could help me with the steps of using self generated certificate from an Internal CA for remotely provisioning the vPro enabled clients. My objective is to be able to Remotely provision vPro enabled clients out of the box (either in the workgroup or even across a Domain). I am new to the vPro technology and have studied most of the resources from the web and ofcourse the user guides available off the Intel website and so on. I want to learn Remote configuration using the PKI or the PSK infrastructure. I am trying to implement the vPro remote provisioning in my Lab here, to no avail. I have a small private network on a domain with one Windows server 2008 computer with the following roles ADS, DNS, DHCP, IIS, WDS and SCCM as well. I have also enabled DHCP option 15, 6 and also made sure that the alias name has been created for ProvisionServer in the DNS records. I have a few HP 2540P laptops with Intel AMT firmware version 6.0.3. Would you please clarify my queries on the following:
1. If I am going to be using SCCM to do OOB Provisioning and managing vPro enabled clients, do I still need to install SCS / RCS on the DC server 2008? If yes, why?
2. Are there any basic out of the box configuration / setup that I need to do in the MeBX of the vPro clients before they can be remotely provisioned via SCCM using TLS? Or is it that the Remote Configuration can be done by simply connecting the out of the box vPro client to the network and power supply? I am suppose, there are. Could you please give me the detailed steps that we need to perform in the MeBX of the vPro clients with AMT >= 6 before connecting to the network?
3. I dont wish to use the certificates from the external CA like GoDaddy, Verisign, Comodo etc, however I would rather use the certificate created from an internal CA based on our existing AD infrastructure and certification authority instead. I have also exported a copy of the .pfx certificate file as per http://technet.microsoft.com/en-us/library/cc161804.aspx# BKMK_AMTprovisioning2 http://technet.microsoft.com/en-us/library/cc161804.aspx# BKMK_AMTprovisioning2 .
Per the documentation, now that we have created a provisioning certificate, we need to insert the certificate hash into the MeBX. Is there a way to burn in the certificate hash into the MeBX using a USB flash drive. Which tool would I use and what command/syntax would prepare a USB flash drive for burning in the certificate hash into the MeBX?
4. For the environments with only AMT version 6 and above, do we still need to install and configure wsman Translator for provisioning based PSK keys? I suppose wsman translator is only required for provisioning vPro client with earlier AMT versions. Right?
In simple words, I just want to implement remote provisioning vPro client with AMT versions 6 and above with SCCM using the PKI infrastructure (certificate from an Internal CA). Can you please walk us through the detailed steps that havent been discussed else where.
Thanks In advance