- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello around.
We managed to set up our OoB Managment with SCCM 2012 SP1 on a Windows Server 2012 some time ago.
Now we got a little problem, perhaps someone can point me the right direction.
I can discover and provision clients with AMT Version 5.2.1 and up without problem but when i try to
discover a client with Version 5.0.1 or earlier i get a TLS handshake error. We found out, that the communication over port 16993
seems to be the problem, but the other clients also use this port and work great. The clients are in the same IP subnet, we checked
Firewall and IPsec-Rules but provisioning dosen't work.
I tried to provision with Intels SCS Console and the ACM_Configure but get the same error here. (Certificate Template was modified before)
Also Version 5.2.1 works fine.
Now I was wondering if there is a list with things that have changed between Version 5.0.1 and 5.2.1. Perhaps we can isolate the problem.
Normaly provisioning shouldn't work for any Client if it is a certificate or network problem.
Any help or suggestions?
Thank's in advance.
Thomas
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi TKremer,
Here are two articles that should explain and help you solve the issue you're having with your AMT 5.0.1 systems.
Explanation of why this is happening.
http://www.symantec.com/connect/articles/updated-verisign-root-certificate-vpro-provisioning http://www.symantec.com/connect/articles/updated-verisign-root-certificate-vpro-provisioning
Guide to fix the issue.
http://www.symantec.com/connect/articles/re-chaining-verisign-g5-certificate-intel-amt-remote-configuration http://www.symantec.com/connect/articles/re-chaining-verisign-g5-certificate-intel-amt-remote-configuration
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Alan,
thank's for the answer.
I checked the Certificates and Certificate-Chains but we already had the G3 Root certificate in the Trusted Root Certification Authorities and the Intemediate Certificates were in place also.
Our Server Certificate shows the Verisign Class 3 Secure Server CA - G3 entry as part of the Chain. (Picture attached)
I tried to re-chain the certificate following the instructions but that didn't work either.
I also tried a BIOS Update but with no effort.
Any other ideas would be great.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thomas,
Based on the screenshot you posted, it looks like your provisioning certificate is not the problem. AMT 5.0.1 has the root cert hash for a VeriSign G3 based certificate. What I would like to know is what your Intel SCS provisioning profile consists of. I'm wondering if you're using TLS and or Wired 802.1x authentication. If you are, what is your key size?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Allan
we are using TLS authentication in our SCS provisioning profile.
Our certificate key size is 2048 bit.
To avoid kerberos problems we use a special provisoning account with a kerberos ticket size of
1028.
If you need more information please tell me.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is a brief summary of the solution if someone stumbles over the same error.
After some work with Alan Alderson and Mr. Pham from Intel we came to the conclusion that the AMT Version 5.0.1 Firmware has problems with the TLS certificates.
A low security provisioning with the Intel SCS Tool worked fine but SCCM 2012 can't provision the clients.
A firmware Update to Version 5.2.70 solved the problem in our case.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page