Intel® System Defense Utility is an easy to use tool for small and medium businesses to take advantage of valuable proactive security and manageability features of Intel® vPro™ processor technology. Combined with systems built on Intel® Desktop Boards Executive Series, this tool lets you unleash the power of proactive management in your local network.
It enables you to remotely perform security and manageability functions such as setting security policies, BIOS configuration, remote reboot, asset management, event logging, and more.
People often say to me - "I've got encryption, so I'm protected," or "I always use a laptop lock," so I'm protected.
In response I always remind them that laptop security should be looked at like a three-legged stool. If any of the three legs are missing, the stool falls over (unless the person on the stool is a member of the Beijing Circus, but that's a rare exception).
What are the three legs?
The first leg is Physical Security, like a laptop lock and/or an alarm on your laptop bag. If you're leaving your machine, lock it down!
The second leg is Data Protection like encryption. If your machine does get out of your control and someone nefarious removes your hard drive, you can be "reasonably" confident they won't get at your data. (I say "reasonably" because we've all seen the laptops at airports on in presentations where the password is written on a sticky note stuck to the machine!)
The third and final leg on the stool is a Protection Solution like AT-p. If your machine fails to check in to the monitoring center after a certain length of time then presto it bricks. Or if you know your machine is lost you can send it a poison pill and lock it down.
I've updated the vPro-ready systems that are available from Panasonic. These include the fully rugged, business rugged, and semi-rugged notebooks. John Hilliker just blogged about the Park and Patch use case which features the CF-19. The full line of Panasonic Toughbook notebook computers available with vPro is shown here: http://communities.intel.com/docs/DOC-2033#Panasonic. In case it isn't clear from the list, all CF-19K and CF-19L series (CF-19Mk3), CF-30K and CF-30L series (CF-30Mk3), and the CF-T8, CF-W8, and CF-F8 come standard with vPro.
I have finally finished the Park N Patch Use case on how you can leverage a Management console and Intel vPro Technology. In this example I am using Symantec Management Console and a Panasonic CF-19 toughbook.
Intel has been working with various companies on implementing the concept of Dynamic Virtual Clients. Driven by the need to control costs of desktop management, Providence Health & Services – Oregon (PH&S – Oregon) recently undertook an initiative to gain greater control and standardization of desktop configurations, while providing performance and flexibility to meet business unit needs. Goals for this initiative included maximizing system availability, reducing operating costs, increasing security, and better using IT time and resources to support business strategies rather than day-to-day maintenance.
After evaluating various computing models, including virtual desktop infrastructure (VDI), blade computing, and terminal services, PH&S – Oregon deployed a pilot solution with streamed delivery of a centralized OS image using Citrix Provisioning Server* (Citrix PVS) along with application streaming and virtualization using Microsoft SoftGrid,* now called Microsoft Application Virtualization* (Microsoft App-V).
For PH&S – Oregon, this solution offered the lowest cost of ownership for both conversion and operation, met management and security requirements, and met or exceeded user expectations for boot time, application launch times, and performance.
When we first got back to the drawing board and thought about new SCS Architecture, for SCS6.0, we had several things in mind.
It was clear that the existing provisioning flow (end to end)had to be simplified – Feedbacks from the field, showed that the required IT setup and configuration interaction required steep vPro specific learning curve, even before the actual provisioning process that happens through the SCS tool.
We also realized that in order to improve the ISV integration we had to listen to Key ISVs’ trends. Some of them requested the ability to configure vPro from the local host while others - SMB/MSP ISVs had different needs.
Interoperability and scalabilitywere also 2 focus items when we started the new design.
The plan was to hit the road with a new agile development methodology – SCRUM.
In parallel, we decided to break the setup and configuration logic into different components that ISVs can use as their building blocks.
This new architecture allows ISVs greater flexibility in order to provide a more integrated solution that will be easier to use by IT administrators, or on the other hand, can be used by small scale ISV who are not interested to deal with provisioning as part of their offering.
Let the SCRUM begin!
SCRUM is defined as agile development process that allows teams to deliver usable software periodically throughout the life of the project, absorbing change and new requirements as the project proceeds.
Working agile for us, meant being able to divide the SCS deliverables into short iterations (“sprints” ) and by the end of each sprint be able to provide “potentially shippable” product - Something that can be actually used by the customers.
This way, in an incremental effort, we are sharing more features andhigh quality releases on a regular basis.
This is how the SMB requirements started floating around. First, through several email threads and then, after the team looked at the requests, they all said: “Yes we can!”
In an effort to reduce the number of tools trying to solve similar problems to the customers, and in reality only adding to the confusion, we defined the following milestones for SCS6.0:
•Release #4 - Q4’09 (ww45’09) - SCS 6.0 Final - AMT6 Features Support
The Lightweight provisioning and the SMB provisioning story
The recent technology preview provides a lightweight solution aimed for small and medium business (SMB) customers. In the spirit of the SCS 6.0 approach, pre-requisites were reduced to minimum: No DB is needed (XML based solution is the alternative), No configuration is needed - Profile is ready. It can be installed on any windows based host, No prerequisites from the “server” and … Low footprint on the host system.
In only 3 simple steps, that take only few minutes, the user can now configure the machine (with or without PSK).
All that is required is:
•User step 1: IT installs SCS 6.0 LW with default profile out of the box
•User step 2: IT buys RCFG certificate
•User step 3: IT remotely distribute host based Activator (Through existing Management consoles that are out there already, in the organization)
Or … with PSK:
•User step 1: IT installs SCS 6.0 LW with default profile out of the box
•User step 2: IT remotely distribute host based activator
•User step 3: IT admin creates USB file containing PSK/PID pair to be consumed by the Intel® AMT (One touch end-user restart is required)
Lastly, there is also an option to do Local USB key configuration through the Activator’s GUI in SCS 6.0. This manual configuration takes 2 steps:
•User step 1: User insert USB key containing GUI Activator SCS 6.0 application
•SCS Activator Determine Local AMT State
•SCS Activator creates setup.bin file containing all information needed to configure the system (using user input regarding password and information if no DHCP is present)
•SCS Activator formats the USB key then copies both setup.bin file and the Activator application to the disk again.
•User Step 2: USB Key – Reboot & Approve
•End User Shut Down Applications and Reboot PC
•End User “Approve” BIOS AMT Provisioning Process
Under the hood
For those interested to know what’s going on under the hood, the new SCS6.0 technology preview #1 contains 3 elements:
• AMT Configuration Server Service — A Windows service (known as the SCS service) performs the steps required to make an Intel AMT system operational. (This includes Intel AMT Release 2.0 and later releases.) The configuration is determined by a configuration profile stored in an xml file. The SCS service exposes a WMI interface for managing the configuration file, creating and importing USB keys and performing configurations (see the MOF API section for details on the interface). The SCS service writes log messages to a file.
• Intel® vPro™ Technology Activator Utility — This application runs on an Intel® AMT system. It performs a diagnosis of the current state of the Intel AMT system and triggers the SCS (via its WMI interface) to perform configuration or unconfiguration.
• SCS Console— A GUI application for managing the SCS configuration profiles and creating and importing USB keys via the SCS WMI interface.
The new technology will be demonstrated in 2009 ISMC, but you also have the ability to download it and experience it yourself. The ease of use ofthe Intel® AMT Setup and Configuration Service (SCS) 6.0 first Technology Preview can be checked here:
If you extract out the Activator directory - the exe and dll files are what you want. Test it out on a system. The command is as follows:
You will notice the system's network connection disconnect\reconnect during the transition. Once complete - you're system is not set to AMT manageability mode. If the system supports remote configuration (Intel AMT 2.2, 2.6, 3.x or higher), and your infrasrtucture is ready to support remote configuration, then you can immediate start the provisioning event.
Last year I had an opportunity to talk with GB about vPro, I was able to do the same this year & spend a few moments with him on 3 questions. In this first series he talks about vPro in 2009. Listen in & let me know what you think..
Curious about how Intel vPro and Symantec’s Altiris software work together? Using Symantec’s Altiris CMS to manage your vPro machines? Or, are you somewhere in between? In either case, the Symantec SP Zone was designed for you. The new vPro Expert community houses info that offers a better understanding of the products, describes how others are benefiting from the combined solution and, can help you get up and running.
So check it out, post a blog or start a discussion.
Intel has been working with various companies on implementing the concept of Dynamic Virtual Clients.Driven by the need to stay competitive under brutally challenging market conditions, a globalfinancial services firm has mounted an innovative “stateless” desktop virtualization initiative,using streaming OS and application technology to make IT more agile and cost-effective.(The firm wishes to remain anonymous.)
In a previous effort to control desktop management costs for over 100,000 workstations, the firm implemented a solution based on VDI, which did not work well for certain segments – the power users and some knowledge workers. VDI also did not solve the underlying complexity issue of managing at least one desktop image for each user. To service the power users and provide a solution for centralized desktop image management, the firm implemented a “stateless client” architecture that centralized management and distribution of desktop images through real-time streaming technology, deployed on economical, scalable PCs or “virtual thin desktops.”
The firm’s stateless solution assembles desktop images on the fly from a set of master OS images combined with virtualized, streamed applications. This solution combines the security and control of server-based models with the high performance and multimedia user experience offered by rich client workstations.
Microsoft has just released Hotfix KB960804. This is ahotfix rollup package that addresses issues that involve the Out of Band Management (OOB) feature in Microsoft System Center Configuration Manager 2007 Service Pack 1 (SP1). These issues are documented in the following Microsoft Knowledge Base articles: (Even if you have all or some of the other Hotfixes installed that are included in this rolled up HotFix, it is recommended that you installKB960804Roll-up Hotfix)
954718: You cannot use the Out of Band Management console in Configuration Manager 2007 to connect to computers that use versions of Intel AMT that are earlier than version 3.2.1
955114: The SMS_Executive service process may crash when the System Center Configuration Manager 2007 SP1 Hierarchy Manager handles the site control (.ct2) file from child sites that are running the RTM version of Configuration Manager 2007
955126: The SMS_Executive service process (Smsexec.exe) in System Center Configuration Manager 2007 may crash if you have Intel AMT-related software installed
955355: A distinguished name that contains more than 100 characters and that is discovered from Active Directory for an AMT host causes the SMS_EXECUTIVE service to crash in System Center Configuration Manager 2007
956337: System Center Configuration Manager 2007 Service Pack 1 is unable to remove AMT user ACLs during the provisioning process for AMT 2.x computers
957183: You cannot add a group as an AMT user account in Configuration Manager 2007 Service Pack 1 if the group name has more than 20 characters
957469: The Out of Band Power control function does not work for clients that have the Intel AMT 4 or Intel AMT 5 chipset in System Center Configuration Manager 2007 Service Pack 1
959700: The Out of Band Management console in Configuration Manager 2007 Service Pack 1 cannot connect to AMT-enabled computers
960741: The SMS_Executive service process crashes on a Configuration Manager 2007 Service Pack 1 site server when you use Intel WS-MAN Translator to provision computers that are equipped with AMT 3.2.1 chipsets
961328: System Center Configuration Manager 2007 Service Pack 1-based systems cannot provision AMT 2.2/2.6 clients in PKI mode and AMT 2.1/2.5 clients in PSK mode
Intel has been working with various companies on implementing the concept of Dynamic Virtual Clients. As innovators among Harvard University’s IT community, the School of Engineering and Applies Sciences (SEAS) is an ideal environment for implementation of Application Streaming technology. Within SEAS, the office of Computing and Information Technology’s (CIT) CyberInfrastructure Labs (CI Labs) supports faculty, researchers, students, and staff by deploying and maintaining up-to-date, effective computing technologies.
With application streaming, applications are streamed on demand from the data center to the client, where they are executed locally. The goal of the scientific application streaming project, as outlined in the attached white paper, is to simplify the deployment of large, complex engineering and scientific applications to a highly diverse user population of around 1,000 students and faculty.
Initial results show install times decreasing from hours to minutes, as well as fewer problems caused by human error during complex installation and licensing procedures. As innovators among Harvard’s IT community, the CI Labs anticipates wider implementation of application streaming, both within its user base and across Harvard.
The release of the Notification Server 7.0 platform will provide a new design and infrastructure. Out of Band Management will also provide a new release with this platform. First I’ll provide a brief description of what Out of Band Management is used for. This article will also cover the differences between the 6.2 version of Out of Band and version 7.0. The changes include UI improvements, relabeling to be in line with current Intel terms, and the addition of limited Dash support.
Out of Band Management 7.0 allows an administrator or IT Professional to setup and configure several protocol technologies for use in the greater Notification Server infrastructure, or even any other solution that supports the protocols handled by Out of Band Management. The supported technologies are:
Intel AMT (Active Management Technology) or vPro
ASF (Alerts Standard Format) primarily from Broadcom
DASH technology support (open architecture)
The greater focus is on Intel’s AMT technology. Using the provided configuration pieces with Out of Band, systems with the above technologies can be configured to respond to functions called from either the RTSM interface or via Task Server. Once configured, the Notification Server is a trusted entity to the local systems and all available functions are available.
It’s important to understand the changes in terminology and labeling so the transition from 6.2 to 7.0 Out of Band Management goes smoothly. This section will also help explain the naming scheme for Out of Band Management. The following list provides the term, and the previous label (if different), and a brief description:
Configuration, AKA Setup and Configuration – Previous term: Provisioning – Intel has standardized on using Configuration as the term for activating a vPro system. This more aligns with what is occurring and avoids confusion with basic industry understanding of what provisioning means (putting an OS on the system). NOTE: Since this word is used throughout documentation for 6.x it is important to understand the change!
TLS – Transport Layer Security can be considered the next generation of SSL (Secure Sockets Layer). It’s used in 2 sections of Configuration: Remote Configuration authentication, and TLS within the Configuration Profile.
Remote Configuration – This specifically means the process for automatic Configuration via the handshake with a TLS certificate, usually purchased from Verisign, GoDaddy, Comodo.
Out of Band Portal
Out of Band Management now has a Portal page that provides access to most function from a user-friendly UI. It’s accessed in the Symantec Management Console by going to Home > Remote Management > and click on Out of Band Management. The following screenshot shows a view of the portal:
The upper left-hand pane shows a list of setting groups that will enable a user to go through those steps necessary to enable or complete Out of Band setup and configurations. Please note the following items and what they can be used for:
Configuration Service Settings – This provides all the nodes that are used in the Setup and Configuration process for AMT.
Basic Configuration (without TLS) – This takes you through the process of setting up Configuration where TLS will not be used in the Configuration Profile (not to be confused with Remote Configuration TLS). See this screenshot for the way the steps are setup:
Enable Remote Configuration – This walks you through setting up the Notification Server to accept Configuration requests using TLS certificates. Note that 2.6, 3.0+ AMT systems are automatically configured to send out requests using this method.
Enable Security (TLS) – This walks you through setting up the Notification Server to use TLS when managing AMT systems.
Intel AMT Tasks – This is a quick area that reveals the Task Server tasks that directly utilize AMT.
Configure Site Server – This is a link that opens the Site Server Configuration page as part of the Notification Server Platform. This is available here because OOB has a Site Service that can be deployed to Site Servers.
As a note, Site Servers allow distribution of Out of Band functions across the environment, and helps alleviate any problems with large rollouts involving a large amount of Configuration. This brings us closer to having true hierarchy support with Out of Band Management.
Those who are familiar with Out of Band Management 6.2 can use this section to find corresponding functions, configuration pages, and utilities when upgrading to Out of Band 7.0. If you are unfamiliar with this version skip to the next section.
Out of Band Management looks much the same as it did in 6.2, with some notable exceptions. The following items cover the differences between the two. The method used to reach the console area for Out of Band Management is as follows: Browse down through Settings > All Settings > in the left-hand tree browse down through Remote Management > Out of Band Management. The three subfolders are by the same name as they were in 6.2, lacking the fourth folder: Delayed Provisioning.
*Provisioning > Configuration – I called this out previously in this article but with my experience the double-exposure is necessary. In reference to managing vPro AMT systems, consider the previously used term Provisioning to now be Configuring, or Provision to now be Configuration. If you’re like me and have the word provisioning ingrained in your mind, it will take some getting used to.
Auxiliary Profiles – Three new nodes have been added to this folder. They are described below:
Management Presence Server – (MPS) This is the secure gateway CIRA technology will use to connect securely with the network where the NS resides for remote management from anywhere on the Internet.
Remote Access Policies – In relation to the above MPS, this policy dictates how CIRA connections are handled by the Notification Server.
Trusted Root Certificates – Also in relation to MPS, these are required to establish so that trust can be formed from the calling AMT system, the MPS, and the Notification Server.
Configuration Profiles – Formerly known as Provision Profiles. The following items have been added as tabs within the profile configuration. Descriptions of the items are supplied as well:
Domains – Allows the ability to configure AMT to operate in more than one Domain.
Remote Access – This ties directly to the Remote Access Policies found under the Auxiliary Profiles node. Edits here will take effect in both places.
The remaining nodes under the Configuration Service Settings folder are the same between versions 6.2 and 7.0.
Delayed Setup and Configuration – Formerly known as Delayed Provisioning, this has been renamed to fit the proper naming convention. It also no longer has its own folder, but can be found under the Intel® AMT Systems folder above the Intel AMT Systems node.
The following screenshot shows the layout of the console:
The component that Out of Band Management plugs into has not changed between versions. Intel SCS (Setup and Configuration Services) is still the backbone of Out of Band, and handles all the transactions between the server and the remote Intel AMT clients during the Configuration process. Please note that management functions of AMT are NOT handled by Intel SCS. SCS stands for only the Configuration process, including maintenance and reconfiguration tasks (for example for profile updates) as part of maintaining the configured state.
Out of Band Management 6.2 used Intel SCS version 3.0 (or 3.2.1 per the Knowledgebase article found at this location:https://kb.altiris.com/article.asp?article=40076&p=1). Intel SCS version 5.0 ships with Out of Band Management. While the UI does not reveal all the additional capabilities, SCS 5.0 comes with a tool called Activator. This utility can handle a number of scenarios that were sticky points in the previous versions of Out of Band and Intel SCS. The abilities include the following:
FQDN Name Change – The Activator, when run on the local AMT system, can tell AMT to send updated information to Intel SCS on its FQDN. This is especially important if the FQDN has changed in Windows, thus changing the identity of the machine.
The problems associated with this are the failure of AMT systems to authenticate using TLS due to FQDN sensitivity if enabled, and also the inability of Intel SCS to contact back a system whose FQDN has changed.
Resending of Hello Packets – While the 3.0 version of Out of Band had the ability to send Hello packets using the Delayed Provisioning (AKA Delayed Configuration) task, it did not have the ability to send PSK (pre shared keys) packets if the 24 hour cycle of the hello packets sequence expires. This functionality was also added to verison 3.2.1 of Intel SCS.
The problems associated with this are when systems are not configured within that 24-hour cycle they need to be acted upon to get the needed information to the server for configuration.
The above two functions can be utilized by sending Activator down using a Delivery Software job in the Software Management Solution.
Hopefully this introduction will help those familiar with Intel vPro, and especially familiar with Out of Band Management in the Notification Server 6.0 infrastructure, to understand the changes and functions in version 7.0 of Out of Band Management. In depth articles will be generated in the future to cover some of the new features such as the MPS and CIRA functionality.
If you want to have the Intel Manageability Tool Kit interoperate with a vPro client that has been provisioned by Microsoft System Center Configuration Manager SP1, there are two key things you need to do: Configure Manageability Commander to trust the Issuing Certificate Authority of AMT Web Certificates and to authenticate with a Kerberos user that has access to the vPro Client.
Before configuring Manageability Commander, you will need to obtain a copy of the Root Certificate Authority Certificate that the vPro Client AMT Web Server Certificate was issued from. This is the same Certificate Authority that was configured in “Microsoft System Center Configuration Manager Console” -> “Out of Band Component Configuration” -> "Site Database" -> "Site Management" -> "Site" -> "Site Settings" -> "Component Configuration" -> "Out of Band Management" -> "General Tab" -> "Certificate Template".
If you are issuing AMT Web Server Certificates from a subordinate certificate authority, you should still use the certificate from the Root Certificate Authority the SubCA is chained up to.
Export a copy of the Root CA
1)To export of a copy of the Root CA Certificate, you can open your local certificate store, select “Trusted Root Certificate” -> “Certificate” and search for the proper Root CA Certificate. If you do not have the Root CA certificate in your trusted root store, your CA Administrator can obtain a copy for you from the CA by selecting the “Properties” of the Certificate Authority and selecting “View Certificate”.
2)Once you have the certificate open, select the “Detail” tab and then select “Copy to File”.
3)When the “Certificate Export Wizard” appears, click “Next”.
4)Select “DER encoded binary X.509(.CER)” and click “Next”.
5)Select a location to export the certificate to and then click “Next”.
6)On the “Complete the Certificate Export Wizard”, click ‘Finish”.
Trusting your Root Certificate Authority in Manageability Commander
Now that you have a copy of the Root CA certificate, you are able to configure Manageability Commander so that it can manage a vPro client provisioned by SCCM.
2)Once Manageability Tool Kit is install and Manageability Commander is open, select “File” -> “Certificate Manager”.
3)In the “Certificate Manager” window, ensure you delete all other existing certificates by highlighting them and clicking the “Delete” button. After which, select “Import”.
4)Browse for the Root Certificate Authority Certificate you exported (which is the Root CA Certificate that is chained up from your AMT Web Server certificates) and click “Open”.
5)Back in the “Certificate Manager” window, click the “Refresh Displayed Certificates” button. You should now see your CA in the “Trusted Root Certificates” list. Click “Close” to exit the Certificate Manager window.
Adding a Client to Manageability Commander
Once the Root CA certificate has been trusted, you can now add the client (that is provisioned by SCCM) you want to manage via Manageability Commander.
1)To add the vPro client, select “File” -> “Add” -> “Add Intel® AMT Computer”.
2)When the “Add Intel® AMT Computer” window appears, enter in the full qualified domain name (FQDN) of the client you want to manage. If you want Manageability Commander to use Kerberos authentication of the local user logged, leave the Username and Password blank. If you want to specify a different Kerberos user then the local logged on user, enter in the desired Kerberos user as domain\user and the appropriate password. Click “OK” to close the “Add Intel® AMT Computer” window.
3)Once you have added the vPro client, you should see it in the list of clients to manage. Right click on the client, and select “Connect”.
4)Once connected, you can invoke any of the vPro / AMT use cases that the Manageability Commander Tool supports on the client provisioned and also managed by SCCM.
If you are having connection issue, you can perform some general troubleshoot by viewing the debug information.
A recent discovery (thank you Frank) of Intel Proset that may impact your ability to wireless manage your vPro systems. While I realize this may impact a very small group of folks I still believe it's valueable to post out. Here's the issue if you have users log out of their notebook system and leave it powered on windows, while utilizing Intel Proset you may loose control of the machine for vPro management.
Need to be sure this box is checked. It’s part of the properties for the wireless profile. Note, Microsoft Zero Configuration has this set by default. Hopefully this helps if you run into this problem.
The new generation of notebook PCs with Intel vPro technology includes Intel Anti-Theft Technology PC Protection (Intel AT-p). Intel AT-p offers you the option of activating hardware-based client-side intelligence to secure the PC and data if a notebook is lost or stolen. Because the technology is built into PC hardware, it provides local, tamper-resistant defense that works even if the OS is re-imaged, a new hard-drive is installed, or the notebook is not connected to the network.
In the following we describe an example of how this technology is deployed and used in the life of a typical employee working for a security conscious company. Consider a user Jane who is a new employee of a company called SecureBank. SecureBank wants all its employees laptops to be protected against theft and is therefore utilizing the Intel® vPro Anti-Theft Technology for Asset Protection (AT-p) with Absolute ISV.
In particular Jane has two (rather adventurous) days –
-Day 1:IT admin receives a new laptop and sets it up for Jane. Jane uses the new laptop for the day when she receives her new laptop and manages to loose it to a thief!
-Day 2:the thief is unable to use the laptop due to the poison pill sent as a feature of the AT-p technology. The thief therefore gives up on it and leaves it in a coffee shop. The laptop is subsequently recovered by SecureBank, made functional again and is ready to be handed over to Jane.
The IT admin receives a new laptop and creates the SecureBank IT image on the laptop. This includes the Absolute agent which would be used for AT-p. The Absolute Client Windows Installer is a part of the IT image. The two key steps are undertaken -
-Enrollment:The IT admin runs the Absolute Client Windows Installer which installs the Absolute agent on the client. As part of the installation this client is enrolled with the Absolute server. Enrollment consists of the following steps –
1.The Absolute Agent checks the local platform to ensure that the platform is eligible for Intel® AT-p.
2.The Agent requests permission of activate AT-p with the ISV Server i.e. the Absolute Server.
3.The ISV Server takes this unique client request and sends it (along with a license key) to the Intel permit signing server.
4.Once the Intel signing server has validated this request, an AT-p permit is generated for that unique client. The client system is now ready to validate signed messages from the ISV server.
Once the machine is enrolled it shows up on the administrator console. The machine is identified using a unique identifier generated by the Absolute server, Detected Full Computer Name and Detected Serial Number. At this point a default policy for the client machine is also applied.
-Policy Setup:The IT admin can also fine tune the policy for Jane. Examples of Attributes he can set include:
AT-p Timer Value
The machine’s disablement timer (time after which the machine is disabled if it does not connect with the server) is 48 hours.
AT-p Timer Action
The action a machine performs once the AT-p Timer has expired. In this case, the machine will shut down immediately (even if OS was up and running) and not allow the boot process to be carried out.
AT-p Theft Action
The action a machine performs once the machine is marked stolen when connecting with the server. In this case, the machine will shut down immediately, same as above.
Admin Password used to recover the machine when it is disabled or locked.
Marks whether AT-p is currently active or not on a machine. When it has a legitimate working user then it is marked as active.
Marks whether the machine is stolen or secure. In this case, the machine is not stolen.
Once the IT admin has set the above policy he is ready to hand over the laptop to Jane.
(2) Normal Usage:
On receiving her new Laptop, Jane logs in with her domain credentials and uses it seamlessly (as if there were no AT-p). The rendezvous may occur without any active participation of Jane. As such the rendezvous happens in the background and is transparent to Jane.
- Rendezvous (Machine Not Stolen) The Absolute solution has a rendezvous timer of 24.5 hours. After this time the following steps would occur –
1.As the Rendezvous Timer (24.5 hours) expires the ISV Client Agent initializes a rendezvous.
2.The ISV Server’s response is relayed to the Intel Management Engine (in the firmware) through the ISV Client Agent. Any new settings are relayed.
3.Acknowledgments are generated for any message received.
4.Once finished, the Disablement Timer (or AT-p Timer) reset message is sent to the Intel Management Engine.
After a good first day of work, Jane’s colleagues take her out for a dinner. She leaves her laptop in the car and heads to the restaurant. To Jane’s bad luck her car is broken into and the notorious thief steals her laptop.
- Malicious Usage: The thief has a hacking tool that allows bypassing the windows login/password challenge and can use the laptop. He feels he can make a good fortune by selling this laptop in the black-market.
- Theft Reporting: When Jane returns to the car, she is shocked to see her car broken into and her laptop stolen. She immediately calls the IT admin helpdesk and reports the theft. The IT admin sets the Theft Status to Stolen. Next time the laptop checks in with the Absolute server, the Theft Action, which is Immediate Lock, will take place.
(4) Poison Pill:
The attacker logs in again using his hacking tool. Since it is past 24.5 hours (i.e. the rendezvous timer has expired) the agent initiates a rendezvous. At this time the following steps happen -
- Rendezvous (Machine Stolen)
As the rendezvous timer expires the ISV Client Agent initializes a rendezvous.
The server has marked the system as stolen, and sends an AssertStolen message (“Poison Pill”) to the system.
The local system takes action based on the current policy.
As the action is to immediately lock, the thief to his surprise observes that the machine just shuts down. When he tries to power on the machine he sees a pre-boot authentication screen which requests him to insert admin credentials. The thief’s hacker tools are not able to bypass this screen as the same OS (which is potentially more vulnerable) as the pre-boot environment serves as an extension of the boot firmware and guarantees a secure, tamper-proof environment external to the operating system as a trusted authentication layer. Brute force attacks in this environment are also much harder as the tamperproof firmware reboots the machine after a threshold time or number of attempts to login has expired.
To the thief’s dismay, he cannot really use the laptop and leaves it in the coffee shop where he logged in from.
(5) Asset Recovery:
The IT admin of SecureBank was able to get the IP of the location where the thief last logged in from and contacts the coffee shop. SecureBank officials pick up the laptop and bring it back to the IT admin desk for recovery. To recover the platform the IT admin carries out the following steps –
The IT admin (re)sets the Theft Status to be Secure (from Stolen).
Upon boot, the admin is presented with a “system locked” message in the pre-boot environment.
The admin recovery passphrase must be entered before a given time (say 2 minutes). The admin immediately inputs his admin passphrase for the given machine.
When the admin credentials and theft status have been verified, the AT-p timer is reset and the client platform is unlocked. The platform then boots to the OS.
Once this is done, the IT admin is ready to return this machine back to Jane without loosing any time. Thus we can see that AT-p solution not only provides a way to secure machines against theft and continued malicious use, but also ensures efficient recovery and continued use of the recovered machine!
Last month, Intel introduced Intel® Anti-Theft Technology with support from Lenovo and Absolute Software.
There are various use models that this new technology enables, such as:
The ability to disable a lost notebook PC and the data on the hard drive even if it never connects to the network (based on IT policy)
The ability to send a "poison pill" so that the notebook PC is disabled, along with the data on the hard drive, if the notebook PC is connected to the internet
The ability to re-activate the notebook PC if it is found again
Watch the following Intel Anti-Theft Technology demo with Intel executives Dadi Perlmutter and Pat Gelsinger from Fall IDF 2008 and learn more about how this new technology helps with theft deterrance.
For a more in-depth demonstration of Intel Anti-Theft Technology with Absolute Software, watch the following video:
Listen to industry analysts discuss benefits of Intel Anti-Theft Technology and why this technology is an important milestone that will help with notebook PC theft deterrence in the future.
Listen to a Lenovo executive discuss the benefits that Intel Anti-Theft Technology will bring to Lenovo based notebook PCs.
Listen to Absolute executives discuss how they are taking advantage of Intel Anti-Theft Technology in their software and services.
Last, listen to Intel'sAnand Pashupathy, George Thangadurai and Duncan Glendinning comment on the benefits of the new technology.
Another Add, here's Josh Hilliker talking about Anti-Theft Technology @ the beach.
I'm sure we've all either experienced or had a close encounter with a notebook nightmare (which is when you lose a laptop with some very valuable data on it). Well, with the release of Intel Anti-Theft Technology (go to the Intel vPro expert center to learn more about this new technology) - Intel wants to help consumers and professionals not have to worry about that data seeing the light of day in the wrong hands.
To see how notebook nightmares in the future may change, see the videos below:
My final video with Jake (a bit overdue), here we sit down and Jake shows me how the team automates their console build out for rapid testing of each platform. This capabilty was just installed in my lab right before the holiday's and I'm fired up to use it when I return to the plant.
The key here is that automation is very critical for us to test without spending hours/days building an infrastructure on the fly to test a certain configuration. Who wouldn't want an automated console build out WEB UI, that just works when you need it.
When designing a vPro deployment strategy it is important to understand the implications of your decisions on your ability to scale your vPro deployment beyond one management application. Here are a few of the basic principles that are important in these decisions:
·Reduce the number of client dependencies by updating your vPro firmware and vPro drivers
·Choose one application and method for initial setup and configuration
·Determine which application is going to manage which aspect of vPro feature configuration
·Use Kerberos authentication
·Understand how to share TLS across applications
The details behind these principles are described below.
Intel vPro is a suite of individual technologies. The term vPro means manageability, security and power efficiency among other things. Depending on your companies needs you may desire to take advantage of some or all of the individual features of a given vPro system. Similar to the rest of your infrastructure the ways that you interact with vPro may be different depending on the use case. For example, you may find yourself with a software deployment console that needs to use vPro for waking up machines that are powered off and security software that uses vPro to manage a System Defense firewall. Both pieces of software would need access to vPro functionality and need to cooperate together to provide a full set of vPro functionality. As an analogy, it would be uncommon for a given IT department to only have one tool that manages Windows clients. They would more likely use a combination of tools such as MMC snap-ins, Remote Desktop, Group Policy Objects, 3rd party consoles, etc.
This article attempts to speak to vPro ISV interoperability and outline the path to success in sharing access to vPro across ISVs. Understanding the interoperability decisions relating to vPro will ensure that your vPro deployment is scalable beyond your initial usage of vPro. Also, as vPro progresses as a product the list of features that the vPro suite contains will expand. It will become increasingly difficult to use one tool to get all of the functionality out of vPro.
The basic concepts that make for an interoperable vPro deployment are the following:
·vPro Lifecycle – How the vPro lifecycle impacts interoperability
oSeparation of Duties – Determining which features of vPro are managed by which ISV
·Authentication – Understanding how authentication decisions impact interoperability
·Encryption – Figuring out how to share encryption keys used to protect communication transport
There are several aspects to the vPro lifecycle that impact interoperability ranging vPro firmware/software versions to turning on vPro to managing the feature. Putting together a plan to manage each aspect of the lifecycle can help make for an easier path to interoperability.
vPro Firmware/Driver Versions
When you obtain a new machine it is important to check with the OEM to ensure that your machine has the latest firmware and vPro drivers. The reason this is so important is because it will help to make your interoperability matrix as small as possible. As a general rule, there has historically been a new major version of firmware and drivers for each new platform year. Beyond each year’s release, there are also updates that fix issues or back-port features for consistency and forward compatibility. Maintaining each of your machines firmware and driver versions will decrease the number of different vPro configurations you have in your environment and make management through consoles easier and more consistent.
vPro firmware and drivers are typically available on the OEMs support/download section of their site. The firmware is usually coupled with the BIOS firmware and available through a BIOS update. The drivers include the HECI (low level driver) and LMS (higher level service) as well as other components that help complete the vPro use cases.
Initial Setup and Configuration
The enablement of vPro on a given machine is often referred to as ‘vPro provisioning’. The term provisioning can be broken into two parts – initial setup and initial configuration. Since it is important to differentiate these two parts of provisioning for this conversation, the term Initial setup and configuration will be used to describe these two sub-processes of provisioning.
Initial setup at a high level is the initial trust establishment that allows the machine to know that you are authorized to turn on the vPro features. This can be done through a number of methods including through MEBx, USB Key One-Touch, and Remote Configuration. This initial configuration step is typically completed using ISV software assistance. For example the ISV software might create the USB key utilized through the One-Touch configuration or act as the coordination point for remote configuration. The initial setup phase is broken down into a smaller subset of steps all utilized to establish trust for the subsequent configuration phases. These steps include (but are not necessarily limited to) the following:
·Setting the remote administrator password
·Synchronizing the clock (important for the Kerberos authentication protocol)
·Configuring TLS mode
Once initial setup is completed, the initial configuration can be applied to the machine. This initial profile should include the minimal necessary information in order to manage the system from there on out. Some primary examples of what is included in initial configuration are the network/wireless settings as well as authentication configuration (discussed in a later section). The basic idea is to then allow multiple ISVs to utilize this information (network access and credentials) in order to configure the different features of vPro that they care about. Here are a few examples of configuration that is set during initial configuration:
·Additional digest users or Kerberos ACLs
·Enablement of the web administrative interface
This initial setup and configuration should be managed by one source. Having a consistent way of enabling vPro and setting the initial configuration network and authentication credentials is critical to achieving ISV interoperability. That way there is one consistent way to access the machines after the initial configuration is done.
To be clear, this initial setup and configuration should not be confused with subsequent usage of vPro. Policies and settings such as System Defense Filters, Agent Presence, Third Party Data Storage (3PDS), etc are all examples of things that are outside of the scope of initial setup and configuration and therefore can be managed easily outside this single setup and configuration source. The only requirement being that the software configuring these usages should be configured to use the authentication credentials / encryption mechanisms that were established via initial setup and configuration. This concept and examples on how this is achieved is discussed throughout this post.
If for some reason the method of initial configuration needs to change midway through deployment, you may need to either migrate the data that was set through initial configuration using a tool such as the SCS to SCCM migration tool or as a last resort go back through the initial setup and configuration process again using the new console. Instructions on how to do this can be found here.
Using the features
When multiple vPro enabled software applications are used to manage the same client it is important to clearly delineate between the roles of the two applications. This delineation might be decided for you based on the functionality of the software and the indented usage of vPro, however there may be overlap between two software offerings. In that case, IT policy should take over.
The basic idea behind determining a clean separation of duties for vPro enabled applications is to figure out which applications will manage which parts of vPro. An easy way to think about this is based on the origination of the data. Here are some examples:
·Security software the manages the System Defense filters
·Auditing software that maintains the audit logs and event logs
·Management software that manages Client Initiated Remote Access (CIRA) settings
There also might be examples where multiple software applications might utilize the same features of vPro at different times. For example most or all of them might utilize the following:
·Remote power control capabilities
The ability for these software applications to manage the features of vPro that they are responsible for and share the usage of the other features is made possible by setting up the proper authentication/authorization and encryption policies.
Authentication is the act of proving you are who you say you are. It is important to understand the different ways that you can authenticate to vPro and the role that the IT infrastructure can play in this proof of identity. This not only applies to individuals but service accounts as well. vPro supports both HTTP Digest Authentication as well as Active Directory Kerberos Authentication. Here is a brief description of both:
Digest authentication is a simple passing of a username and password through the digest protocol. It is considered to be reasonably secure when coupled with SSL and easy to setup since all you have to do is create a username and password in order to establish a trust between two endpoints. The drawback to digest authentication lies in scalability and interoperability.
When using vPro with digest authentication, it is recommended for security reasons that the console creates a unique password for each vPro system so that if one password is compromised, then all machines are not compromised. This creates a difficult interoperability problem. This means that the console that is responsible for initial configuration (and therefore creates the initial digest password) will need to store all of the unique passwords in their data store. If another ISV wants to then subsequently gain access to that vPro system they need to either gain access to that data store to get the passwords or have the initial configuration console create a new account with new passwords on each machine for that application. Since there is no standard interface for this console to console communication and sharing of usernames and passwords and because this large number of accounts can quickly become difficult to manage, it is strongly recommended to use Kerberos if interoperability is a goal of your deployment.
If digest must be used and interoperability between vPro enabled software is desired, it might be a worthwhile exercise to investigate your needs for interoperability vs. the risk of security exposure by making the digest password the same across all managed vPro clients. Making the digest password the same across machines would allow all software access to all machines without having to share machine specific credentials. Again, Kerberos gives you these same benefits without the same exposures. The primary reason is that the Kerberos account is centrally controlled. If compromised, the password can be changed once centrally to mitigate the exposure without having to connect to each remote machine to change it. Also since the account is managed centrally with Kerberos, it is easier to create vPro software specific service accounts that only have access to a smaller number of vPro features. Doing this with Digest could result in an unreasonably large number of usernames and passwords that would be difficult to manage per machine.
Active Directory Kerberos Authentication
Kerberos is an authentication protocol that allows someone to gain access to network based resources based on that initial authentication by trusting the central source that originally authorized that user. The Kerberos protocol is a bit more complicated than digest; however it has the advantage of providing a secure answer for scalability and interoperability. If you have Active Directory deployed in your company, you have the infrastructure you need to support Kerberos authentication.
Kerberos works by sending the username and password securely to a central authentication server. The authentication server then authorizes them to gain access to other network resources that trust that same authentication server. This means that the username and password only needs to be stored once on that authentication server and because the authentication server is trusted by the environment it provides one place for central management of those credentials.
Microsoft centered their Active Directory solution around Kerberos in order to simplify account management and allow for interoperability between different resources based on a single authentication. For these same reasons and based on the fact that vPro seamlessly integrates with Active Directory, Kerberos is a far better choice for vPro authentication in the context of interoperability, scalability and manageability.
Again, here are some of the reasons that centrally managed Active Directory Kerberos accounts are superior to Digest for interoperability:
·Reduces the number of individual usernames and passwords to manage/share
·Better security since control is centralized
·Account management such as changing passwords can be done once rather than once per machine
Once a user or service is authenticated using either digest or Kerberos authentication the user then needs to be mapped to a set of allowed actions. In vPro this association between a user and the actions they are authorized to perform is controlled through Realms. vPro Realms are predefined groupings of control that can give one user or service access to a given feature of vPro and another user access to another feature isolating the ability for each to control the other. Here are some examples:
·Users that need administrative access to the entire set of vPro features should be assigned to the PTAdministrationRealm
·Software that needs access to manage System Defense should be assigned to the CircuitBreakerRealm
·Software that needs to wake up or shut down a machine should be part of the RemoteControlRealm
It is common that the software managing these realm assignments abstracts the names or even blurs lines between the realms. There are even software applications that completely abstract the realm assignment by inserting the authorization logic into their application. Regardless of how the software chooses to utilize these realm assignments it is important to understand the realm assignments and how they impact your plans to allow for interoperability. As you are doing this ensure that you are assigning the least privilege necessary to get the job done, which will not only help to isolate your applications, but ensure a more secure deployment.
vPro supports SSL and TLS in order to protect the information passing between the vPro enabled software application and the vPro client. This is an optional component of the vPro configuration but is strongly suggested for security reasons. Some of the vPro enabled software consoles extract the complexity of configuring encrypted communication and enable it by default. If there is an expectation that multiple vPro enabled software applications should be able to communicate securely to vPro clients, then there needs to be a strategy for trusting the CA used to secure that connection.
The encryption technology vPro uses is the same that is used to protect you when you are going to your banks website to check your account balance. The way it works is through a public/private key pair where the vPro client is similar to the banks web server containing the private key and the vPro enabled software application or web browser used to manage vPro needs the public certificate. vPro only supports storing one private key used to establish secure communication so similar to other features of vPro you will need to choose which console will manage the lifecycle of that certificate. It would typically make sense that this is the same console that owns the initial setup and configuration. Once you have made this decision, the other consoles need to utilize that same key pair to communicate securely with the vPro clients.
The high level process used to share this key pair includes exporting the public key from the console that originally configured encryption and importing it into the other vPro enabled software applications certificate store. This isn’t as hard as it sounds. For example, here are the steps to export the Root CA certificate that is used with SCS. This process only needs to be done once per server that needs to manage vPro.
To export the certificate and save it as a file:
Note: There are several methods of exporting a certificate. This section describes one method.
1.Click the Windows Start button > Programs > Administrative Tools > Certification Authority.
2.Right-click on the first sub-branch. A popup menu is displayed.
3.Click Properties and click the General tab.
4.Select the certificate and click View Certificate.
5.Click the Details tab and click Copy to file.
6.Follow the steps in the Wizard: Select an export format (any of the options is acceptable), name the certificate file, and save it in a known location. A message indicates that the export was successful. Click OK. The Details tab returns to focus.
7.Click OK > OK. The Certification Authority Management Console returns to focus.
To install the CA certificate in the certificate store as a trusted root certificate:
Note: This step is not required if the CA is installed on the local platform.
1.Find the certificate. If it was exported directly to another computer, find it on the other computer. If it was exported to a USB key, move it from the USB key to the computer.
2.Right-click on the certificate and from the popup menu and select Install Certificate. The welcome screen of the Certificate Import Wizard is displayed. Click Next.
3.Select Place all certificates in the following store and click Browse. The Select Certificate Store window opens.
4.Select Trusted Root Certification Authorities and click OK.
5.Click Next > Finish. A message indicates that the import was successful. Click OK.
With proper planning vPro configuration can easily be managed by several vPro enabled applications. Having an understanding of the separation of duties for those applications and the authentication/encryption technology vPro uses can make for a vPro deployment that scales beyond one ISV.
Here is a simple video that demostrates how SCCM and Altiris can interoperate together to manage vPro Out of Band functionality.