I tried toconfig anAMT device with a pofile, whose network is set withUse TLS,TLSServer AuthentificationtoLocal Interface and TLS Mutual Authentifcication to Network Interface.
Though it was indicated as Provisioned on Console, but i could not connect to the AMT deviceneither by Commander nor by WebUI. When by WebUI method, i was given a popup to confirm the cerficate, but failed afterwards.On SCS console, the log said: "Cannot contact provisioned intel AMT device at FQDN: ...."
Here is part of my environment:
AMT : V 3.0
SCS: V 3.1
SCS environment was set up following the manual (Intel AMT SCS Installation and User Manual.pdf) from the SCS_3.1_Gold package.
So far, i doubted it might have something to do with CA, but Ifailed tofind any way to solve this issue after much work.
Any help/hint from your guys is very much appriciated.
Thanks in advance.
Thanks for posting the question on the forum. First, I am assuming that you are trying to connect to AMT remotely from another machine. According to your profile parameters, you are using TLS mutual authentication for remote interface. This means that both sides of the connection need to identify themselves using certificates. This requires that on the machine where the connection is being inititated, the root certificate and a client certificate is installed. Also AMT needs to be configured with a certificate for proving its identity during the TLS handshake operations.
We can try a small experiment here. Can you create a profle with no TLS first and after the AMT client is provisioned, try connecting to it using WebUI or commander. Once you are successful, you can try TLS with server authentication on remote interface and try connecting via WebUI. If you are successful in the last two modes, we can root cause the issue further.
Are you doing any Active Directory integration? Please let us know how things go and we will take it from there.
Thanks for your reply.
I try the small experiments you talked about. Here are the results:
With Profilewith no TLS and WITHOUT AD integrated, the AMT CAN be connected;
With Profile with no TLS but WITH AD integrated, the AMT CANNOT be connected, via WebURL, I just cannot login with correct Password;
With profile with TLS, and TLS Server authentication to local interface and TLS Server authentication to Network interface, but WIHTOUT AD integrated, the AMT CAN be connected, but with warnings Connection name, DNS name, certificate name mismatch shown on commander.
With profile with TLS, and TLS Server authentication to local interface and TLS Server authentication to Network interface, and WITH AD integrated, the AMT CAN NOT be connected, on commander, it is shown as 192.168.1.3---intel amt with TLS or not configured.
With profile with TLS and TLS Server authentication to local interface and TLS Mutual authentication to Network interface, no matter if with AD integrated or not, the AMT device CANNOT be connected;
In all, AD makes difference in the first 4 trials, and Mutual authentication cannot work with or without AD integrated.
About AD, I installed it following the manual and also ran the BuildSchema.vbs after SCS installation.
About what you said Also AMT needs to be configured with a certificate for proving its identity during the TLS handshake operations., I do not know how to configure AMT with a certificate.Are there any specific steps to make it?
Thanks for reply.
Here are more details about the ways I did:
I used SCS Console to configure an AMT device, then used DTK Commander to connect it; besides, SCS Console is installed on the same 2003 Server with SCS, on which DNS, DHCP, AD are all installed for convenience.
Since the Console and SCS are installed on the same server whose CA are installed according to Intel AMT SCS Installation and User Manual.pdf, I am not sure if the Console certificate conditions are met automatically.
In order for mutual authentication to work, a certificate need to be installed to the console with the certificate name as FQDN of the machine from which you are connecting to AMT. Since TLS Server authentication works, AMT is configured correctly.
We need to configure the machine from which you are connecting to AMT. Your server machine should have two certificates installed on it. One is the root certificate, which is there because TLS server authentication worked. Another certificate that is needed is the one issued to the machine that can be used for mutual authentiation.
Please refer to the section - "Installing an Intel AMT Client Certificate for TLS Mutual Authentication" , page 35 in SCS Installation and User Manual.pdf document. You will have to create a new template (page 119 has instructons)based on the user certificate and will have to add a intel specific OID to the extended properties of that template. After the template is issued, you will need to request a certificate with the certificate name as FQDN of the machine name. Once you install this certificate, TLS mutual authentication should work. If you run into any issues, please send us the root certificate and the console certificate.
Hope this helps.
A good news.After configuredby SCS, now AMT with Server-Auth or Mutual-auth is working with Commander, which means I can connect to AMT device by Commander and work on it . However, we still have some bad news. On SCS console, after provisioning, it still shows the error like: Cannot contact provisioned intel AMT device at FQDN:, and also, if click the webURL on commander like https://amt09.dns02.intel.com:16993, we cannot log into AMT, and it also does not work at using IP likehttps://192.168.1.2:16993.
Do you have any idea about it?
Note that AD is not integrated as you suggested.