1 of 1 people found this helpful
- For your situation, running ACUConfig to apply your SCS profile on each computer would be the least complex way to configure AMT.
- vPro will work independently.
- SCCM requires TLS communication with AMT. SCS integration will also require the use of Kerberos.
Once configured you can power them up on demand, or on a schedule using the AMT Alarm Clock feature.
Thanks for the input Alan. If I decided to try to tackle TLS so I can use AMT with SCCM, is it possible to set up SCS as an independent installation and then just "plug" it into SCCM later? (As opposed to doing everything via the Add-on 2.0; or would the Add-on be the better route?)
What is tripping me up the most is the TLS issue. It seems most of the documentation assumes a solid familiarity with certificates, but our team has never used them. I understand the importance for security, but the complexity is certainly an obstacle. Is it possible to have full AMT functionality without the use of certificates? (only using PSK?)
There seems to be so many versions, variations, and variables with vPro/AMT/SCS that it's hard to know you're starting on the right path. Maybe I'm an idiot but I could certainly benefit from some decision flowcharts :-O
1 of 1 people found this helpful
Yes you are able to setup an SCS server separately. Then at a later time use the SCS Add-on to integrate it into SCCM.
It's absolutely possible to have full AMT functionality without using certificates. You can achieve full AMT functionality with a basic SCS profile. That profile only needs to contain the mandatory system settings. Later, if you want, you can go back and reconfigure your vPro computers with a new SCS profile that includes any of the increased security options.
I need to develop a process that covers the spectrum, AMT 2.2 and up.
- The only way to do this, without PKI/certificates/CA, is to use the One-Touch (TLS-PSK) provisioning method, correct?
- After TLS-PSK provisioning, TLS communication isn't required. But if I decide to enable TLS-PKI later won't I need to manually install a new root hash, meaning all machines would have to be touched again?
- If TLS is only for encrypting the communication with a client, what protects the device itself? Digest passwords?
Later, if I want to integrate AMT with SCCM it will require a certificate. Either a Microsoft CA, or 3rd party certificate. Our network team says we have an internal CA, and we have a "wildcard cert from Entrust I may be able to use".
- From experience, which would be the least problematic, using an internal CA or the Entrust certificate? (Disregarding the need to the need to import it into the root of each device since Entrust is only for versions 7.0+)
Thanks so much for your help.
- This depends on if you use your own internal CA provisioning certificate or get a 3rd party certificate. Using an internally created provisioning certificate will require you to manually input the certificate hash into the MEBx of every AMT computer. However, certain 3rd party certificate hashes have been present in the MEBx beginning with AMT 2.2.
- Digest passwords and if you choose, Kerberos.
- Using a 3rd party provisioning certificate would be easier in the long run. All future vPro computers would already contain the certificate hash, which would mean less work for you.
As far as your current Entrust certificate, in order for it to work as a provisioning certificate it will need to have been created as outlined in this document. https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=22269