On page 34 of the AMT add-on for SMS2003 Installation and User's Guide, the following note appears:
Note: This version of the Add-on does not support Kerberos profiles in which Active Directory groups are defined in the ACL tab in Intel® SCS. Tip: If you have multiple users, specify each user separately in the ACL tab (and not by specifying the group in which they are members).
If I interpret this correctly, we will need to add the Active Directory Service account for all SMSAMTUser_XXX accounts instead of a group. Could this be overcome by trusting the computer for delegation within AD?
The steps following this also instruct the reader to configure the SMSAMTUser_XXX accounts with the "Store passwords using reversible encryption" and "Remote Access Permissions (Dial-in or VPN)" set to "Allow Access". Does anyone have any ideas as to why this required for Kerberos authenticaiton to work?
I believe the limitation of AD groups you refer to only exists if you run the Add-on in the mode in which it is integrated with SCS, because in this mode the Add-on reads SCS profiles and parses AMT client access credentials from the ACL. I believe the limitation you refer to with the Add-on is related to attempting to parse AD groups in an SCS profile ACL.
If you have many SMSAMTUser_XXX accounts and wish to use AD groups to simplify management of them, I believe you will find you can use the Add-on in external authentication mode (i.e. not integrated with SCS). In this mode you can specify Kerberos as your authentication protocol, create an AD group containing your SMSAMTUser_XXX accounts and add that AD group into your SCS profile ACL with access to the required AMT client realms. After you reprovision clients with the profile, any SMSAMTUser_XXX accounts in the AD groups in the SCS profile ACL should have access to the client assuming you configured access to the appropriate AMT client realms in the SCS profile. You can validate this by logging into the AMT client WebUI using the SMSAMTUser_XXX accounts and their password.
Using external authentication mode avoids the necessity for the Add-on to parse AD groups in the SCS profile ACL.
If you decide to go down this route of external authentication, what you will need to ensure is that the Add-on settings for TLS are correct. This is because when the Add-on operates in external authentication mode it is no longer reading SCS profiles to determine how to communicate with clients, but is using the settings in the Add-on dialog. As long as your clients are all configured with the same TLS mode (either none, server TLS or mutual TLS) and your Add-on settings match that TLS mode then you should be OK
Re: your other question about VPN and reversible encryption. I have raised this question myself before and have been told that none of this is required for Kerberos access.
Thanks for the response. I had assumed that Integrated Mode was the preferred option as it allowed (among other things) the discovery of AMT clients from the SCS database instead of scanning subnets; reprovisioning and unprovisioning. I guess the limitation in terms of Kerberos support is the trade off.
On Friday, I discussed these issues with a contact that I have in Intel UK. He is going to try and obtain definitive answers.