More Insight on the AMT object
As Intel AMT systems are provisioned into the environment with Active Directory integration enabled, the list of objects within the defined AMT OU will grow. Each object will be named based on the reported FQDN at the time of configuration. If the Active Directory object differs from the reported FQDN, a mismatch may occur. In a commonly configured Altiris environment, the FQDN used at the time of Intel AMT provisioning is obtained from the Altiris management database or the resolved IP-to-FQDN address. Thus if a mismatch does occur, check to ensure the correct FQDN is being reported in the infrastructure.
The recorded FQDN in the IntelAMT database will used when attempting to create, update, or delete Intel AMT objects. In Altiris 7, a TaskServer job is predefined to synchronize the FQDN based on the Symantec\Altiris management database and IntelAMT database. A scripted approach was also posted.
Two computer objects exist per system. The difference between the two objects is one refers to the physical computer as reported by the operating system; the second refers to the Intel Management Engine service within the physical computer. The details of the Computer Object Name, Service-Principal-Name (SPN) and User-Principal-Name (UPN) help to further differentiate the operating system versus management firmware related objects in the Microsoft Active Directory.
In the following screen, the details of the AMT object show the Computer name is actually e6400$iME. The $iME identifies this object as related to Intel Management Engine, the out-of-band management service in the firmware of the target computer.
The object is shown to be of a Computer object class, yet some distinct differences may not be apparent in the shown object properties.
For example, the AMT object is a member of the Domain User Global group, as shown in the image below. This association occurs at the time of creation, and as a member of the users group the object will be replicated and accessible to all domain controllers in the Active Directory forest.
Those administrating the Active Directory environment will want to be aware that Computer objects will start to appear in their Domain Users Global Group, specifically with a primaryGroupID of 513. To support the previous statement, the following screen shows what might appear as a computer object in the Global Domain Users group.
In the following screens, Active Directory Explorer was used to view the exact details of the two computer objects. Active Directory Explorer is a free download from Microsoft TechNet, available at http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx.
The first screen shows the computer object associated to the operating system on the target client. This is the first computer object created due to joining the client operating system to the Active Directory domain.
The next screen shows the computer object which references the Intel Management Engine due to the Active Directory integration setting described earlier. At first glance, the two computer objects may appear to be exactly the same. Upon closer inspection a few key elements are different, as noted in the following list:
- sAMAccoutName differs with "$iME" after the hostname (i.e. e6400$iME), thus referring to a service on the remote system.
- primaryGroupID differs between 515 and 513 (Domain Computer and Domain User groups)
- servicePrincipalName differs with the iME object specifying the Intel AMT network ports, and referring to an HTTP address instead of a HOST address (i.e. HTTP/e6400.vprodemo.com:16992).
- userPrincipalName does not exist in the first example, yet does in the second. This is another indication that the second computer object is a user, or rather a service, to which authentication can occur.
- Operating system details exist only in the first computer object, and not the second. Yet another indication that the first object refers to the operating system, while the second object refers to a service outside of the operating system.
The differences yet interrelation between the computer object and the AMT object helps to reinforce some common items:
- Changes to the FQDN in the host operating system without updating the AMT object will cause a connectivity failure, especially if the DNS resolution for FQDN-to-IP is incorrect. The iME service as described by the SPN may become unreachable for Kerberos authentication.
- Authentication to the AMT object requires use of the FQDN and Intel AMT network port. The Altiris 7 environment will attempt this automatically. If using the WebUI to directly access a system, the FQDN and Intel AMT port number must be specified.
A final note on the Intel AMT object with the associated configuration settings in place. The AMTconfig service account was delegated both create and delete permissions to the computer objects in the AMT OU. As shown in the following screen, the AMT object is cleared after a full unconfiguration event handled by the AMTconfig service.
With the material provided in this and previous sections, successful AD integration with Kerberos authentication can be obtained. Yet due to variance of situations on infrastructure or processes, errors may occur as with any technology. The final section provides more insights and details on troubleshooting Kerberos authentication failures.
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
Part 3: Configuring AD Integration and Kerberos Authentication for Intel vPro Technology
Part 5: Configuring AD Integration and Kerberos Authentication for Intel vPro Technology