In the previous article Kerberos Authentication of Intel vPro in an Altiris Environment, an explanation was provided on how Kerberos applies to Intel® AMT for authentication. This article addresses a deployment and integration approach for Altiris environments - specifically, how to use any LDAP account which can be associated to an Altiris console security role and still have Intel® AMT functionalities.
As I researched and posted the previous articles, along with many customer and partner related discussions, a few core concerns were oft repeated:
- Only a single Microsoft Active Directory 2003 Forest environment is supported for Intel® AMT Kerberos authentication. Many production environments have multiple LDAP infrastructures or client systems that are currently not joined to a Microsoft Active Directory 2003 forest\domain.
- In the current setup, Kerberos authentication to Intel® AMT requires a Microsoft Active Directory object for the Intel-Management-Engine device. By enabling Active Directory integration, the directory schema had to be extended which is a non-reversible operation. Similarly, for each provisioning Intel® AMT system, a matching Intel-Management-Engine object must correspond to the existing directory computer object. Thus the possibility of doubling the number of computer related objects within the Microsoft Active Directory.
- The Intel AMT firmware currently supports only a 4kb size Kerberos Ticket Granting Ticket (which equates to roughly 60 groups). For some enterprise production environments, a larger Kerberos TGT is required. Some might argue that the underlying Microsoft Active Directory groups should be adjusted to a number less than 60.
- LDAP authentication effectively occurs at least twice - once for the user to access the management console, and a second time for the user to access target client computer. From a security auditing perspective, this may be preferred. From a performance or multiple LDAP structure perspective, this may be a nuisance.
- A greater level of control on a user's Intel® AMT actions. For example, allowing a user to only power-on units. From an Intel® AMT Access Control List context, the user would need "remote control" access, which would grant not only remote power-on, yet also power-off, restart, and other features related to "remote control ACL" settings.
Using a Service Account
When logging into the Altiris management console, the user is typically assigned to a defined Altiris console security role. That security role determines what actions and level of access the user is granted. A common production implementation is to add users within an LDAP group, and then place that single LDAP group as a member of an Altiris security role. As will be shown later on, the Altiris security role can be customized to restrict a user to a more granular level of control and access to Intel® AMT.
Similarly, with the Altiris Real-Time Console Infrastructure (RTCI) Profile, a default credential can be used to access client systems. When using Altiris TaskServer or other functions which can access Intel® AMT, the Altiris RTCI profile provides a handy mechanism for default feature and control access. As shown in the following image, the Altiris RTCI profile can be used to define a single account for access to Intel® AMT features - in essence, a Service Account.
Restricting a user's access to Intel® AMT features can be handled via the Altiris Security role and setup. The Intel® AMT service account has full operational capabilities.
Building upon that model and idea, the following summary diagram may help to further explain and understand. The model has been generalized intentionally.
As a brief explanation to the above diagram:
- A user is able to access the client management solution (i.e. Altiris console) based on established group association, console security roles, etc.
- User requested actions to Intel® AMT devices for out-of-band management are sent from the client management console to the target Intel® AMT client using the "service account"
- Intel® AMT service account credentials can be either Digest or Kerberos based. The latter will require Microsoft Active Directory integration, with a define Intel-Management-Engine object associated to the existing directory computer object.
Digest or Kerberos Account?
For simplicity, the preference may be to use a single Altiris RTCI profile with an Intel® AMT administrative account defined. This being the case, all provisioned systems would be accessed via Digest Authentication instead of Kerberos authentication.
For greater security, the Altiris RTCI profile could be defined with a Kerberos related account. Thus the service account idea still exists, and Kerberos authentication is used. During the provisioning process, a single Kerberos account could be specified. However, this approach will likely require every Intel® AMT device to have two objects in the Microsoft Active Directory Forest - one for the computer object and a second for the Intel-Management-Engine object.
Other approaches can be taken, including those that prefer to avoid the service account approach and have a direct mapping of each user to access Intel® AMT features.
Keep in mind the golden rule: "once provisioned, any authenticated and authorized request is accepted." As an example, if you have an environment with Altiris and Microsoft based client management solutions, it's really a matter of those respective consoles - or the users of those consoles - knowing the underlying Intel® AMT authentication requirements. In the case of Microsoft SCCM, interaction with Intel® AMT is handled via Kerberos authentication with TLS certificates. Therefore, the defined Kerberos user (which could be an individual user or group) used by Microsoft SCCM would also be used by Altiris. Similarly, the root certificate used for TLS authentication by the Microsoft SCCM environment would need to be installed\associated on the Altiris console.
Microsoft SCCM is the only client management solution to date that required Kerberos authentication for Intel® AMT usage. Other consoles (i.e. LANDesk, Microsoft SMS, etc), can use the Digest authentication for Intel® AMT.
Greater Level of Control
Using the Altiris security roles, and security rights customization, access to Intel® AMT functionality can be restricted beyond the default Intel® AMT Access Control List. As an example, in the following screenshot, a logged in user (i.e. Tech1) has been restricted to only defined TaskServer jobs. The user is unable to modify the job, yet is able to actively use the job for defined collections of computers.
In the example shown below, the defined TaskServer job will power-on the target systems via Intel® AMT, run a defined software delivery job, and then gracefully power-off the client. The user (i.e. Tech1) is a member of the lowest level Altiris security role, with the TaskServer able to use the default Altiris RTCI profile which has full Intel® AMT usage capabilities. However, in this context, the "most restrictive" rights are effectively in place between the Tech1 and Altiris RTCI accounts.
Customizing the Altiris Security Role and Permissions required a bit of extra effort. If interested to understand how I accomplished this, add a comment below and I'll attempt explain. However, I understand that Notification Server version 7 security role and permissions will make the process a whole lot easier.... We'll see.
Conclusion
In designing your security infrastructure to access Intel® AMT features and capabilities, a number of considerations and options are available. At the core, authentication to Intel® AMT is handled either via Digest or Kerberos authentication as defined during the provisioning process. In a production implementation, use of a service account may provide for a "good enough" security approach. The user is authenticated to the Altiris console via defined Altiris security roles and permissions. Intel® AMT related actions by the user can be authenticated based on the defined Altiris RTCI profile settings. Other combinations can be considered as you pursue the balance of management and security in your production deployment and implementation.
The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.