Kerberos Authentication of Intel vPro in an Altiris environment

Version 3

    NOTE: This resource is a re-post of information provided at  Although the title and material make reference to Altiris, the core concepts apply to any Intel SCS based solution




    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 ( 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  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  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



    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.



    NOTE: If not using Altiris, a similar interface is available via the Intel SCS console or other application which integrates into the Intel SCS application








    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 Improving Loading Performance in RTSM article, 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:


    • KB8999000 - 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 depends upon group membership, domain trusts, and other items affecting a user's SID.  One estimates is roughly 60 group memberships.  If you want to check exactly how large the service ticket is in your environment - do a network trace between the Altiris notification server to a domain controller. Look for kerberos TGS-REP packet. This is the Ticket-Granting-Ticket (TGT) returned by the domain controller. In lab environment, I found this packet to be between 800 and 1,500 bytes.  Microsoft's recommendation is to support 64k service tickets - this has been noted for future Intel AMT firmware updates

      • How many users are supported?  The 4K buffer limit within the Intel vPro firmware can accomodate ~60 groups. This will vary based on nested group memberships, domain trusts, and other items that affect a user's SID.   If you want to check exactly how large the service ticket is in your environment - Look for kerberos TGS-REP packet. This is the Ticket-Granting-Ticket (TGT) returned by the domain controller. In lab environment, I found this packet to be between 800 and 1,500 bytes.  Or - use the Microsoft TokenSZ utility

    • 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 ( 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.



    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.