Troubleshooting Kerberos Authentication Failures
With the knowledge gained earlier, if experiencing issues in connecting the following information may help to remediate the situation.
Referring to the core communication architecture
The following image is an excerpt of the Active Directory Integration documentation in the Intel AMT SDK. The communication sequence shown in the image helps to reinforce some key points that will assist in troubleshooting and issue resolution.
Per steps 1 and 2, an HTTP POST request is sent to a client, and the response indicates that a negotiated authentication will be required. For the HTTP POST request to occur, the FQDN-to-IP resolution of the client is needed.
Per steps 3 and 4, the FQDN used for the HTTP POST is then utilized to request a session ticket from the Active Directory KDC (Key Distribution Center). This is in accordance to the Kerberos sequence for requesting a session ticket. Notice that the request is HTTP/FQDN:16992 (i.e. HTTP/e6400.vprodemo.com:16992). Per the previous section, this is the Service Principal Name (SPN) for the Intel AMT firmware for the target client
Once the session ticket is granted, steps 5 and 6 complete the Kerberos authentication sequence.
A simplified version of this sequence was shared at the beginning of this article series, and is repeated below for quick reference.
The Kerberos authentication sequence provides interoperability of solutions. The fortunate part for an Altiris deployment is that many of the intricacies and learnings around AD integration and Kerberos authentication can be shared from Microsoft SCCM deployments. As mentioned in previous sections, Microsoft SCCM requires Kerberos authentication and TLS encryption for 1-to-1 operations.
Steps to try in troubleshooting and remediating the situation
To the first point about key insights already obtained and how this might help in troubleshooting a Kerberos authentication problem, the following list was compiled based a Troubleshooting Guide for SCCM (click here) and other insights posted on Intel vPro Expert Center (click here)
- Access the WebUI via Internet Explorer (i.e. http://clientFQDN:16992 or https://clientFQDN:16993). When using Microsoft Internet Explorer to connect to the Intel AMT WebUI, enable Integrate Windows Authentication in the browser s Advanced Internet Options and restart the browser. Check the Intel AMT WebUI URL is specified using the client FQDN and not an IP address or other address alias otherwise Kerberos authentication will fail.
- Check the current Windows user (operating the WebUI or logged onto the Altiris console) is included in the Intel AMT ACL clients
- Check the current Windows user (operating the WebUI or logged onto the Altiris console) is not a member of a large number of Windows groups. Intel AMT limits Kerberos ticket size to approximately 4KB which equates to membership of approximately 30 windows groups (for more insight on how to use TOKENSZ and the potential impact of token sizes, click here)
- Logon\off of user will reset token\sid; thus if a user's group association is changed, that change may not take affect until an event occurs to cause token renewal
-
If after entering the credentials, you get re-prompted for the login or after 3 failed attempts a message that states – “log on failed. Incorrect user name or password…” – a very common reason is that an Internet Explorer registry setting is not in place. See
Microsoft KB 908209, specifically the post hotfix instructions. The file\software update is likely applied to the system, yet the associated\required registry key change is not. The download for the Microsoft KB includes a .reg file.
- KerbTray or KerbList utilities from Microsoft Windows Server 2003 resource kit can also be used to flush cached Kerberos tickets
- Check time synchronization scheduled tasks are completing via the Configuration Services Setting log entries
If connectivity via WebUI is responding correctly, ensure the Connection Profile within the Altiris 7 environment is configured correctly.
If connectivity via Kerberos was working correctly and then suddenly stopped, even WebUI is not responding correctly, yet all other configuration settings including AMT objects are configured correctly and FQDN is correct, check the exact version of Intel AMT firmware for a select client system. To obtain just the firmware version, use the GetAMTversion.exe utility posted at http://communities.intel.com/docs/DOC-4078. A more insightful utility is AMTSCAN (click here), or look for MEinfowin.exe.
Updates to the Intel AMT firmware are recommended if lower than the following versions. The firmware updates address some issues which were identified and fixed as they relate to Kerberos.
- Intel AMT 2 desktop - 2.2.10
- Intel AMT 2 laptop - 2.6.10
- Intel AMT 3 desktop - 3.2.10
- Intel AMT 4 laptop - 4.1.11
- Intel AMT 5 desktop - 5.1.10
Future releases of Intel AMT will include the necessary updates.
Managing changes to the FQDN of the client
The final troubleshooting point refers to one of the most common culprits of Intel AMT communication failure: the FQDN of the operating system has changed, yet the Intel AMT firmware FQDN setting or Intel SCS FQDN setting have not been updated.
The frequency of this event depends upon individual environments. In some situations, the first FQDN assigned to a system remains with it throughout. In other situations, the FQDN is changing constantly as a system is moved about within an environment. From an operating system and Altiris agent perspective, the change of the FQDN is automatically updated. If the client is joined to a Microsoft Active Directory domain, the change of the FQDN will require privileged domain credentials to be provided to update the computer object. There may be a brief gap as updates are propagated among the various applications and entities that need to know. During that time, FQDN-to-IP resolution may not exist.
Yet in respect to AD integration and Kerberos authentication as explained earlier for Intel AMT, an FQDN change can cause connectivity failures. The resolution can be server or client initiated.
Addressing this issue requires some background on the sequence of events and dependencies. The FQDN is recorded within the IntelAMT database, and the Intel SCS application uses this reference to query the DNS for resolution of FQDN-to-IP. However, if the FQDN is no longer known by the DNS, than the IP resolution will fail. Thus the IntelAMT database needs to be updated based on a script or event, and then a reprovision must be triggered to update the Intel AMT firmware on the respective client.
The Microsoft SCCM approach is to first schedule a full unprovision of Intel AMT, perform the FQDN changes until settled, and then reinitiate the configuration event. The following article explains this - Renaming AMT-Based Computers and Domain Changes in SCCM environment. Microsoft SCCM does not use Intel SCS, yet coded a similar configuration engine.
An Altiris environment can also take this approach, which is server based. The process would use the FQDN acquired by Altiris agent basic inventory. A replication or synchronization between the Symantec\Altiris and IntelAMT database is performed, and then a reprovision event is initiated. This approach can be scripted as discussed by Joel Smith in an Altiris 6 environment. See Handling vPro AMT FQDN Issues with Out of Band Management Solution. In Altiris 7, the same script could work and a pre-defined TaskServer job for FQDN update has been noted. See Four Insights to OOB Site Service Installation and Usage.
A client initiated approach can be accomplished with an advanced feature of Intel vPro Activator. Take a look at Provisioning of Intel® vPro™ Technology, Part 5: Intel vPro Activator Utility, specifically the brief reference to the /f option. This will require a Configuration Client role to be defined with a domain privileged account, and that account must be used to run the command on the client... in addition to having local administrative rights. It will send the FQDN updates to the Intel SCS web interface (AMTSCS), and initiate a reconfiguration event.
The client initiate approach was applied for this article. On the client system a domain privileged account ran the vPro Activator utility with /f option enabled. This generated an exit code of 0 (zero). Upon checking the list of Intel AMT systems, the FQDN update was applied. In addition, the existing AMT object inside the defined AMT_OU was also updated as shown in the logs below.
Concluding Thoughts
AD integration and Kerberos authentication for Intel AMT enables role based security and interoperability within a single Active Directory Forest environment. In approaching AD integration for Intel AMT in a Symantec environment, this article series has attempted to provide a complete perspective on the configuration settings, Active Directory objects, and common troubleshooting steps within a production environment. Although AD integration and Kerberos usage are not required for Intel AMT in a Symantec environment, the interoperability between client management solutions may necessitate such. In addition, role based security operations or preferences may require a complete audit trail of activities between users and services.
The material provided is a combination of documentation, experiences, and lab trials. The information was provided "as-is", and updates to the information may occur based on requests.
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 4: Configuring AD Integration and Kerberos Authentication for Intel vPro Technology