Sometimes it’s just easier to adopt a technology that you’re able to use “out-of-the-box” and don’t have to spend excessive amounts of time trying to get it to a configured and operational state. Bypassing some of the advanced configurations may be sufficient, as long as you are able to “take-control” of the situation at a future date.
Repeatedly setting up demonstration, training, and lab environments for Intel vPro may present a challenge in adjusting the Intel AMT firmware settings. From an "in-band" perspective - it's relatively easy and known how to re-image a group of systems - thus resetting the operating system state, application configuration, and so forth. However, mass resetting or management of the Intel AMT firmware remotely may not be as straight forward.
Another environment or situation to consider is when more than one management console is used. Does it matter which console owns the Intel AMT firmware configuration? What if the console used to configure the system is no longer available? Can you regain control of the system configuration?
Are there command-line tools to provide some management of the Intel AMT firmware?
What if an OEM or a value-added reseller (VAR) provisioned the client in a staging area totally separate from the production environment?
These questions are raised to help address a number of questions raised by customers and partners.
In my lab, I've left my Intel vPro systems in a "standard provisioned" state - meaning that they are enterprise provisioned, yet are not using Kerberos, TLS, or other advanced security configuration options. I am able to change out management consoles, re-associate or rediscover the clients that are Intel AMT capable and provisioned, and continue doing tests on associated usage models. A ProvisionServer or provisioning service is not needed - as the Intel AMT firmware is already provisioned. Should I need to regain control of the configuration within my present "ProvisionServer" - a few commandline tools or agents are used to adjust the environment accordingly.
If you've read this far - I apparently have your attention. Let me provide a few reference points and guidelines on how this is possible:
An initial provision event MUST occur on the system - be it a Basic or Standard provisioning event which is manual or automated.
Once an Intel vPro\AMT system is provisioned - authenticated and authorized requests can be accepted from any source using the defined admin account credentials
Authentication\authorization of requests - at the basic level - is done via a Digest username\password
Commandline utilities such as Intel AMT Reflector Utility or UnprovisionEX (see http://communities.intel.com/openport/docs/DOC-1171) allow for remotely adjusting basic or standard provisioning settings – including remotely UnProvisioning the Intel AMT firmware. Some consoles – such as Altiris – also include a remote unprovision capability (see http://juice.altiris.com/node/4640).
Note: If you have a ProvisionServer already defined, make use of it to change configurations and settings. These tools and insights are provided for situations where the original ProvisionServer is no longer available and you want to adjust settings without physically touching the client.
If an environment is using TLS or Kerberos and the former management console is not longer available – the new console must be a member of the same Active Directory domain and have the root certificate used by TLS in it’s local certificate store.
Management consoles must support network discovery or agent based discovery of Intel vPro systems already in a provisioned state (Basic or Standard – see Understanding Provisioning Models - Basic, Standard, & Advanced). For an example of agent based remote discovery – see http://juice.altiris.com/node/4638
The consoles must be configured with the known digest username\password. This unfortunately excludes Microsoft SCCM – as it requires TLS and Kerberos. Other common consoles and interfaces have options to both discover and connect to clients using Digest authentication (i.e. Altiris, LANDesk, HP Openview, SupportSoft, Intel System Defense Utility, etc)
In support of the above ideas and conditions, the following scenarios could be supported without any
“ProvisionServer”:
An OEM or VAR provisions a set of systems before shipping them to a customer. Upon arrival, the IT administrator adjusts the management console configuration with the OEM or VAR provided credentials used, and continues with normal deployment activities. Once the systems are on the network, a network scan or agent based discovery of the Intel AMT capabilities updates the management console, and the IT administrator now has full use-case functionality of the out-of-band technology as supported by the host management console. (NOTE: No mention of ProvisionServer, Intel vPro provisioning process, etc)
In deploying the systems, the hostname of the operating system does not match the hostname of the Intel AMT firmware. Using the Intel AMT Reflector Utility, the administrator sends out a single command script to all clients. (This assumes the “server” component of the utility is running on a single system separate from the Intel vPro clients, and that the Intel vPro clients have the Intel AMT reflector client console executable and associated DLLs local). An example of the single command sent to all clients for synchronizing the host operating system and Intel AMT firmware name is:
Reflector –user admin –password P@ssw0rd –server vprodemodc.vprodemo.com –port 16992 –syncFQDN> > Note: This utility must be run locally on the Intel vPro\AMT client, as it will obtain the local FQDN before transmitting to the Intel vPro Reflector Server component. If you have an existing ProvisionServer in the environment – do NOT use this tool. Utilize the FQDN synchronization option of the ProvisionServer, such as the /f option with the Intel vPro Activator Utility for Intel SCS based environments.
Not feeling comfortable with the OEM\VAR preset values of Intel AMT admin firmware username and password, the IT administrator wants to remotely change these credentials. Instead of the default username of “admin”, the IT administrator wishes to use “PCSupport” with an associated strong password. This could be handled via the WebUI, supporting management consoles, or via commandline script. The following example uses the Intel AMT reflector utility from the management system to the Intel vPro client:
Reflector –user admin –pass P@ssw0rd –server –vProSystems1.vprodemo.com –port 16992 –setAdminCred –newUsername PCsupport –newPassword Pr0t3ct!0n
Finally, a situation occurs where the IT administrator wishes to transfer or take control of the provisioning process with a designated ProvisionServer. The preference is not to physically touch any of the systems to make this adjustment – thus the requirements of remote configuration must be met (i.e. support by the management console running ProvisionServer, remote configuration certificate obtained and installed, etc).
Using the Intel AMT Reflector or UnprovisionEX utility (see http://communities.intel.com/openport/docs/DOC-1171), the IT administrator executes a command to remotely unprovision the Intel AMT firmware and reset to a factory default state. (As noted in the linked article above, some management consoles may have this capability already built in). Once the target systems or group of systems have been unprovisioned, a provisioning event can be initiated via the Intel vPro Activator Utility, supporting management console agent, or related methods.
All of the above scenarios and situations have been proven out in a lab environment – mostly out of necessity as I desired to automate procedures a little (resetting an environment a few times a week or month becomes exhausting, thus my quest to find methods or simplification). Although my lab is only 10 systems, the concepts have been applied to large lab, testing, and training environments.
Do you have additional ideas or inputs on this topic?
A final thought – since a majority of the initial deployments of Intel vPro are pilot or limited test situations, the advanced security features are not the initial focus. The initial focus is on the usage and applicability of the technology within a target environment. Unfortunately, getting the initial setup or provision event to occur presents an upfront hurdle which many have overcome… yet would have preferred to sidestep. What if during the pre-staging of the equipment the firmware was put into a Basic or Standard provisioned state (again – no TLS, no Kerberos, no 802.1x - see Understanding Provisioning Models - Basic, Standard, & Advanced). Wouldn’t this help get to the desired state of using the technology – allowing time to gain a better understanding first? If at a later time the IT administrator wants to setup a ProvisionServer and own the configuration – then the process could be done remotely via command scripts, agents, and so forth.
Open to comments, criticisms, corrections, or alternative viewpoints out there…
