If you plan to use Kerberos authentication yet are not familiar with nor own the Microsoft Active Directory infrastructure in your environment, share this article with those who do manage that environment. You will need their assistance to be successful, especially since some of the steps will require directory administrator rights to complete.
Earlier a poll was posted on the Juice to find out how many in the Altiris Juice community were planning to use Kerberos with Intel® vPro™ technology. The results were a little surprising - leading to concerns that either the capability was not known, was too hard to implement, or the instructions on how to implement were not sufficient. This article attempts to tackle a few of those topics, with the additional intent of helping to reconsider what authentication protocol may be preferred within your production environment.
Once an Intel® vPro™ technology system is provisioned, all subsequent requests must be authenticated and authorized. The authentication is handled either via Digest or Kerberos protocols. Both are defined in the provision profile, yet only one makes use of existing user lists within a production environment. Using the Kerberos Authentication protocol built into Microsoft Active Directory, an Intel® vPro™ client can be managed via any authorized account in the same Microsoft Active Directory Forest as the client - providing authentication capabilities to the individual users or groups are defined in the provision profile and applied during the provisioning process. This comes in handy when a group is defined - thus changes to the group are the defining factor of who has rights to manage the Intel® vPro™ clients.
Kerberos Authentication for Intel® vPro™ technology is "least restrictive". This means that if a single user is a member of two or more groups defined as Kerberos users in the provision profile and assigned different authorization levels to the Intel® AMT realms - than the user is granted the cumulative values.
If Kerberos is not used, then the authentication is usually handled via MD5 Digest Authentication as most of the Intel® vPro™ technology communications are SOAP over HTTP based. More on Digest Authentication can be read at http://en.wikipedia.org/wiki/Digest_access_authentication. The exception is the redirection functionalities - Serial-over-LAN and IDE-Redirection. It is strongly recommended that these sessions be authenticated via Kerberos and encrypted via TLS.
For those wanting to review more detail on Kerberos and Integration with Active Directory for the Intel® vPro technology, obtain the Intel® AMT SDK from http://softwarecommunity.intel.com/articles/eng/1023.htm. Look for the documents "Intel® AMT integration with Active Directory" and "Network Interface Guide".
Building Upon the Microsoft Kerberos Authentication Engine
Kerberos authentication has existed for a long time, yet the foundational aspects of how it works are not always understood. For the Intel® vPro™ technology, the Microsoft implementation of Kerberos within the Active Directory is used. For those wanting to learn more about Kerberos Authentication in a Microsoft environment, check out http://technet2.microsoft.com/windowsserver/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx?mfr=true
In the context of that article, the focus is authenticating a user at a workstation to a service offered on a server, via the KDC on the domain controller. Although the same principles apply for authenticating to the Intel® vPro™ firmware, the difference is that session key is stored in the firmware at time of provisioning - along with Active Directory object updates and so forth.
What Core Items are Needed for Intel® vPro™ Kerberos Authentiction?
The following sub-headings step through core items needed to support Kerberos authentication to Intel® vPro™ firmware within the Altiris environment. A latter section will highlight some known issues and future considerations to further assist the reader.
Intel® vPro™ Clients MUST be Joined to the Domain
The Kerberos authentication occurs with the Microsoft Active Directory Forest. Since the domain controllers provide the KDC and other Kerberos functions, both the requestor of the service and the provider of the service must exist in the same forest. In addition, the provisioning process attempts to link the existing Computer Object to the IntelManagementEngine object. Lastly, when clients are joined to the domain their FQDN is established and they are more likely to participate in dynamic DNS updates which will become key to addressing systems using the Intel® vPro™ technology.
Intel® SCS 3.2.1 is Recommended
The September 2007 release of the Altiris Out-of-Band Setup and Configuration service includes Intel® Setup and Configuration Service (SCS) version 3.0.2.x, which has been integrated into the Altiris environment. This is the core service which handles the provisioning and configuration maintenance of the associated Intel® vPro™ systems. Within the Windows Services, look for AMTconfig to easily determine what version has been installed within the environment.
Earlier this year, Altiris tested and validated a later release of this service as highlighted in Altiris Knowledgebase article 40076. The validated version of 3.2.1 is recommended to handle the current versions of Intel® vPro™ technology. As the next major release of Altiris approaches later this year, the integrated Intel® SCS version is expected to be upgraded to the next major release.
After installing the update via AMTconfserver.exe, ensure the AMTSCS virtual web directory settings match the Altiris Service Location settings in respect to whether SSL is used or not.
Enable Integration with Active Directory
Before proceeding with the setting shown below, a discussion with your Microsoft Active Directory administrators will be needed, along with their support to extend the directory schema. The schema extension adds in object types to support Intel® AMT within the directory including the version number, UUID, and so forth. Schema extensions do occur in production environments, yet often require review and consideration as the action of adding to the schema cannot be reversed.
If the schema has already been updated and a newer version of Intel® SCS is installed, it is recommended to rerun the schema extensions to ensure the latest Intel®AMT object attributes are available in the directory.
Enabling the integration with Active Directory will also require that an Active Directory Organization Unit (AD OU) be defined at time of provisioning. This will create an Intel® AMT object which is linked to the existing Computer Object. This setting can be defined in the Resource Synchronization tab, or passed as a parameter via a provisioning script.
AMTconfig Logon Account has Active Directory Rights to Create\Modify
Existing in the same domain is best, otherwise the AMTconfig logon account must be delegated control within the Active Directory Users and Computers to create and delete IntelManagementEngine objects. If the AMTconfig service logon account is unable to create and delete objects and Integration with Active Directory is enabled, the provisioning process will fail. The Intel® SCS logs will record errors indicating the service was unable to create or delete the AD AMT object.
To delegate control to a specific account, open the Active Directory Users and Computers. Right click on the target OU, and select Delegate Control.
In stepping through delegation wizard, the AMTconfig logon account must be defined with custom rights to create and modify ONLY the intelManagementEngine objects. The following three images provide a summary on these settings within the delegation wizard, once the logon service account has been identified.
- A custom task to delegate must be defined.
- Only intelManagementEngine objects are targeted for delegated control.
- Full-Control permissions must be defined to allow the AMTconfig logon service account to create, modify, review, and perform other functions on intelManagementEngine objects.
The full details of rights delegation are beyond the intent of this article, and are often already understood by enterprise directory administrators.
Enable Kerberos User in the Provision Profile
The next key step is to define a Kerberos User in the Provision Profile. The Kerberos User can be either a single Microsoft Active Directory User or a defined Group. In the example below, the group Domain Users was selected to help prove the point. For production environments, the Kerberos user might be Level One Support or something similar. As will be noted later on, the total number of users has a limitation thus the recommendation is to keep the groups or list of users to small finite set.
With the user defined for authentication, the authorization of Intel®AMT Realms must also be defined. This article will not dwell on the different options and reasons, except to state that the example above would grant a majority of the usage control for Intel® vPro™ out-of-band capabilities.
Apply the Provision Profile
Once the profile has been updated, it must be applied either to new or currently provisioned Intel® vPro™ systems. For systems to be provisioned, making the provision profile the default selection in Resource Synchronization will be sufficient.
For systems already provisioned, check the Profile Assignments to ensure the updated profile is the same as the currently assigned profiles. If so - select the target units within Intel®AMT systems and ReProvision to apply the profile changes.
For systems already provisioned yet assigned a different profile, update the Profile Assignments and then ReProvision.
Update the Real-Time Console Infrastructure Profile
This step is optional, and may not be preferred if the users credentials are not to be stored within Altiris. If the RTCI profile is used, updated the AMT portion of the RTCI profile with the appropriate domain\user and the associated password to be used for subsequent authentications. The preference may be to have the user enter these credentials at the time of usage.
According to the article Improving Loading Performance in RTSM, the currently logged in user will also be used to attempt a Kerberos authentication. This was not tested in the lab prior to writing this article, only a defined RTCI profile was used. I am interested to hear experiences from the community.
Troubleshooting Kerberos Authentication
If all of the steps above have been followed, and the Kerberos authentication does not appear to be working - a quick test can be done using the Intel®WebUI. This option must be enabled in the provision profile, which must be applied to the target client systems via a provisioning event.
For Microsoft Internet Explorer to address the correct Intel®AMT network ports for Kerberos authentication, two key items must be in place:
Enable Integrated Windows Authentication
Within the Tools > Internet Options of Microsoft Internet Explorer, under the Advanced tab is a setting to Enable Integrated Windows Authentication. This setting attempts to pass through the credentials of the logged in user during the Kerberos authentication. The initial attempt will likely be prompted for a username and password, with the username entered as domain\user. However, all subsequent requests by the same user will be acknowledged
Microsoft Kerberos Updates and Patches
For Kerberos authentication to be directed to specific network ports, users attempting to authenticate with Kerberos from systems without Microsoft Windows XP or Windows Server 2003 Service Pack 2 will need the following updates:
- KB899900 - Will allow Windows HTTP Service to append a port number
- KB908209 - Allows Microsoft Internet Explorer 6 to use Kerberos Authentication
NOTE: The second update includes an important registry update which must be applied even if the target systems already has Service Pack 2 installed, regardless of Internet Explorer versions. If not applied, after the login credential are entered Microsoft Internet Explorer will return a Page Not Found or similar error.
The image below provides a summary of patches needed. The Altiris NSCap file share was modified for the purposes of a lab environment, thus the AltirisNSUpdates folder shown is a custom folder created outside of the published Altiris installation and updates.
Known Limitations and Future Considerations
Before writing this article, I spent a number of hours validating the setup in the lab, talking with others, and learning some of the pain points of Kerberos Authentication with Intel® vPro™ technology. The following items may be of key interest:
- Kerberos authentication is time dependent, with a maximum tolerance of 5 minutes within an Intel® vPro™ technology environment. The UTC time is synchronized via the provisioning maintenance options, with the maximum tolerance defined in the provision profile
- The Intel® vPro™ firmware supports Kerberos service tickets that are 4K or smaller. The contents of the service ticket identify the authorized users, which are matched based on the defined Kerberos user in the provision profile. Thus, if a group with a larger number of users is defined as the Kerberos User, the authentication process will fail if the Kerberos service ticket exceeds 4kb. The exact number of supported users was not determined at the time this article was written. It is a combination of trusted domains, groups, and individual users.
- Intel®SCS 3.2.1 and earlier versions may bind to a different domain controller during the provisioning process. Some refer to this as a "bindless update" situation. When the changes are attempted, the process fails yet the Intel® SCS service may not report back. Only when the Kerberos authentication is attempted and fails is the problem realized. A reprovision event may resolve, yet the chances are too great for an error when multiple domain controllers exist for a single domain. Intel® SCS 3.3.1 (http://softwarecommunity.intel.com/articles/eng/1025.htm) fixes this issue, yet is not officially supported by Altiris.
- Intel® SCS version 5, which is expected to be integrated into the next major Altiris update later this year, does not require schema extensions to support Kerberos authentication to an Intel® vPro™ system. The core merits for schema extension include distinguishing an Intel® AMT device from a Computer object, providing a repository of UUID and firmware versions, and provide a linkage or association between the host operating system and firmware. However, extending the schema has presented a challenge in many environments, thus the requirement is being made optional in future Intel® SCS versions.
Conclusion
Kerberos authentication of the Intel® vPro™ technology in an Altiris environment provides better user authentication and authorization control. However, it presently also requires additional infrastructure coordination to integrate with Microsoft Active Directory. In addition, some of the known limitations which are either firmware or software based may present additional challenges in large complex production environments. Although the options and outcomes will differ for each environment, much of the information provided herein provides a foundation to help guide those decisions.
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.