Differences of Digest versus Kerberos Authentication with McAfee ePO Deep Command

Version 4

    Introduction

    McAfee ePO Deep Command works with Intel® Active Management Technology (AMT) to provide beyond-the-operating-system security management.   All communications to Intel AMT are authenticated and authorized per an Access Control List stored within the firmware.   The authentication occurs via MD5 Digest or Kerberos, and the session is encrypted via TLS.

     

    Choosing between Digest or Kerberos authentication is one of the first steps in a McAfee ePO Deep Command deployment. Both are fully supported and provide the same level of functionality when working with Intel AMT in a McAfee ePO Deep Command environment.  However, they differ in setup complexity and security considerations.

     

    In general, McAfee recommends using Digest authentication for test environments and proof-of-concept deployments because it is simpler to implement. For production deployments, McAfee recommends using Kerberos because it is more secure.

     

    This article details the differences between Digest and Kerberos authentication.   Administrators should consider all of this information when planning a deployment of McAfee ePO Deep Command. It is also important to understand that it is possible to move from one authentication type to another. This is done by simply changing the Intel AMT configuration profile and updating the Intel AMT Credentials within McAfee ePO.

    Overview of Digest versus Kerberos Authentication

    This section provides a rudimentary explanation how the two authentication approaches work in respect to Intel AMT.   Only the authentication sequence and overview are summarized.   The authorization of the credential to perform a particular function is addressed in the next section of this document.

     

    MD5 Digest authentication compares a nonce, or one-time generated hash value, based on the user account and password known by both the requesting application and the Intel AMT firmware.   Other components involved in generating the nonce include the UUID of the platform and session time value.

     

    The nonce value is unique to that particular session.   The session originates from the requesting user or service in the following manner:

    • Requesting application: “Hi, I want to authenticate this user account and here is my calculated nonce value”
    • Intel AMT firmware: “I have a matching user account.   I will generate my nonce value and compare to yours.   Yes – the nonce values match.   You are authenticated.”

    Digest-Kerberos_pic1.png
    Only the user account name and nonce value are transferred across the network.   With McAfee ePO Deep Command, all Intel AMT communications are encrypted via TLS.   For more information on why TLS is recommended with Intel AMT including screenshots of network traces, click here.

     

    The advantage of MD5 Digest authentication is simplicity.   Only a direct connection from the requesting application to the Intel AMT firmware is needed for authentication.  

     

    The disadvantage of MD5 Digest authentication is maintenance, interoperability and flexibility.   If the list of users or passwords must be updated, a re-configuration event for Intel AMT firmware must occur.   Plus, Digest credentials are commonly shared among users and applications.    In the case of McAfee ePO, the Intel AMT Credentials within the console acts as a service account.   Access to the AMT action menus within McAfee ePO is controlled based on console permissions.   McAfee KVM Viewer, introduced with ePO Deep Command version 1.5, is a separate application with many instances used across an enterprise.   Maintenance of passwords, access control, and unauthorized used becomes increasingly difficult due to a known account\password combination.

     

    In contrast, Kerberos authentication to Intel AMT improves interoperability and security but also raises complexity.    Kerberos authentication requires Microsoft Active Directory integration, which includes a second directory object per configured Intel AMT device within the network.   The second Active Directory object has a “service principal name” or SPN used for Kerberos authentication.

     

    In the summary diagram below, the SPN is vProSystem$iME.   The sequence of events is as follows:

    • Requesting application to Intel AMT firmware: “Hi – I want to authenticate”
    • Intel AMT response to requesting application: “Please obtain a Ticket-Granting-Ticket”
    • Requesting application to Microsoft Active Directory: “Hi – Here is my domain credential.   Will you provide a Ticket-Granting-Ticket for vProSystem$iME”
    • Microsoft Active Directory to Requesting Application: “One moment while I validate your domain credential.   Ok – you are an authorized in the domain.   Here is the Ticket-Grant-Ticket for vProSystem$iME”
    • Requesting application to Intel AMT: “Here is my Ticket-Granting-Ticket and Security Identifier”
    • Intel AMT to requesting application: “One moment while I validate.   Ok – you are authenticated”

    Digest-Kerberos_pic2.png

    The Security Identifier (SID) used in the example above is a unique value to identify an individual user or group to which that user is a member within the Microsoft Active Directory domain.   During the Intel AMT configuration event, a list of SID values is placed within the Intel AMT firmware as defined by the configuration profile.

     

    The advantage of Kerberos authentication is flexibility in allowing or blocking user authentication based on group membership.   Although a user or requesting application may be able to obtain a TGT, they must also have a valid SID per the list of authorized users within Intel AMT firmware.

     

    A key disadvantage of Kerberos authentication is the secondary domain object for Intel AMT authentication.   The secondary Intel AMT domain object will require maintenance to ensure proper directory lookup, especially if a hostname value changes on the client.   The hostname change on the client will automatically trigger a computer object update, but maintaining the Intel AMT domain object requires an Intel AMT configuration maintenance event that is separate and must be scheduled.

     

    Using the example below, a separate Active Directory Organization Unit (AD OU) has been created for Intel AMT domain objects.   The HP8440p$iME object properties are shown.   If the computer were renamed to MyClient via a hostname change, the Microsoft Active Directory computer object will be updated but the secondary Intel AMT domain object will remain as HP8440p$iME until an Intel AMT maintenance event is initiated.   Users and applications on the network will request authentication to MyClient$iME, but this object will not exist until the Intel AMT configuration maintenance event occurs.
    Digest-Kerberos_pic3.png

     

    An additional layer of detail is shown via ADSIedit (run ADSIedit.msc, connect to the target domain, and navigate to the target OU for Intel AMT objects).  

     

    Shown below from a similar environment:

    • sAMAccountName - includes the $iME reference.   This refers to the "Intel Management Engine" for that host.
    • sAMAccountType - Machine Account.    The kerberos authentication is to the server (i.e. Intel AMT) within the target host
    • servicePrincipalName - commonly referred to as SPN.   The FQDN of the client with Intel AMT network ports (i.e. 16992-16995).    The network ports of 623 and 664 are for WS-MAN communications as defined by the DMTF (Desktop Management Task Force)

    ADSI edit example.png


    Defining Authentication and Authorization via Intel AMT Access Control List

    Completing the previous summary dialogues, the next step after Authentication is Authorization.  That is – your credential may be allowed to authenticate, but when compared to the permitted Intel AMT realm access (i.e. the Authorization) the requested operation may be denied.   The Authentication and Authorization of Intel AMT is defined via the configuration profile.

     

    When configuring Intel AMT, an optional setting in the Intel® Setup and Configuration Software (SCS) console enables the definition of the Access Control List (ACL) to be applied into the firmware.   This is where a Digest or Active Directory User\Group can be defined, and the settings will be applied into the Intel AMT firmware during the configuration event.

     

    In the example below, a Digest User account of “UserName” has been defined with Intel AMT Realm access of “PT Administration” for both local and network interfaces.
    Digest-Kerberos_pic4.png
    For McAfee ePO Deep Command purposes, the user account must have “PT Administration” Realm access.   This level of access is required to Enforce AMT Policies.

     

    The Access Control List is an Optional Setting for the Intel AMT Configuration Profile.    If not defined, the Intel AMT Admin account can be used with McAfee ePO Deep Command operations if a static password is provided to all Intel AMT systems.   The required System Settings section of the Intel AMT Configuration Profile is where the password for the Intel AMT Admin account is specified.

    Digest-Kerberos_pic5.png
     
    Note: There are options to randomize the Intel AMT admin account, which provides additional protection.   If used, the Intel AMT Credentials within McAfee ePO must be an Intel AMT account as defined by the Access Control List settings highlighted above.   McAfee ePO supports only one Intel AMT Credential, acting as a service account for AMT actions initiated by ePO Console users granted sufficient access via the console.

     

    Intel AMT Credentials within McAfee ePO Console and KVM Viewer

    Depending on the choice of Digest or Kerberos, the Intel AMT Credentials will look different.

     

    For a Digest account, such as the Intel AMT admin credential, the settings will look similar to the following:
    Digest-Kerberos_pic6.png
    For a Kerberos account, such as domain user that is a member of the Intel AMT admins group within Microsoft Active Directory, the settings will look similar to the following:
    Digest-Kerberos_pic7.png
    If McAfee ePO Deep Command is the only application using Intel AMT, the Digest credential is simple.   Since McAfee ePO is effectively a proxy for Intel AMT communications, only a single account is needed.

     

    If other applications will be using Intel AMT, especially applications running from a technician’s system, the preference may be a Kerberos authentication.   If AD integration and Kerberos is used in the Intel AMT configuration, all applications connecting to Intel AMT should use a Kerberos or Domain credential.

     

    As an example of an application outside the McAfee ePO console, the McAfee KVM Viewer default setting for Intel AMT authentication is Kerberos.   Shown below, the current logged in user is vprodemo\itproadmin.   By default, McAfee KVM Viewer uses the current logged in account.
    Digest-Kerberos_pic8.png
    However, if a Digest credential is used in the environment, then the specific user and password must be provided in the McAfee KVM Viewer options
    Digest-Kerberos_pic9.png
    As stated at the beginning, either Digest or Kerberos authentication will accomplish the end goal.   As to which one you choose to utilize is really a question of your environment and needs.   Authentication via MD5 Digest will be simple and is a suggested starting point.   Authentication via Kerberos provides better interoperability and flexibility… and less credentials to remember.

    Concluding Thoughts

    Each communication to Intel AMT must be authenticated.   For initial testing of Intel AMT with McAfee ePO Deep Command, a Digest credential is recommended.   This will provide simplicity in understanding the features and capabilities of the solution.    For improved security and flexibility in a production environment, Kerberos authentication is often more desirable.  

    Additional Resources

     

    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