Technical Articles ID:
KB79784
Last Modified: 7/28/2021
Environment
McAfee Drive Encryption (DE) 7.2.x
For details of DE supported environments, see KB79422.
Summary
Recent updates to this article:
Date
Update
July 28, 2021
Rebranded for McAfee Enterprise.
July 24, 2020
Minor formatting change; no content changes.
June 3, 2020
Correction to the "Additional Cold Boot general facts" section:
Removed "Further hardening work is planned for this function in future releases."
June 2, 2020
Added the following to the "Additional Cold Boot general facts" section:
Also, this function does not work with Virtualization-Based Security, introduced in Windows RS1 and later. So, it can't be enabled on those platforms. Further hardening work is planned for this function in future releases.
March 23, 2020
Correction to FAQ "What is the key length used by the encryption algorithm AES256?". Key length changed from 128-bit to 256-bit.
To receive email notification when this article is updated, click Subscribe on the right side of the page. You must be logged on to subscribe.
This list presents common questions and answers, and is intended for users who are new to the product.
NOTES:
To review the FAQs for Endpoint Assistant (EA), see KB85917. EA is a companion application for iOS and Android that was developed to work with DE. Help Desk costs for DE are typically related to user password reset management. EA can completely offload the preboot password reset related Help Desk costs to users. You can enable users to securely reset preboot passwords even if they have no access to a telephone to call the Help Desk.
FAQs for Opal Drives have been split into a separate article. For details, see KB89333.
Contents
Click to expand the section you want to view:
What is an OptIn and OptOut user?
You might see references to OptIn and OptOut users in the logs. For example, failing policy enforcement: assigned OptIn user.
OptIn users have their User-Based Policy (UBP) Enforcement set to True in ePO, which means that a specific UBP applies.
OptOut users have their UBP Enforcement set to False, which means that the UBP assigned to the computer applies.
Why do I need DE?
The key purpose of DE is to only protect sensitive data on the disk when at rest. This type of protection might also be required to be covered by identity protection laws.
What protection do I have when preboot authentication is disabled when enabling the temporary Autoboot feature?
The key purpose of DE is to protect the disk at rest, when the disk is unlocked. But, DE provides no data access protection. So, if you want a secure system, do not use the Autoboot feature. The autoboot feature effectively removes the preboot authentication, which completely removes the security of the product. The AutoBoot feature is provided only as a temporary means. For more details about AutoBoot, see Autoboot. For details about the more secure Trusted Platform Module (TPM) autoboot.
Compatibility DE 7.2.0 and later:
Do you support the Windows 10 Anniversary Update new command-line parameter /ReflectDrivers for in-place upgrade?
Yes. Microsoft has included a new feature in Windows 10 Anniversary Update that allows for operating system in-place upgrade through ISO and SCCM using a /Reflectdrivers option.
This command switch specifies the path to a folder that contains encryption drivers for a computer that has third-party encryption enabled. PnP drivers are installed and the upgrade can continue.
NOTE: The /Reflectdrivers option is also supported with DE 7.1.3 Hotfix 1148978 or later. But the process is further simplified with DE 7.2.0, as a result of changes introduced in the product installer.
For detailed information about Windows 10 in-place upgrade with DE installed, see KB87909.
To view the Supported platforms, environments, and operating systems for DE, see KB79422.
Compatibility for DE 7.1.0 and later:
Do you support the in-place Unified Extensible Firmware Interface (UEFI) conversion tool (MBR2GPT.EXE) with Windows 10 Creators Update and later?
Yes. A Drive Encryption Master Boot Record (MBR) to GUID Partition Table (GPT) tool (MdeMbr2GptTool.exe) has been developed, that works on Microsoft Windows 10 (version 1703) Creators Update and later (64-bit only). The tool works with the Microsoft tool (MBR2GPT.EXE). The tool converts a software-encrypted Drive Encryption drive from MBR to the GUID Partition Table (GPT) partition. It does so without the need to decrypt the diskTo get the Drive Encryption tool and instructions, see KB89024.
What version of DE supports Windows 10 (version 1507)?
DE 7.1 Update 3 (7.1.3) is the first version to support Windows 10, but is released ahead of the Windows 10 general release. So, there might be caveats that apply to the deployment and use of DE 7.1.3 on Windows 10 systems.
See the following articles for specific details about upgrading Windows 10 when DE is installed:
Windows Release
Article
Operating System (operating system) refresh from Windows 8
LTSC and LTSB are Microsoft terminology for a Sustaining build. These builds do not receive feature updates and would be limited to security updates in general.
Is a Windows operating system with DE installed on Mac hardware supported?
No. DE has not been tested on any Mac hardware and is thus unsupported.
Can I run the Microsoft Upgrade task to upgrade a Windows 8.0 system to Windows 8.1?
No. Microsoft is using functionality that lays down a new WIM image. It is essentially an operating system Refresh Process and not a traditional upgrade or Service Pack upgrade. But, DE has a documented operating system Refresh Process that allows you to upgrade from Windows 8.0 to Windows 8.1. Ther process allows you to keep the existing data encrypted throughout the entire process. For assistance with this process, see the following:
Windows operating system Refresh Recommended Process Guide for Master Boot Record systems only, click here.
Windows operating system Refresh Recommended Process Guide for UEFI Systems Only, click here.
Can I use the Windows 8 or later Automatic Repair (enabled by default)?
No. We recommend that you disable this feature. Automatic Repair of an encrypted disk might inadvertently destroy the encrypted operating system files and cause permanent boot problems. Previous versions of Windows asked whether you wanted to repair your system before starting the repair. But, Windows 8 starts Automatic Repair immediately when a problem is detected, leaving little scope to prevent destruction of encrypted data. For information about disabling Windows 8 Automatic Repair, see article KB76649.
Why must I use the DE 7.1 operating system Refresh Process when I do not use it on Windows BitLocker systems?
Microsoft implements a mechanism that exposes the BitLocker encryption key during the upgrade, allowing the WIM overlay process to run. McAfee does not adopt this approach because it leaves the system vulnerable to attack during the Windows upgrade process.
Microsoft has talked about a new feature calledDevice Encryption. What is it?
Microsoft Device Encryption can be considered a scaled-down, non-managed version of BitLocker.
Other Device Encryption general facts:
Microsoft Device Encryption is automatically enabled. Only enabled when the hardware matches or exceeds its minimum hardware requirements.
The following happens, if you deploy DE to a system that has 'Microsoft Device Encryption' automatically enabled:
Pre-activation checks determine that BitLocker is active. Remember that Microsoft Device Encryption is simply a non-managed version of BitLocker.
DE activation fails because the disk is already encrypted with Microsoft Device Encryption.
This status is reported back to ePO.
The above applies, if both the following apply:
The option 'the system meets the minimum hardware requirements' has been automatically enabled.
And
The hard-disk is encrypted.
IMPORTANT: The following applies, if you have a new system that meets the Microsoft Device Encryption minimum hardware requirements. But have Windows 7 and DE 7.1 installed, and then decide to upgrade to Windows 8.1:
If you have not logged on with an MSDN account, the system does not try to enable Microsoft Device Encryption.
If you have logged on with an MSDN account, it does break the operating system.
Does DE support Windows compressed drives?
No, Windows compressed drives are not supported because no compatibility testing has been undertaken.
Are there plans to support JAWS for Windows screen reading software for the preboot client, to help users with poor eyesight?
No. JAWS is a Windows-only software product. It does not work at the preboot authentication point because Windows is not yet loaded.
Does DE work with the new Dell Cylance Advanced Threat Protection Technology, which can report if a Boot attack is detected?
No. DE has not been tested with Dell Cylance Advanced Threat Protection.
Does DE support Intel Anti-theft technology, which can lock the computer based on hardware?
No. Intel has discontinued Intel Anti-Theft Service.
Does DE 7.1 support Intel Smart Response Technology (SRT)?
Yes. Data is always safe, even the cached data. The Intel SRT is a smart cache component that only caches frequently accessed data. This cache is at the sector level and is encrypted by the DE filter driver.
Does DE support Intel Rapid Start (IRS)?
No. IRS requires an extra partition space on the Solid State Drive (SSD) or Hard Disk Drive (HDD), called the Hibernation Partition. This partition must be equal to or larger than the amount of system memory. This partition does not have a drive letter.
IRS provides a low-power S3 state. Where, instead of storing state to DRAM in S3, the memory contents are flushed to the dedicated partition on the SSD. Because the BIOS is responsible for flushing to and from the SSD, DE can't intercept and encrypt the content. So, any sensitive data in DRAM is written to the disk in plaintext. This issue affects only the S3 state, not S4. NOTE: IRS technology enables your system to resume faster from sleep; this fact saves time and power consumption.
Is the DE 7.1.x client compatible with Microsoft BitLocker?
No. It is not compatible with BitLocker or any other Full Disk Encryption or Sector Level Encryption software running on the same system. DE detects Windows BitLocker during the DE activation process and stop the activation of DE if BitLocker is active.
Is Active Directory needed for a DE 7.1 installation?
No. You can install the installation (MSI) packages without access to Active Directory because of the new User Directory feature included in DE 7.1. See the Functionality section for details. Other Active Directory general facts:
Active Directory is required to manage DE 7.1 clients via ePO.
Although Active Directory is required for a DE 7.1 activation, a DE 7.1.0 new feature allows offline activation to activate DE without a connection to ePO. When the system can successfully communicate with ePO, the client moves into an Online mode. Only systems that ePO does not manage, can remain encrypted without the need to be connected to Active Directory.
Assigned users are not deleted from the ePO database if the object name such as a Group or User is changed in Active Directory. The object name change is detected on the next run of the 'LdapSync: Sync Across Users from LDAP' task and updated in ePO. During the following Agent to Server Communication (ASCI), any user object name change is synced to the client.
What happens to my endpoints if the ePO server goes down?
If the product is already installed and active, clients continue to operate with the cached copy of the policy. No additional policy updates or user assignments occur until the client can communicate with the ePO server. If the product is not yet installed, it can't activate until communication with the ePO server is re-established.
Can I use a Windows bootable CD on an encrypted system?
A bootable CD works on an encrypted system unless you want to access the hard drive. One advantage of full disk encryption is that it prevents a bootable drive from being used to access the hard drive without authenticating.
If Windows is not working properly, and you have to repair it using the Windows setup disk. You must first decrypt the drive before you use any Windows repair tools.
To access the encrypted drive and DETech WinPE Recovery, you have to create media. For more information about how to create the media, see the latest DETech guide:
What operating systems are supported with DE?
For up-to-date details of current supported operating systems, see KB79422. NOTE: The following also applies to the article named above.
The minimum ePO versions supported by DE 7.x.
The minimum McAfee Agent (MA) supported by DE 7.x.
Which EEPC versions can upgrade to DE 7.1.x?
The following upgrades are possible:
EEPC 7.x - (End of Life) Systems installed with EEPC 7.0.x can upgrade to DE 7.1. But, you must first upgrade the EEPC extension to either EEPC 7.0 Update 2 (7.0.2) or Update 3 (7.0.3).
EEPC 6.x - (End of Life)
If you are using EEPC 6.1.2 or later, you must first upgrade all extensions to either EEPC 7.0 Update 2 or Update 3. Client systems running EEPC 6.1.2 or later can be directly upgraded to DE 7.1. ePO installations with either EEPC 7.0 Update 2 or 3 extensions checked in can be upgraded directly to DE 7.1.
EEPC 5.x - (End of Life)
Systems installed with EEPC 5.2.6, 5.2.12, and 5.2.13 can migrate directly to DE 7.1.
What steps must I follow if I want to upgrade to the latest version of DE 7.2.x. But already have an earlier DE 7.1.x version installed?
If you have an earlier version installed, such as DE 7.1.0, but want to upgrade to a later DE 7.1.x version, perform the following steps:
Make sure that there are no LDAP Sync tasks running. If any are running, wait for them to complete.
Disable all LDAP Sync tasks before initiating the upgrade.
Install the DE 7.1.3 extensions.
Check in the DE 7.1.3 Agent and PC software packages.
Re-enable all LDAP Sync tasks.
Deploy the DE 7.1.3 software packages to the client system.
Restart the client system after the deployment task has completed.
I am setting up a new ePO server and want to move DE clients across to it. Is this action supported?
Yes. This scenario is supported in DE 7.1.3 and later. NOTES:
With earlier versions of DE, transferring a system from one ePO server to another replaces the user assignments. User token data on the system are also replaced with data from the destination server. There is a potential to lose user assignments and change user credentials in the preboot environment.
DE 7.1.3 introduces a client transfer capability. The capability provides the ePO Administrator with a mechanism to allow systems to be transferred from one ePO server to another. The transfer occurs while preserving user assignments and user data. If the feature is enabled, a DE 7.1.3 system detects a server change. It requests that the new DE 7.1.3 managing server automatically assigns users to the system in the context of the new managing server. When the assignment is successful, the system sends its user token data up to the new managing server. Any systems that have failed the system transfer process are highlighted on the destination server via an intuitive out-of-the-box report.
A separate DE 7.1.3 Client System Transfer Guide is included in the release that describes this system transfer process in detail. For details, click here.
What do I have to consider if I install to a Windows 8.x system using native UEFI?
Recommendations if you plan to install DE 7.x on a Windows 8.x system, using native Unified Extensible Firmware Interface (UEFI). McAfee Enterpise recommends that you only use native UEFI mode, if the system is explicitly Windows 8 certified. McAfee Enterprise also recommends that you upgrade your UEFI systems to the latest UEFI firmware level. Then test on a specific native UEFI-capable system, before wide-scale deployment. NOTE: For other UEFI questions and answers, see the Functionality section below.
Do I have to decrypt and re-encrypt the clients during the upgrade to DE 7.1?
No. The upgrade process is designed to transfer the key from the old agent to the new agent.
Can I automate the DE users and systems migration from one ePO server to another?
For how to migrate DE users from one domain to another, see KB83802.
During the installation process, what methods are available to avoid all users using the same default password?
There are two methods:
Via the DE policy, you can forgo using the default password. Instead force users to be prompted to enter a password they choose.
Use a policy assignment rule with a different User-Based Policy (UBP) where you define a different default password for those users assigned the UBP.
Can I install DE on a system and take a RAW image (sector by sector) to use on new computers?
No. This scenario is not supported. It would introduce a security problem because every system would have the same security key.
Can I change the size of the tablet on-screen keyboard displayed during preboot if I think the default size is too small?
No. To submit a Product Enhancement Request to include this functionality, see the Related Information section.
Do I need to add VirusScan Antivirus exclusions for DE?
No. Antivirus exclusions are no longer required.
Functionality FAQs applicable to DE 7.2.0 and later How does DE 7.2.x use Intel Software Guard Extensions (SGX)?
Intel SGX is an Intel Architecture extension, introduced with 6th Generation Intel Core processor platforms, that is designed to increase the security of software through an inverse sandbox mechanism. In this approach, legitimate software can be sealed inside an enclave and protected from such threats, irrespective of the privilege level of the threat. The alternative is to try to identify and isolate all potential threats or attack surfaces on the platform.
Using Intel SGX with DE further improves protection against memory-based attacks (such as the cold-boot attack) without affecting performance on systems that support SGX and with suitable policy applied.
How do I enable SGX with DE 7.2.x?
To make sure that DE uses SGX where available, support for SGX must be enabled before DE 7.2.0 is deployed to a target system.
For further information about the technology requirements for this new feature, see KB87256.
Functionality FAQs applicable to DE 7.1 and later Can I repartition a disk that is encrypted with DE?
No. It is not possible to change the partitioning of a disk that is already encrypted. You need to fully decrypt the disk and uninstall DE before performing the repartitioning of the disk.
What is the key length used by the encryption algorithm AES256?
The key length used is 256-bit.
Is Raid supported?
There are two types of RAID technologies to consider: Computers with hardware or software RAID:
DE is untested with hardware RAID. But we expect that DETech to work properly in environments where pure hardware RAID has been implemented. This expectation covers systems that have internal RAID cards or external RAID systems with a built-in controller. NOTE: DE/DETechcan't support diagnostic or disaster recovery for a broken raid configurationwhen hardware RAID is in use.
DE/DETech does not support software-based RAID. Windows dynamic disks are a form of software RAID.
Computers when the BIOS SATA Mode is configured to use RAID or RAID ON:
In general, DE/DETech works in RAID mode as long as the BIOS SATA mode of that computer can see the disk.
NOTES:
In Legacy/MBR BIOS mode DE relies on Int13 calls to access the hard-disk (HDD) of the computer.
In Unified Extensible Firmware Interface (UEFI) mode, DE relies on the system input/output protocol, so DE is agnostic to the BIOS SATA mode.
The only caveat to this statement is, if the disk is an OPAL, or Self-Encrypting Drives (SEDs) HDD. DE must be set to Advanced Host Controller Interface (AHCI) mode. The reason is because DE has its own controller driver and does not rely on the BIOS for hard-disk access. NOTES: The caveat only applies to hardware encryption of an OPAL or SED drive, and not if the OPAL HDD is configured for software encryption.
Is possible to encrypt a removable media storage device connected through a USB port?
No. DE detects and encrypts the drive only if it is detected through a SATA port.
What is the DE User Directory?
The User Directory extends your ePO-managed DE to systems with unmanaged, non-domain users. In addition to users managed in Active Directory, DE can now also use these ePO-managed users for preboot authentication.
User data is now synchronized from Active Directory and cached locally in ePO. This fact eliminates the need for constant round trips from ePO to Active Directory. It results in significant performance improvements for user-based policy checks.
Other User Directory general facts:
User Directory removes the dependency on Active Directory
An Administrator must install the User Directory extension. You can do this install before, or after you have upgraded to DE 7.1.x. As long as the ePO prerequisites are met, which is ePO 5.1.x
There are no conceptual differences between the standalone users in EEPC 5.x and the users in the User Directory
Migrate EEPC 5.x standalone users to the User Directory.
You can create Organizational Units (OUs) in the User Directory.
Users can be added to and removed from an OU.
Users can be moved from one OU to another OU
OUs can be nested.
A user can't belong to more than one OU
When selecting an OU, you can see all users that make up that OU (including nested OUs). NOTES: You can see all users from sub OUs, but not all nested OUs. From the distinguished name, you can see which sub OU each user comes from.
Regardingscripting, does the ePO WebAPI change for User: Machine assignments?
No.
What is Trusted Platform Module (TPM) autoboot?
TPM autoboot is a new offering in DE 7.1. It strengthens the traditional autoboot functions by using a TPM, if the hardware is present, to protect the key.
The TPM provides a sealing mechanism. Whereby encrypted data can only be decrypted if the system is in a predefined state. During system startup, the TPM measures the firmware and all boot components. Measuring consists of extending a hash stored in a TPM register, with the code about to be executed. The firmware takes measures, which can't be bypassed. The TPM only allows the decryption of the key. If the system is in the same state as when it was sealed, any change, no matter how small, causes it to fail. Other TPM general facts:
TPM autoboot is different from traditional autoboot in that traditional autoboot provides no security for the system. The key used to encrypt the disk is written in plaintext to the disk. TPM autoboot secures the key by encrypting it with the TPM; it is no longer in plaintext.
TPM helps secure the key because the TPM can decrypt the key only if the system state has not changed. The key is not decrypted if:
The TPM believes that the system state has changed.
Or
A new TPM chip is present (new motherboard),
If it can't decrypt the key, the autoboot function fails, and the preboot authentication is displayed.
With TPM autoboot enabled, the system continues to automatically boot, but only if the TPM believes that everything is in order. In this situation, the user does not see the preboot environment and it simply boots into Windows.
TPM autoboot can be used with reactive autoboot.
TPM Autoboot and Reactive autoboot, can be used with the new Connected Standby. Both provide support and hardening of systems against cold boot attacks.
If the motherboard is changed, or the TPM boot measurements change, the User sees the preboot authentication screen. If a user has gotten into this situation, they need to perform a Challenge / Response Recovery to gain access to Windows.
If valid preboot user credentials are known, the user can simply authenticate and boot into Windows. But, because the user has been in this autoboot mode, the chances of them knowing a valid user credential is low.
TPM does more than encrypt the key. It also measures the boot path. Every time the system boots, we hash some data about the boot path into the TPM. The result is that the TPM only decrypts the key if the boot path has not been changed.
This fact means that after TPM autoboot unlocks the disk, it is not possible to boot to another boot path. If a different boot option is selected on startup, the autoboot function fails and the preboot is displayed.
Other TPM Administrator role facts:
The policy settings for TPM autoboot are under the title "User TPM for automatic booting" and it has the following three options:
Never - Disk key is written in plaintext to the disk. This option is the original autoboot functionality.
If Available - If the system has a usable TPM, the TPM is used to encrypt the key. If no TPM is available, or is unusable, the TPM present on the system has the key written in plaintext to the disk. This action is according to the original autoboot functionality.
Required - Autoboot only works if the system has a usable TPM. The DE preboot environment is displayed on systems that do not have a TPM.
IMPORTANT: If Microsoft updates the Windows bootLoader during a Windows update, the boot measurements have changed. As a result, TPM can't decrypt the key and you must go through a recovery process. The recovery process requires a Help Desk call, to have the system boot successfully again. NOTE: The DE preboot is also in the boot path. So, when an administrator rolls out a new version of DE, hotfix, update, or new version, it updates both the:
DE preboot EFI Application
And
Boot measurements
Similar to the Windows update scenario, users must make a Help Desk call to access their system after DE pushes an update.
The minimum requirements for TPM autoboot are:
DE 7.1.x/7.2.x only support TPM Autoboot on TPM 2.0 systems (all Connected Standby Systems support TPM 2.0). NOTE: Older systems with TPM 1.2 do not support this feature.
DE 7.1 Update 1 (7.1.1) and later add support for TPM 1.2 chipsets (UEFI systems only).
The TPM owner key must be managed locally and not in the Active Directory.
The system must include the TPM UEFI protocol in the OEM’s UEFI implementation (a requirement for Connected Standby systems).
Other TPM user experience facts:
When TPM can't decrypt the key, it displays the preboot environment and asks the user to authenticate. If TPM is in any doubt, it does not automatically boot the system and instead displays the preboot environment and waits for authentication.
Can I now handle a larger number ofusers in preboot?
The preboot environment has now been improved to support more than 5,000 users without perceptible performance degradation during preboot authentication. The previous limit was a maximum of 250 users in preboot. You can now safely provision all users to share desktops, which enable any user to use any system.
What is the recommendation for the number of users assigned for preboot authentication?
The general recommendation remains unchanged. Assign only the minimum number of users for preboot authentication. Other preboot authentication general facts:
DE 7.1 and later increase the number of users that preboot can support. Although it is recommended to minimize the number of users assigned per node. The numbers have increased to thousands, rather than hundreds.
First, best security practice aims to limit the number of users that can access a system to the smallest group of users.
Second, assigning large numbers of users to each node might affect the overall scalability of the entire system. Which can reduce the maximum number of nodes that DE can support.
The following penalties apply if you allow 5,000 users to log on at preboot on a computer:
Activation takes longer because it needs to download all information about the 5,000 users.
Synchronizing user information takes longer, increasing the workload on the ePO server.
Other actions that include user information take longer to process. An example of these actions is Saving the system Information about a client, because it also includes user information.
Scalability of an ePO server can be affected. Your ePO server performs more work per agent-server communication intervals (ASCI) to make sure that all information is up to date.
Example
Suppose that you have 100 systems that each have 5,000 users assigned. Take the most common occurrence, a changed password. For a user, that would be captured on one system, uploaded to ePO, and then pushed down to the other 99 systems when they sync with ePO.
If you force users to change their passwords every 90 days, 5,000 users must update their password. The result is 500,000 updates (5,000 users x 100 systems) that the ePO server must process at several times as the systems synchronize with ePO.
A large number of users causes increased network traffic. All this traffic is handled across the network. Although individual user data is small, generally < 20 kilobytes, it is multiplied out by the number of transactions. If a system has a slow link, it could take a considerable amount of time to receive all changes. If the server is handling user updates for many clients, the network traffic could also be significant. In the worst case, it might not receive all updates in a sync period.
What isAOAC?
AOAC means Always On, Always Connected. Microsoft calls it 'Connected Standby' and Intel calls it as Smart Connect. They all basically reference the same high-level function.
It is the ability to keep a system in a low-power sleep mode and periodically wake it to retrieve data. For example, for emails or Facebook updates, then have it go back to sleep again. This activity occurs without the user knowing or intervening. Think of it being similar to the way your mobile phone works. Other AOAC general facts:
DE 7.1.x supports an AOAC Model. Support is provided through Connected Standby. While it is in this standby mode, the Windows logon is used to protect the data from unauthorized access.
AOAC changes Full Disk Encryption. Full disk encryption has historically been about protection of data at rest (when the system is turned off). Several companies are introducing AOAC function.
With the AOAC model, the system and services need to access the disk. That means the encryption key for the disk always remains in memory. But systems that support AOAC are more vulnerable to cold boot style attacks because the key is always in memory. Remember that the system does not turn off; it is only in standby.
All AOAC and Connected Standby still works when this function is enabled.
When the system is sleeping, the data is never at rest with the AOAC model. The systems are not turned off; they are only in standby. The AOAC model requires the disks to remain 'unlocked' because:
Systems might wake periodically or via a push notification.
Applications and Services might require access to the disk during this awake period.
You can use AOAC functions with preboot, the autoboot function, or both.This function works regardless of your method of authentication. But, McAfee Enterprise does recommend that you use one of the following:
Preboot
If autoboot is chosen, enable TPM autoboot with reactive autoboot or the integration with Intel’s Active Management Technology.
How does DEharden systems against cold boot attacks?
A high-level overview of this new DE functions:
On modern Windows platforms that can support the new 'Connected Standby' mode, the user can have an iPad-like experience.
These systems are always in a 'powered-on' state.
The system requires the encryption key to be always in RAM, making them susceptible to memory scrubbing attacks that can scrub the encryption key from RAM.
DE can operate behind the scenes delivering a native Windows experience to the user. When the device enters the 'Connected Standby' state, DE erases the encryption key from RAM. DE then moves it to a secure area on an Intel hardware hardening system, to prevent against cold boot and memory scrubbing attacks. When the device moves into an active state, the encryption key is transparently moved back to RAM. Which occurs after successful user authentication to Windows.
What is a cold boot attack?
A cold boot attack is a way of extracting sensitive data from system memory. It does so when the system is turned on, or in a standby state. Even if the system is protected by a Windows password. The attack involves either of two actions:
Hard rebooting the system and running a small program on the next boot cycle that scans system memory for sensitive information
Removing the RAM from a powered-on system and translating to another system for scanning
Other Cold Boot general facts:
DE hardens systems against a cold boot attack when a system enters one of the standby modes. DE 7.1.x removes the key from memory. It is stored in a secure location that is still accessible while in Connected Standby. The system continues to function as a user expects; but, the system is less vulnerable to a cold boot-style attack because the key is no longer in memory.
DE completely removes the key from memory. This function hardens the system against memory-style attacks. Every effort has been taken to make sure that the key is removed from memory. But McAfee Enterprise can't guarantee that it is removed, because of the way Windows manages memory.
Also, this function does not work with Virtualization-Based Security, introduced in Windows RS1 and later. So, it can't be enabled on those platforms..
The only condition in which the key is put back into memory is after a user has successfully authenticated to Windows. Simply having Windows running does not put the key back into memory.
When the key is not in memory, it is held in a secure storage area that is not in memory. The key can be removed from memory when any of the following events occur:
The system is turned off.
The user logs off.
The user locks the workstation.
The system is waiting for a user to authenticate at the Windows logon prompt.
After the system wakes up from standby or sleep
If users have authenticated, and are at their desktop, the key is in memory. If users have not authenticated, or are not at their desktop, the key is not in memory.
NOTES: An Administrator can select, via a policy, under what conditions the key is removed.
Although only one driver is required to handle the key in memory, it does operate in one of two modes. Those two modes are:
Standard Crypt
Elevated Security Crypt
What isStandard Crypt Mode?
It is a state of the encryption driver where:
Encryption key is stored in RAM.
Not secure against RAM-based or Cold Boot-style attacks.
Highly optimized for performance.
Uses the same algorithm implementation as in previous legacy EEPC 7.x releases.
What isElevated Security Crypt Mode?
It is a state of the encryption driver where:
Uses a new implementation of the AES256-CBC encryption algorithm.
Encryption key is stored in a secure location, not in RAM.
ISO
Comes with a significant performance penalty.
Policy enforcements are disabled while in this state.
Other Elevated Security Crypt general facts:
The driver swaps between the two modes, and is defined via a policy.
Example: DE 7.1 can swap into the Elevated Security Crypt Mode when the system is:
Locked
Logged off
Has entered into Standby mode NOTE: Standard Crypt mode resumes when the user has successfully authenticated to Windows.
This functionality can be used with TPM autoboot.
The boot time is slower in the Elevated Security Crypt Mode. From the initial boot, the key is not stored in memory until the user has successfully authenticated to Windows. If you are using a tablet, you rarely shut down completely, so you do not always experience this issue.
When the system performs a high disk intensive task, and the workstation is locked, the workstation runs slower. The users observe the performance hit when they return later. Seen because when the system is running in the Elevated Security Crypt Mode. This issue is when the key is not in memory.
In the Elevated Security Crypt Mode, you have a security vs. performance trade-off. The important thing to remember is that when a user is actively using their system, then the normal full performance is experienced. It is only the periods where authentication has yet to occur that the user experiences the performance impact.
Example of the performance impact when the driver uses the Elevated Security Crypt mode:
Looking at raw algorithm performance: 64-bit AES-NI Capable processor:
Standard Crypt = 1 CPU clock cycle/byte
Elevated Security Crypt = 15 CPU clock cycles/byte
32-bit non-AES-NI capable processor:
StandardCrypt = 35 CPU clock cycles/byte
Elevated Security Crypt = 133 CPU clock cycles/byte
NOTE: The impact can be higher than the above raw algorithm because of the tests being executed with interrupts disabled. Looked at another way, purely as an example: If a system experienced a throughput of 208 Mb/Second in Standard Crypt, it can drop to 20 Mb/Second in Elevated Security Crypt.
Are there any hardware requirements for using this Elevated Security Crypt Mode functionality?
Yes. This information is provided in KB79291. NOTE:The system needs to support Connected Standby and it must be either a Clover Trail tablet or a Haswell system.
Is there a difference between 'Connected Standby' and 'Smart Connect'?
Yes. Smart Connect is an older technology. Smart Connect has a driver that periodically wakes the system, and dials into a server to pull notifications. Connected Standby is a new technology where the system goes into a new power state on the CPU.
Connected Standby requires new hardware to support it; Smart Connect does not. So you can have Smart Connect on a Windows 7 system with older CPU and hardware. Technically speaking, Smart Connect uses the power state S3, which is Sleep. Connected Standby uses the power state RTD3, which is a different state on the CPU.
What is Connected Standby?
Connected Standby is not really a true sleep mode. It runs in this new power state and leaves some services running that can receive notifications from the server. So, it has hardware requirements and is available only on Windows 8.x systems.
Example: The hardware requirements for Connected Standby on Windows 8 take advantage of Connected Standby if all following hardware requirements are met:
A firmware flag indicates support for the standard.
The boot volume does not use a rotational disk.
Support for NDIS 6.30 by all network devices.
Passive cooling when in Connected Standby.
NOTES: There are other security-specific requirements, for example:
Memory must be soldered to the motherboard to prevent cold boot attack vectors that involve removing memory from the computer
Is it possible to clone an existing hard-disk (HDD) to a larger disk, make the new disk bootable, and extend the size under Window’s environment?
No. To migrate to a larger HDD, you must first decrypt the HDD, complete the cloning, and then re-encrypt.
Is it possible to perform a remote wipe of an encrypted system?
No. Preboot does not have networking functionality.
Why doesWindows 8 require a significant change for encryption products?
Microsoft introduced many new features with Windows 8 and later. The ones that affect encryption the most are:
A Unified Extensible Firmware Interface (UEFI) Boot Process
GPT Disk partitioning
Secure Boot
Hybrid Boot
Windows 8 Modern User Interface (UI)
Windows 8 Tablets
Other Elevated Security Crypt general facts:
Windows 8.x has two possible boot methods. Depending on your system's configuration and capabilities,
Windows 8 either installs the capability to boot with the new UEFI Boot process or the legacy BIOS boot process.
You can't change a configuration setting and swap Windows 8 from one boot process to another. You need to completely reinstall Windows 8 because of the change in the partitioning mechanism.
From Windows 8 and later, DE has two preboot environments. A preboot to handle the UEFI Boot Process and a preboot to handle the BIOS boot process.
The DE Intelligent Client examines which boot process the system is configured to use. It then determines which preboot needs to be installed. This fact allows an administrator to deploy DE to systems, and know that the appropriate preboot is installed automatically.
DE 7.x does not use the modern Windows 8 user interface (UI). After Windows has loaded, the only DE UI in Windows 8 is the tray status monitor, which is only available on the desktop. It is not available in the Modern UI.
What isAutoboot?
Autoboot is an account that effectively bypasses the protection provided by DE. With this option enabled, the users do not see the preboot authentication screen.
What isReactive Autoboot?
Reactive autoboot is an enhancement to the traditional autoboot functionality that exists on Windows, and OS X. In autoboot mode, the drive is encrypted. But the user does not see the preboot authentication screen, and boots directly into the operating system.
Unlike traditional autoboot, reactive autoboot has one other piece of functionality. When enabled, the product monitors Windows authentication requests. If a user exceeds a specified maximum number of authentication failures, reactive autoboot automatically enables preboot authentication, disables autoboot, and immediately restarts the computer. After these actions occur, the user must successfully pass preboot authentication before gaining access to the operating system.
This functionality allows the authentication policy to automatically transition from autoboot (unlocked, insecure) to preboot (locked, secure). It is based on certain conditions designated by the Administrator.
Other Reactive Autoboot general facts:
To enable reactive autoboot (not enabled by default), an Administrator must do two things:
Select the product policy setting 'Disable and restart system after <n> (1–10) failed logons or unlocks (Windows only, Vista onwards)'.
And
Specify the number of failed logons, or unlocks allowed.
The policy must then be assigned to the systems that require the reactive autoboot functionality.
Example for the use of reactive autoboot. You want to encrypt shared systems, that any user in the organization might need to access. As a result, you can't assign a specific user or group of users for preboot authentication. Reactive autoboot might be an acceptable solution for such cases where you would otherwise be forced to deploy using autoboot.
The drives are encrypted on a system with reactive autoboot if so defined in the encryption policy. But, because authentication is not enabled when autoboot is enabled, the data is not protected.
What are the key features of Reactive Autoboot?
This feature is client-side only; this functionality is a client-only. Audit events are uploaded to ePO on the next sync, but the ePO server has no interaction with this functionality.
This feature is Windows-only. Reactive autoboot is not offered on Mac OS X. Because of Apple changes, Management of Native Encryption (MNE) has replaced the EEMac product. For details, see KB79375.
You can specify the maximum number of failed attempts. An ePO administrator can specify this number in the policy. It has a minimum value of 1 and a maximum value of 10.
Applies to all Windows authentication attempts. It applies to both Windows logons and unlocks attempts.
It works with both Software Encryption and Opal.
Users can use the Challenge/Response Recovery to allow the system to access Windows when a user exceeds the maximum defined failed attempts.
A Windows user can be either part of a Workgroup or Domain user.
Events are audited. An ePO administrator can see which systems have enabled. The event 30070:“Automatic Booting Deactivated – Exceeded maximum failed logons" is sent to the ePO Server, but only after the next successful authentication to Windows, and when connectivity to ePO is possible. NOTE: The moment that the system thinks it is under attack, it disables autoboot and restarts the system. There is no time to send an event to ePO, so ePO is not aware of the lockdown as it is implemented.
No administrator action is required to re-enable reactive autoboot on a system where it was disabled. Which can occur on a failed Windows Authentication attempt. After the client has restarted the system and accessed Windows, reactive autoboot is re-enabled automatically. The system does not need to communicate with ePO to re-enable autoboot.
What is the User experience when the system uses Reactive Autoboot?
When users turn on their computers, they boot directly into Windows. Autoboot means that there is no preboot authentication. Users go directly to the Windows logon. Assuming they always successfully authenticate to Windows, their experience does not change.
The user experiences the following after exceeding the maximum number of failed Windows authentication attempts:
Preboot authentication is automatically enabled, and autoboot is disabled.
An ungraceful shutdown of Windows occurs, and the system restarts.
When the computer restarts, the preboot authentication screen displays and the user must successfully authenticate to gain access to Windows.
After a user exceeds the maximum defined failed attempts,a user can't:
Authenticate using Windows credentials
Use Self-Recovery to pass preboot and access Windows NOTE: If the system has always worked in autoboot mode, it is unlikely that any DE users have been assigned to allow any successful preboot authentication.
A user, to gain access to Windows when presented with preboot authentication, to gain access to Windows must either:
Authenticate at the preboot screen.
Or
Go through one of the standard recovery mechanisms.
How do I re-enable reactive autoboot and disable preboot authentication to go back to my previous workflow?
The user must successfully authenticate at preboot or go through the needed recovery process to access Windows. After Windows loads and the DE services start, reactive autoboot is re-enabled automatically.
What Intel Active Management Technology (AMT) Integration features work with Reactive Autoboot?
Although in theory you can use the Location Aware use case from the Intel AMT integration with reactive autoboot, the combined use does not make sense for two main reasons.
First, while reactive autoboot is enabled, the AMT functionality is not used in preboot because the system boots directly into Windows.
Second, from a security and usability perspective, it is better to use the AMT functionality, and the 'Location Aware' use case. Both of these enable secure and authorized automatic booting of the system into Windows. If you have enabled this functionality, it is the more secure solution compared to reactive autoboot.
You might consider using AMT to remove or reduce Help desk calls from users when the reactive autoboot functionality enables preboot. This functionality might reduce the need for a Help desk call to continue past the preboot environment. But you can still encounter a scenario where the Help Desk call is required. More importantly, the AMT functionality provides data security by requiring an automatic preboot authentication to be provided by the server. By contrast, autoboot has no preboot authentication and provides no data security.
The user experience appears to be the same with the following applies:
When both the AMT integration and reactive autoboot are used
When the user fails to authenticate too many times
NOTE: But, there are back-end differences:
Example Scenario: IMPORTANT: You have enabled the Intel AMT 'Location Aware'. McAfee Enterprise recommends that you use that functionality, and not reactive autoboot. The reason is, because it provides data security by authenticating from the server. If needed, you can set a Windows policy to disable the user if they fail to authenticate after a set threshold.
Reactive autoboot is an insecure solution that boots into Windows using cryptographic information already present on the client.
The Intel AMT integration is a secure solution that contacts ePO, and requests permission to boot into Windows. It then receives the needed cryptographic information to do so.
On a client system using reactive autoboot, the AMT functionality in preboot is not used. When a user fails to authenticate repeatedly, reactive autoboot enables preboot and restarts the system.
Preboot uses AMT and contacts the ePO to receive permission to boot. If ePO does not respond, the user is in the same situation as traditional reactive autoboot without AMT.
The user is returned to the Windows authentication screen. The active autoboot is enabled because the system has booted into Windows. The user can continue to enter incorrect passwords until Windows disables the user.
This scenario might force a Help Desk call. Reactive autoboot is a client-side activity. There is no communication with the ePO server, and no time to communicate with the server when the functionality responds to failed logon attempts.
What isFast Initial Encryption (Used Sector Only)?
Fast initial encryption, is the ability to install the DE product on a system, and perform encryption in a matter of minutes. Compared to several hours that are required in normal circumstances.
Fast Initial Encryption (Used Sector Only) key features:
Fast Initial Encryption primary function is for the initial encryption of a newly installed/imaged system. The system is sitting on a desk of an IT Technician and is not being used by the user. You can see the 'In-House Provisioning' or 'Provisioning by a third party' use cases from the Offline Activation FAQs.
This feature can't be used with an Opal drive. There is no need to use Fast Initial Encryption with an Opal drive because the drive is technically always encrypted. The DE activation process enables the locking mechanism for the drive. Currently, an Opal drive goes from Inactive to Active and fully encrypted in a matter of minutes. Also see the Offline Activation FAQs.
You can't use Fast Initial Encryption as part of the normal activation process.
To view a detailed document covering the advantages of encrypting your computer in minutes using Fast Initial Encryption functionality, see KB81093.
Fast Initial Encryption can be used with a normal Hard Disk Drive (HDD) or Solid State Disk (SSD). But it is important to read the considerations about Used Sector Only (see below).
Other Fast Initial Encryption (Used Sector Only):
Fast Initial Encryption removes the power failure protection. Which provides protection against data loss in a power-failure or hard-shutdown scenario. It performs the initial encryption as quickly as the hardware allows. It also encrypts only the sectors that are currently in use.
Fast Initial Encryption differs from the way DE 7.1 and earlier releases worked. Traditionally, the product assumes that it is encrypting a system that is in use. It prioritizes the user experience to minimize impact on the user's daily routine. This fact has the benefit of allowing the user to continue working while encryption occurs and provides protection against power failure or a hard shutdown. In a standard deployment, the encryption process takes longer to complete. The reason is, because the DE encrypts every sector of the volumes and partitions. It encrypts any area that is specified in the encryption policy. Even blank sectors that contain no data get encrypted.
Fast Initial Encryption only encrypts used sectors. The product queries the operating system for which sectors are in use by the file system. The product then encrypts only those sectors that are flagged as being used in the volumes and partitions. Per volumes and partitions specified in the encryption policy. On a new installation, this number is generally a small subset of the total size of the disk.
When new data is written to the disk, as new sectors become used, they are encrypted.
Fast Initial Encryption is only available on Windows with DE 7.1. Because of Apple changes, MNE has replaced the EEMac product.
To enable Fast Initial Encryption as part of an offline activation package, use one of the following two options:
SkipUnused (Default value is disabled)
DisablePF (Default value is disabled)
This feature is not enabled by default for offline activation. You must explicitly enable Fast Initial Encryption.
Fast Initial Encryption is available only as a part of the offline activation process. The offline activation option is called Skip Unused Sectors.
Other Fast Initial Encryption (Used Sector Only) user experience facts:
When Fast Initial Encryption is enabled, the user must type Yes when using Used Sectors Only. This act makes sure that you have read the disclaimer and understand the use of this functionality. It is important to read the considerations about Used Sector Only.
When a user does not type Yes when prompted, the offline activation package is not built and the process fails. You need to rebuild the package again and correctly type 'Yes' or remove the 'Used Sectors Only' option from the package.
Does the Fast Initial Encryption option Used Sector Only affect HDD and SSD in the same way?
There is a larger impact and implication on SSDs because of the way SSDs operate. For more information about performance issues reported on some SSDs, see KB66256. Other Used Sector Only general facts:
The 'Used Sector Only' option means that there are no sectors on the disk that are not encrypted. The product only encrypts the sectors that the Operating System states are in use. All other sectors (white space) are left in an unencrypted state until they are used. Even if those sectors contain previously deleted sensitive data. Any new sectors written during normal operation are written in an encrypted state.
The recommendation for using Used Sector Only option applies to both a new HDD and SSD. This functionality can be used before any sensitive company data is written to the disk.
When you are recycling an older drive that was fully encrypted with DE, this functionality can still be used. Assuming all volumes that contained sensitive data were previously encrypted. If that condition is not met, You are recommended to not use this function.
To view data that shows the improvements when using Fast Initial Encryption (Used Sector Only), see KB77844.
IMPORTANT: Do not use this functionality on disks that previously contained sensitive company data. Encrypt the entire volume/partition/disk.
Can I restart a computer while the hard-disk is being encrypted?
There are two scenarios to consider:
You can't restart while using Fast Initial Encryption and when the DisablePF feature is enabled. A system restart under these conditions would lead to a loss of data.
With Full Disk Encryption (FDE), a restart is possible. With FDE, encryption continues when the computer has restarted.
Can I still perform a normal or offline activation withPower-failure Protection enabled and encrypt all sectors, not just the ones in use?
Yes. You must explicitly enable Fast Initial Encryption for it to be used. If it is not enabled, the normal process for activation and initial encryption is used.
Can I disable the Power-failure Protection option but allow the Used Sector Only encryption functionality?
Yes. Any combination of the two options can be selected. But, because of the potential security concerns when using 'Used Sector Only' encryption on recycled drives (dirty disks), it is possible to disable this option. It is important to read the considerations about Used Sector Only
What isUEFI?
UEFI (Unified Extensible Firmware Interface) defines the next-generation firmware interface for your personal computer. The Basic Input and Output System (BIOS) firmware, originally written in assembly and using software interrupts for I/O, has defined the PC system since its inception. But, changes in the computing landscape have paved the way for a modern firmware definition to usher in the next generation of tablets and devices. Other UEFI facts:
UEFI is managed through the UEFI forum. A collection of chipset, hardware, system, firmware, and operating system vendors. The forum maintains specifications, test tools, and reference implementations that are used across many UEFI computers.
The intent of UEFI is to define a standard way for the operating system to communicate with the platform firmware during the boot process. Before UEFI, the primary mechanism to communicate with hardware during the boot process was software interrupts. Modern PCs can perform faster, more efficient block Input/output between hardware and software. In addition, UEFI allows designs to use the full potential of their hardware.
UEFI allows for modular firmware design that enables hardware and system designers greater flexibility in designing firmware for the more demanding modern computing environments. Whereas I/O was limited by software interrupts, UEFI promotes the concept of event-based, architecture-neutral coding standards.
DE 7.1 supports UEFI version 2.3.1 and later.
Windows 7 (64-bit) and Windows 8 (32-bit and 64-bit) and later systems support a UEFI Boot Process.
What are the key features of using UEFI with DE?
There are different recovery tools for systems with a UEFI boot process. Because it is a different boot process, a different recovery tool is required to handle the different boot processes.
DETech is also a UEFI application. There is a DETech application that is used for recovery on systems with a UEFI boot process. NOTE: You can't use the (legacy) BIOS DETech tools with a UEFI booting system.
IMPORTANT: A system with a UEFI boot process does not work with MBR partitioned disks. Windows requires a new mechanism for disk partitioning, called GPT, to boot under UEFI.
All supported tokens and readers work in both BIOS and UEFI, with the following exceptions: To review the supported tokens for authentication in DE 7.1.x, see KB79787.
To review the supported Readers for authentication in DE 7.1.x, see KB79788.
All biometric tokens
SafeNet’s eToken USB tokens
DE preboot is an application. If you consider that UEFI is like an Operating System, the DE preboot becomes a UEFI native application. In comparison, the BIOS preboot version is an operating system of itself. In both, the DE preboot needs to run first so that after a successful authentication, the encryption key can be loaded and the boot process can continue. In the UEFI world, when a user successfully authenticates at the DE preboot.
Not all touch-screen devices are supported in UEFI. If you think of UEFI more like an operating system, the OEMs need to provide software drivers for the hardware contained in that device. For UEFI, the preboot supports both the Simple Pointer Protocol and the Absolute Pointer Protocol. One or both of these protocols are expected to be implemented for all touch-screen devices encountered. If a manufacturer or OEM of the UEFI implementation has failed to implement either of these mechanisms, support for the touch-screen device can't be guaranteed. NOTE: McAfee Enterprise has found in its own internal testing that not all UEFI implementations from OEMs actually implement these interfaces. In these instances, the creator of the UEFI implementation on that system is leaving out sections of the UEFI specification.
GPT drives are supported with UEFI. They are supported as boot or secondary disks.
UEFI implementation across all vendors. UEFI implementations differ by hardware vendors. Depending on the UEFI implementation, issues can range from:
Missing protocols required to support Opal drives.
Issues to support USB provided in the preboot environment, and used by DE when operating in native UEFI mode.
Opal drives supported in UEFI:
Support for Opal self-encrypting drives on UEFI systems is available only on Windows 8 or later logo-compliant systems that were fitted with an Opal self-encrypting drive when manufactured.
Support for Opal self-encrypting drives under UEFI is not offered when:
Retrofitting Opal drives to pre-Windows 8 systems
Or
Retrofitting to Windows 8 systems that were not shipped with Opal drives from the manufacturers.
The reason for the above, is because a UEFI security protocol that is required for Opal management. It is mandatory only when a self-encrypting drive is fitted at the time of shipping. Without the security protocol, Opal management is not possible.
NOTE:This fact does not affect support for Opal drives under BIOS. For a list of supported drive models, see KB81136.
Is there support for GUID Partition Table (GPT) drives?Windows 7
As a boot disk, no. As a secondary disk, yes. Also, it is up to the operating system to support the secondary drive in GPT mode, and for the BIOS to support large disks for DETech (Standalone) to recover them.
Windows 8 and later
Primary and Secondary GUID Partition Table (GPT) disks are supported on Windows 8 with DE 7.1.0 and later.
NOTES:
UEFI-based systems can only boot from a primary GPT disk.
BIOS-based systems can't boot from a primary GPT disk. On these systems from EEPC 7.0 and later, GPT disks are only supported as a secondary drive.
What is the User experience when the system is using UEFI?
Both preboot environments look and behave the same. A user could not tell the difference between the UEFI and the BIOS preboot environment.
Why must I create and use DETech WinPE recovery media, when the DETech Standalone version includes more functionality. Such as making an Emergency boot?
The WinPE version is much faster than the standalone version.
The WinPE version also allows you to access the encrypted hard disk, fix Windows problems, or copy user data off to another drive before reimaging.
You can also run any of the Windows tools as well, and access the network.
NOTES: DETech Standalone is not backward compatible. Always use a matching DETech recovery media version. If the client has DE 7.1 installed, create a DETech 7.1 Standalone recovery media to perform any recovery actions.
IMPORTANT: It not possible for McAfee Enterprise to provide customers with a WinPE recovery CD because a valid Microsoft license is needed.
What is Secure Boot?
Secure Boot is a feature enabled by UEFI, but Microsoft mandates specific implementations for x86 (Intel) PCs. Any system with a Windows 8 logo sticker has Secure Boot enabled.
UEFI has a firmware validation process, called Secure Boot, which is defined in Chapter 27 of the UEFI 2.3.1 specification. Secure Boot defines how platform firmware manages security certificates, validation of firmware, and a definition of the interface (protocol) between firmware and the operating system. It creates a root of trust which begins in UEFI. Which validates the next module in the chain before loading, and executing it. The validation makes sure that it has not changed since it was digitally signed. With the Secure Boot architecture and its establishment of a chain of trust, the customer is protected from malware executing in the boot process. Only signed, certified 'known good' code and boot loaders can run before the operating system itself loads. Other Secure Boot general facts:
DE 7.1.x does support Secure Boot.
DE is signed, so the Secure Boot process trusts it.
Secure Boot does not work on Windows 8 or later BIOS-based systems. It works only on UEFI-based systems.
What isHybrid Boot / Fast Startup / Fast Boot?
In previous versions of Windows, a traditional shutdown would close all user sessions, services, and devices, and would also close the kernel to prepare for a complete shutdown. Windows 8 closes the user sessions, but instead of closing the kernel session, Windows 8 hibernates it. The result is faster shutdown and start times. NOTE: Microsoft Windows 8 adds support for Fast Boot (previously known as hybrid boot); with the release of Windows 10 and later, this feature is now known as Fast Startup.
Other Hybrid Boot, Fast Startup, Fast Boot general facts:
DE 7.1.x does not support Hybrid Boot, Fast Startup and Fast Boot are not supported. DE features are impacted if they are enabled.
Single Sign On (SSO) works in a Hybrid Boot. DE supports SSO on a resume from hibernate, unlike the previous EEPC releases.
DE 7.1 includes enhancements across all areas of performance, which are unexceptionally experienced with an AES-NI capable processor. In internal testing, DEhas experienced comparable encrypted/non-encrypted boot times using Hybrid Boot.
I see references to Windows RT. What is it?
Windows RT (formally known as Windows on ARM) is a version of Windows 8 for ARM devices. Only software written for the Windows 8 Modern UI interface runs on Windows RT, except for Microsoft Office 2013 RT and Internet Explorer 10. Any application written using the Win32 APIs, which is most current applications, does not run on Windows RT.
What is a WindowsTablet?
A Windows Tablet is a tablet-style device capable and certified to run Windows. There are two major categories of Windows tablets:
Tablets powered by Intel processors
Tablets powered by ARM processors
Other Tablet general facts:
DE 7.x does not support Windows Tablets using an ARM processor and Windows RT
DE 7.x does support Windows Tablets using an Intel processor. These tablets are seen as any other Windows system. But, examine the following cautions:
CPU capability
Touch-screen support
CPU capability on the Tablets. The product development team has noted that some previews of Windows tablet devices from manufacturers contain lower powered processors. Some of which do not have AES-NI capabilities. Customers must be aware of CPU capabilities to make sure that the user has an optimal experience when the system is encrypted.
Touch Screen Support on Tablets.
Some Windows Tablets have keyboards, so touch-screen support is not an issue. For the devices that do not have keyboards, these devices require the user to authenticate using the touch interface in preboot.
What isoffline activation?
Offline activation is the ability to activate DE without a connection to ePO
Other Offline activation general facts:
High-level process for offline activation:
An administrator creates an offline package on the ePO server. This package contains the first policy that needs to be created, and a list of 'offline users.'
After the package is created, it can be distributed to the clients with the MSIs needed to install DE. When DE is installed successfully, the offline package is run and the policy is applied and enforced.
You can now log on with the 'offline users' in preboot.
There are no audit logs in ePO to find information about a system activated via offline activation. Expected behavior because the system has never communicated with ePO; there is no information about that system.
If a device is activated only via offline activation, you are not able to prove that it was encrypted. If the system never communicated with ePO. There is no information in ePO that can be used for auditing purposes, if there is loss or theft. After the system communicates with ePO and goes into an online mode, all normal information is present in ePO. When the transfer is complete, it proves the encrypted state of the system.
Add Local Domain Users (ALDU) does not work offline activation. ALDU is a two-step process that requires ePO to perform the user/system assignment. Because ePO is not available with offline activation, ALDU can't complete and can't be used.
To define the initial policyfor offline activation, use the parameters available in the offline package creation utility.
A system discards all offline users after the system successfully communicates with the ePO server.
What are the Use Cases for offline activation?
The three primary use cases addressed by offline activation are:
In-house provisioning.
Provisioning by a third party.
A remote system that never connected to ePO.
NOTE: There are other use cases where offline activation can be useful; but, DE 7.1 focuses on these three use cases.
An in-house provisioning use case for offline activation is where you might have your own provisioning process. The process might state that a system needs to have the operating system installed, plus all company-approved applications. The disk must be fully encrypted before it is handed to the user. At the point of provisioning, you might not have network connectivity because the devices might be sitting on a shelf in a separate room.
Provisioning by a third-party use case for offline activation. You might have an external third party to provision your devices. In this scenario, you don't want to open up your firewall to allow connections to ePO, yet you require that all laptops need to be encrypted before delivery.
The use case for offline activation for a remote system that never connects to ePO.
You have a client in a remote location.
The client has no network connectivity.
The system might collect sensitive data and needs to be encrypted.
You can distribute a CD with the MSI packages. The packages install McAfee Agent, DE, and the Offline Activation package.
The MSI packages then run to install, activate DE, and encrypt the system.
How does recovery work for offline activation?
If the administrator has selected to save the encryption key, the key is written to a file on a disk. It is then the responsibility of the user to transfer that encrypted key to the administrator using a company-approved method. When administrators have the encrypted key, they can decrypt it when needed using the ePO server that created the offline package. The result of this decryption process is a standard XML file that can be used with the DE recovery tools.
Other Offline activation general facts:
There is only one recovery option available for an offline activation. This option is a local recovery using the DE recovery tools.
If the administrator disabled local recovery, the only choice is to use the DE Recovery tools to correct any issues with the system. It is also possible to connect the system to ePO. At which point the users and policies would be replaced with the information provided by ePO. But, this scenario requires the ability to boot into Windows.
There are no additional recovery options for offline activation when:
Local recovery is disabled
And
You have not saved the encryption key
What are the key features about offline activation for installation?
Consider systems activated by offline activation as unmanaged systems. The reason is because you might not see them in ePO, and you are not able to manage them in ePO.
IMPORTANT: There is not a standalone, non-managed version of DE for systems that are offline and activated. Offline activation might allow you to create a standalone system that is encrypted per a specific policy. But, after the first policy enforcement is complete, you can't update the policy or the users. There is no local console and no method to update the policy or user information. But, a key recovery mechanism is supported. For details, see the offline user recovery FAQs below.
For offline activation, the important fact is that DE can be installed on the system. The installation method you use - for example, a CD/DVD to users with MSIs they can run, or a more automated method - depends on your specific environment.
The following installation requirements are required for offline activation:
McAfee Agent
McAfee Endpoint Encryption Agent
DE
Offline Package created by the Administrator
A system can be activated through offline activation to ePO later from ePO.
When an offline activated system connects to ePO, the following occurs:
Assuming that the offline activation was done for provisioning purposes, the system does at one-point connect to ePO.
When the system can successfully communicate with ePO, the client moves into an Online mode.
Online mode is defined as a normal connection between the McAfee Agent and ePO; consider it the same as a normal install.
Other details:
It discards the offline policy that was enforced, and it also discards all offline users. It receives the real policy from ePO, the list of assigned users according to normal activation, and saves its encryption key in ePO. You could view it as a second but automatic activation. IMPORTANT: Remember that all offline information is discarded, if the user is not known to the ePO server before connection. If the offline user is known to the ePO server, the ePO policies are deployed. But any data they have stored while in offline mode is not discarded.
What is anoffline user?
An offline user is one who is used for preboot authentication and that exists only in a specific offline package. Other Offline User facts:
An offline user is different from a normal user in DE. Offline users exist only in that specific offline package. These users do not exist in Active Directory, and basically do not exist anywhere except in this offline package.
You can't add more offline users to an offline activated system after activation is complete and it has been out in the field for a while.
An offline user starts with the default password
You can recover a password if an offline user forgets it because users can use the local recovery functionality to recover.
Considerations for using tokens (other than a password) for offline users:
Passwords and smart cards that support Self-Initialization can work in offline activation.
Smart cards that are PKI only can't work because there is no back-end to retrieve the needed information to authenticate the user.
Biometric support is not possible.
Self-Initializing tokens are identified in the DE Supported tokens article KB79787.
Other Offline User recovery facts:
When an administrator disables Local Recovery, offline users are locked out. If there is another user on the system, they can use to boot the system, or connect the system to ePO. But, this alternative requires the system to boot into Windows.
When the offline user has forgotten both their password and their local recovery answers, the user is now locked out. If there is another user on the system, they might boot the system, or connect the system to ePO. But, this alternative requires the system to boot into Windows.
If you have an offline user called Bob, and an AD user called Bob, when Bob goes from offline to online, what happens to the password?
Assuming that AD user Bob has signed into the system at least once. An ALDU was active on the ePO policy, then Bob is assigned to the system after the offline Bob was discarded. NOTE: From this point, the AD user Bob can have two possibilities. If logging on at preboot for the first time, Bob has the default password. If not, and if ePO already has credentials for Bob, those credentials from ePO are on the system.
Is an offline policy the same as a policy defined in ePO?
No. There are some policy settings that require interaction, such as Add Local Domain Users (ALDU). These policy settings can't be used in an offline activation.
Other Offline Policy general facts:
You can't update the policy of an offline activated system after activation is complete and after it has been out in the field for a while. Offline activation only enforces the first policy. There are no possible updates after the first policy is applied.
A system discards all offline users after the system successfully communicates with the ePO server. It discards the offline policy and asks ePO to provide the appropriate policy.
The following settings are available for an offline policy:
Back up the Device Key
Path to the recovery key
Enable temporary autoboot
Enable autoboot
Don’t display the previous user name
Enable SSO
Enable boot manager
PBFS Size
Opal PBFS Size
Require user changes their password
User name must match Windows logon user name
Enable self-recovery
User smart card PIN
Enable USB in preboot
IMPORTANT: When the computer is fitted with an Opal drive, offline activations use Opal Encryption first. OPAL preferences are hard-coded in the Offline Activation Packages and do not use the custom policy settings.
What happens to theencryption keys during offline activation?
When the administrator configures the offline activation package, there is an option available to indicate whether the keys are saved or not. The decision of whether to save the keys, and to which location, is solely at the discretion of the administrator. It is not something the user can choose or manipulate.
Other Encryption key general facts:
When you have received the encrypted key, an administrator can decrypt it and export the information in the XML format used by the DE recovery tools.
If you save an encryption key from a system that has completed the offline activation process, you can't import the key into ePO. But, you can store all your keys in a secure location and use ePO to decrypt them and generate the needed recovery XML files.
If the encryption keys can't be saved because of some other fault, the hard disk on the client must be reformatted. The Offline Activation process must then be restarted.
The encryption key is not written to a plain text file on the disk, and the encryption key is always encrypted. If a third-party application intercepted the key, it would not be useful for them. Nor would they have a way to identify to which system it belonged.
The only location where the encryption key for an offline activation can be decrypted is the ePO server that created the offline package. No other ePO server can decrypt the key.
All offline activations do not have the same encryption key. During the first policy enforcement, the encryption key is generated. This fact makes sure that all offline activations have a different key.
Other Encryption key use cases facts:
Regarding the encryption key for the system in the in-house provisioning use case:
You might or might not want to save the key. Remember that on the first connection to the ePO server, it uploads the key. This scenario primarily covers new systems. There is little user data to lose, If any of the following occurs:
Any physical defect is found that causes the disk to crash
Or
You become locked out of a system
NOTE: You can save the key to a USB drive, or a specific network share in case a recovery is required.
Regarding the encryption keys for the system in the provisioning by a third-party scenario:
It is likely that you do not want the third party to save the encryption key. So you would specify to not save the key anywhere. WARNING:If the third-party application copies each encryption key for all systems in your organization, that would be considered a security risk.
Because this scenario primarily covers new systems, there is little user data to lose when:
Any physical defect is found that causes the disk to crash.
Or
You become locked out of a system.
Regarding the encryption keys, where the encryption keys for the system never connect to ePO:
It is likely that you want to save the encryption key to a USB drive or to the hard disk. This step is optional and is purely at the discretion of the administrator. It is then your responsibility to make sure that the encryption key is safely transported to ePO for safekeeping. This transport can be achieved by any mechanism that your organization approves for encryption keys. After the ePO administrator has a copy of the saved key, it can later be used for recovery purposes.
What is included in thePreboot File System (PBFS)?
The PBFS contains all needed information to provide the user with the ability to authenticate. This information includes but is not limited to:
The files needed for the preboot environment
Language files for all supported client languages
Fonts to display characters from all supported languages
The theme assigned to the client
The users assigned to the client
Other PBFS facts:
If you deploy to a client and increase the size of the PBFS in the policy later, the PBFS size does not change on the deployed client. The PBFS size setting gets applied only when the PBFS gets created, or re-created during any recovery procedure.
It is possible to create and customize preboot themes in ePO.
You can't force during preboot an English keyboard when first installing DE 7.x to a non-English operating system. The reason is because by default, the DE installer displays the localized keyboard associated with the localized Windows operating system that the product is installing to.
How long does it take for a newly created user to be available in PBFS?
There is no short answer to this question. The following scenarios try to cover the most common situations:
Scenario 1
If only one uninitialized user is assigned to a system. Only one ASCI is required, given that the user is verified via the EE LDAP Sync task in ePO. NOTE:An uninitialized user is a user that has not previously logged on any DE system. So no token data is present for this user.
Scenario 2
If a new uninitialized user is added to a system that already has users assigned. It might require two ASCIs before the user is fully available in the PBFS.
Scenario 3
If an initialized user is newly added to a system that might or might not already have users assigned. Two ASCIs are required until the user is fully available in the PBFS. The reason is because this user has its token data already initialized.
To summarize: When a user gets assigned to a system, the policies for this system are incremented. During the policy enforcement, an event to request user data is triggered. When ePO returns that event, all users that have been assigned are verified and downloaded to the client.
For an uninitialized user, where there is no token data, the secondary event is not needed to pull all required user data down, and into the PBFS. As for the other scenarios, it requires two events to make a user fully available in the PBFS.
In addition, if the customer is using the policy option Add Local Domain User (ALDU), there is a 2.5 ASCI timeout that is triggered. Occurs when the ALDU request is not responded to. If this timeout is exceeded, a new policy enforcement is required to upload user data for verification. What are the DE 7.x custom theme requirements?
Create the custom theme according to the following requirements:
An image with dimensions 1024 x 768
Make sure that the file format is .PNG
A file size of about 600 KB
NOTE: Users upgrading from EEPC 6.x, a new default theme is shipped as part of DE 7.1.x. If you are using customized themes with EEPC 6.x, re-create your custom themes from DE 7.1.x default theme after upgrade. This approach makes sure that the correct user interface gets displayed, and the correct audio is heard. Failure to do so continues to display the EEPC 6.x user interface and use the EEPC 6.x audio. Those users who want to deploy the new default theme to all their existing endpoints, or have their own custom theme, must follow the steps outlined in the DE 7.1 Release Notes. These steps make sure that they are using the correct theme during PBA.
What is the Pre-Boot Smart Check (PBSC)?
The PBSC is functionality in DE that performs several preboot hardware compatibilities checks. The checks make sure that the DE preboot environment can work successfully on a system. It tests the areas that have been identified to cause incompatibility issues in the past.
Other Pre-Boot Smart Check general facts:
The goal of the Pre-Boot Smart Check, is to help with providing a hassle-free deployment of DE full disk encryption. Which is achieved by looking for common error conditions in the preboot environment. Without the checks enabled, productivity could be affected where deployment issues might lock users out of the system. Pre-Boot Smart Check deactivates DE if there is an issue, and allow the system to roll back to Windows-only authentication.
The Pre-Boot Smart Check functionality is not enabled by default because it introduces one or more systems restarts to the activation process. Some customers can accept this situation, and others might not.
When Pre-Boot Smart Check finds a problem, either a failure to load preboot or a problem handing over to Windows. Ether the system restarts automatically, or the user must forcibly restart the system. Which allows PBSC to try a different set of compatibility configurations to overcome the problem. If any configuration works, and the system boots into Windows, the DE becomes fully activated and the encryption policy is enforced.
If all compatibility configurations have been tried, and unrecoverable problems are encountered, DE preboot is bypassed. In this situation, the system boots into Windows, and DE is deactivated. At this point, an audit is sent to ePO alerting the failure, and subsequent activations on the system are blocked.
When a system passes the Pre-Boot Smart Check, it activates DE and enforces the encryption policy.
What happens if a system fails the Pre-Boot Smart Check?
If a system fails the Pre-Boot Smart Check, it does not activate DE. So, DE activation (and encryption if set in the policy) does not continue, and the system "rolls back" to Windows-only authentication.
Other Pre-Boot Smart Check failure general facts:
For a system that is still running through the Pre-Boot Smart Check, the ePO administrator, can only see that the system is not activated, and not encrypted.
They can view the audit log, to obtain the progress from the last time the system synchronized with ePO.
The Administrator can see that a system has not activated, because the failure is audited.
For an administrator to see that a system has failed the Pre-Boot Smart Check, view the audit log for the system.
If a system fails the Pre-Boot Smart Check, it keeps trying to activate DE at the next policy enforcement. But, activation is immediately abandoned. All subsequent activations are immediately abandoned until either of the following happens:
You disable PBSC from policy
You delete the registry value: Software\McAfee Full Disk Encryption\MfeEpePc\SafeFailStatus\Status
NOTE: Also, a workaround could be to set up an automatic response in ePO based on the Event ID. That way, when an event arrives in ePO (the event that indicates PBSC failure), ePO can automatically assign a new policy to that system. That policy would be configured to disable DE and thus stop future activation attempts. See the ePO documentation for further information.
How can I know if the Pre-Boot Smart Check modified the configuration?
This information is not exposed in DE 7.1. It is transparent to the user and happens automatically.
If the Pre-Boot Smart Check has not made any changes, and the system worked out of the box. Does that indicate that I can disable that check for deployment purposes?
It is at the discretion of customers whether they disable the check. But, variability is common among systems that have the same model number. For example, a user could have gone into the BIOS and changed their USB settings.
Changes to USB settings might affect integration with that BIOS, so keeping PBSC would add value here. But, if you use BIOS passwords to keep your users from making such changes, you might be safe not using PBSC.
What versions of Intel Active Management Technology (AMT) are supported using ePO Deep Command and DE?
To see which versions of AMT are supported, see KB79422.
NOTE:The AMT version is part of the information that an administrator can view on a computer. The collated information is reported back to ePO Deep Command.
Other Intel AMT general facts:
An Administrator can learn how to determine if they can use Intel AMT functionality on a particular system. Achieved by viewing the system properties in ePO. In ePO, you can see the AMT information for that specific system. McAfee ePO Deep Command Discovery and Reporting (free) also provides this information for all managed systems in ePO, and displays it in a dashboard. To be compatible with DE, Deep Command must report the AMT status as Post configuration. Also, DE requires AMT to be version 6.0 or later.
How the Intel AMT information about a system is transferred into ePO.
First, you have installed the Deep Command extensions. Including the Discovery, and Reporting extensions, and checked in the packages on the ePO server.
You must deploy the Deep Command packages to the clients, which report back if AMT is enabled. In addition, if the system has activated AMT, the client reports back what AMT features are supported.
Deep Command adds a schedule server task to ePO that automatically tags the systems with AMT. This task is scheduled to run daily and can be altered. See the ePO Deep Command documentation for more information.
If the system has not activated AMT, see the Deep Command Discovery and Reporting Summary Dashboard to obtain AMT support information from a client.
How many types of Intel AMT actions can be queued against a system?
Two types:
Transient Actions
Permanent Actions.
Examples of Permanent and Transient Actions:
Transient action is an action that is executed x number of times and then removed from the action queue. Below are some examples:
Reset User Password
Unlock x number of times
Unlock from until
Emergency Boot
Restore MBR
Permanentaction is an action that remains in the action queue, until the administrator removes it.
Unlock Schedule
Unlock Permanently
Other Permanent and Transient facts:
For each Intel AMT action, you can only assign the following at one time:
A system, or user a maximum of one Transient action.
And
One Permanent action.
You can only have one Intel AMT Transient, and one Permanent action. A design decision taken for this first implementation of integration with Intel AMT. If other use cases arise, this decision can be revisited. The underlying architecture has been designed to handle more actions if needed.
What does Client Initiated Local Access (CILA) and Client Initiated Remote Access (CIRA) mean in relation to Intel AMT?
The definition of what is local and remote is defined as a part of the AMT provisioning process.
CILA is an AMT request from an internal network address.
CIRA is an AMT request from a remote network address.
NOTE: The default policy setting for CIRA is disabled by default. This decision was a conscious one by the product development team to protect customers from accidental exposure.
CIRA is supported, and must explicitly be enabled. Disabling CIRA, means that if an Agent Handler is exposed to the internet, it can't respond to any AMT requests. The product development team believes that customers need to decide whether they want to enable this functionality.
When I watch a Wakeand Patch (Remote Unlock) or Contextual Security (Unlock) on a client, the preboot seems to wait for about 20 seconds before it continues to boot into the operating system, is that normal?
There are many factors involved in determining how long this time might last. The speed of the network and the workload of the ePO server are two possible factors. A known issue exists in AMT firmware, which might lead to a 20-second delay before CILA events leave the endpoint. The effect of this issue on DE is that it might take over 20 seconds for an Out-of-band unlock to occur in a CILA environment. McAfee Enerprise is investigating this issue. To review other DE 7.1 Known Issues, see KB84502.
What Deep Command policies and settings are required for DE 7.1 integration?
ePO Deep Command 1.5.0 and the Intel AMT policies are required. Which makes sure that the following are configured correctly in the policies:
Remote Access must be enabled.
Enable Client Initiated Local Access (CILA). Choose the correct agent handler.
For the Connection type, select BIOS and operating system.
If you want Client initiated Remote Access (CIRA), make sure that you have configured the following:
Home Domain Suffix
DMZ agent handler
Allow User initiated tunnel
What are the first DE use cases implemented in DE 7.1.x using Intel (AMT) and McAfee ePO Deep Command?
The first four use cases implemented in DE 7.1.0 are:
What is theReset Password Use Case?
This functionality uses Intel AMT to send new token data out to a client. In this use case, a user has started their system and has forgotten their password. They can call a helpdesk, or administrator and request that they reset the password. The administrator creates a one-time password that is pushed out via the Intel AMT to the client while in preboot. Using Intel AMT is a faster alternative for a password reset than the long-established challenge/response method. Other Reset Password general facts:
The following are the high-level steps for the Reset Password Use Case:
The user starts their computer, fails to log on, and calls the help desk.
The user goes to the Recovery section in preboot and provides the help desk user with their ePO user name.
The help desk operator finds in ePO the System the user is using.
The help desk user uses the Intel AMT functionality to reset their password with a temporary one-time password.
For the specified system to receive the new token data, ePO writes the item to the work queue. The preboot reads the work queue, and fetches the key by using the network stack provided by Intel AMT.
The client receives the new token data and automatically leaves the recovery screen and goes back to the password screen. This fact is an indication for the user that the new password has been received. Also, the user hears a beep to indicate that the new token data has been received.
The user then authenticates with their one-time password and sets a new password.
Actions required when a user requires a password reset. To determine what system the user is on, the user on the client, in preboot, must go to the recovery screen. In the recovery screen they can view the Computer ID, and Computer Name. They can give this information to the administrator, or help desk and find the computer in ePO. The procedure is needed because Intel AMT actions work on systems rather than users,
Other Reset PasswordAdministrator role facts:
When an administrator needs to verify that a change went through successfully, or validate why it does not appear to work. The administrator can find the information in the AMTService.log file. NOTES:
An event is not generated in ePO because there is no ePO API to do generate an event from the agent handler.
The administrator can find the AMTService.log file on the ePO server at <ePO_Install_folder>/<Agent_Handler_Install_Folder>\DB\Logs\AMTService.log. It is also collected as part of the server MER.
The following is not recommended when an administrator want to determine what system the user is using. It is possible for the administrator to send the Intel AMT command to all systems that the user can access.
Reasoning:
Assume that the user can access two laptops.
They start laptop-1 and they receive the instruction to change their password.
They go through the process and start Windows.
They now turn on laptop-2, which also receives the request to change the password.
Their token data is updated to the one-time password, and they are asked to change it again.
In theory the above could work in a controlled environment, or where the user is aware.
Other Reset Password user experience:
Administrator has used the Intel AMT functionality to change the user’s password. The user knows that the new recovery password has come through to the client. If the user is sitting on the recovery screen, they see that the recovery screen disappears. Shortly after, it will be replaced with the logon screen. This indication confirms that the new password information has been received. NOTES: When the new token data is received, the user hears a beep.
What is theContextual Security Use Case?
The Contextual Security use case (also known as Location Aware) is a new authentication feature in the DE preboot environment. It gives systems the ability to authenticate without user intervention. Instead of asking a user for credentials, the preboot uses Intel AMT to initiate a network connection to ePO. Then, the preboot retrieves a key that it uses to authenticate in the preboot and then boots the computer into the operating system. The preboot environment and ePO can determine if the system is in the office or connecting via the internet. Contextual security gives administrators the ability to configure systems to authenticate automatically via ePO and AMT while in the office. But when the system is out of the office it shows the preboot authentication screen.
Some example use cases where Contextual Security is useful are:
Customers who want to not show the preboot environment while their users are in the office. But show it when they are outside the office or if the system is lost/stolen.
Encrypt a system that is always in the office. But not impact the user with the notions of preboot, and have them automatically authenticate via ePO and AMT. But, show the preboot if the computer is stolen from the office.
Customers who have shared computers used by many individuals. Think of a meeting room, training room, or laptops and desktops in a hospital environment/.
Customers who want to remove password synchronization issues, by never showing preboot. But while having its protection, if the computer is lost or stolen. Users first authenticate at Windows, even though behind the scenes, DE has automatically authenticated via ePO and AMT.
How does Contextual Security work?
When the preboot starts, it tries to contact ePO, and asks for permission to boot. ePO is in control, and decides whether to return the unlock key. If the client can't contact ePO, or ePO fails to return the unlock key to the client, the preboot environment is displayed. The preboot screen remains displayed, while it waits for a user to successfully authenticate. If ePO sends the unlock key, the computer is unlocked. The unlock keys are sent to the client down a secure channel, secured by the AMT hardware. Other Contextual Security facts:
Contextual Security authentication actually occurs on the client, but the information comes from ePO.
Contextual Security does not bypass preboot. The preboot environment is always there and always active. Preboot still shuts down and boots the operating system when a successful authentication occurs. In this use case, the authentication comes from ePO.
Single Sign On (SSO) does not work in this Contextual Security use case because the authentication in preboot is done against the computer and not a user. Because DE does not know which user to log on, it can't replay any captured SSO data.
With Contextual Security, the user only needs to log on once. In this scenario, the user authentication takes place at the Windows prompt and not the DE preboot prompt.
Using Contextual Security means that the user only ever logs on to Windows with their latest Windows password. This fact can remove any concern about password synchronization for users who continually use this functionality.
With a mobile user who spends time in and out of the office, these users need their credentials to authenticate at preboot when they are not in the office.
The computer automatically boots into Windows, as long as ePO sends back a positive response. It automatically boots the operating system, after the response has been processed.
If a computer is stolen when using Contextual Security, it displays the preboot environment. The preboot is shown because the system can't communicate with ePO and waits for a user to authenticate.
The most unexceptional use case, is to only use this feature for desktop systems or laptops that do not leave the office network.
Other Contextual Security Administrator role facts:
For administrators to enable the Contextual Security functionality, they must:
Select one or more systems
Select the 'Out of Band – Unlock PBA' action
Specify the duration of the unlock, either permanently or to a schedule
NOTE: An administrator can also choose whether the action is actionable for local, or local and remote computers.
When an administrator receives complaints from a user that, from time-to-time, Contextual Security is not working, then to verify that on the ePO server, review the 'AMTService.log'. This file does roll over, and has a file size limit (default size limit is set via Deep Command. The setting is configurable).
When the administrator enables Contextual Security functionality, they can enable it permanently, or for a defined time.
For the defined period options, an administrator can specify one of the following:
One or more reboots
From start date/time to end date/time
A weekly schedule for blocked or available times
For mobile users, it is better to always enforce preboot authentication because technically a user does not log on at preboot in this use case. DE is not aware of password updates because it does not know to which preboot user to apply any password updates.
When using Contextual Security, the system remains in the preboot environment. It retries every five minutes, if the ePO server is busy and can't respond to the system.
If the system fails to reach ePO on the first attempt, it tries again. It tries to contact ePO every five minutes. This behavior is true for CILA (Local) requests. But, for CIRA (Remote) requests, the computer only contacts ePO once. If it does not receive a response, the system must be restarted to contact ePO again.
The ePO server becomes unavailable, and the client can't contact the ePO Server. If the user does not know their preboot credentials, they are stuck in the preboot environment. Their only option is to call the help desk and do a system recovery with the challenge and response process.
When CIRA is enabled, it means a system that is not on the network can't automatically boot. DE makes no decision on whether to display PBA. If DE 'Out of Band management' is enabled, DE tries to send a call for help.
The AMT chip then checks the environment and sees if it is plugged in on the Remote or Local Network.
Local network. It posts a CILA to the ePO server.
Remote network. If a CIRA server was specified, it tries to securely connect to it.
PBA unlocks and goes into Windows if the following is true:
A call from CILA or CIRA, result in a successful connection with the server.
The server sends the encryption key.
Otherwise, if no key is received, it remains at PBA.
Other Contextual Security user experience:
Example Use case:
What actions do users take when they use a desktop system in the office with Contextual Security functionality. Have never needed to log on to preboot before, but then see the preboot screen, and they do not know their credentials. Users have several choices:
First, they could wait five minutes for the next attempt to contact to ePO. Which is true because it is a CILA (Local) request.
Second, they can turn their system off and on again. Which causes the preboot to immediately contact ePO again when it restarts.
Last, they can always authenticate by entering the user name and password of another known user who can authenticate at preboot.
What is theWake and Patch (Remote Unlock) Use-Case?
This use-case covers the need to urgently or regularly schedule wake and patch computers. These computers are shut down and need to be woken so that the update can be applied to them. The Wake and Patch (Remote Unlock) use cases are similar to the Contextual Security use cases. The following questions already answered for Contextual Securityalso apply to Wake and Patch (Remote Unlock option:
How does this work?
Is this bypassing preboot?
If I was a user standing in front of the computer, would I see it automatically boot into Windows?
Does Single Sign On (SSO) work in this use case?
What happens if ePO is busy and can't respond to the system?
If the system fails to reach ePO on the first attempt, it tries again?
How does an administrator enable this functionality?
Can this functionality be set permanently or just for a specific time period?
Does authentication actually occur on the client, and the information comes from ePO?
Other Wake and Patch (Remote Unlock) general facts:
When the ePO server is busy, and does not respond after a wake on LAN request. The client system stays in preboot, and tries again every five minutes. Although true for CILA (Local) requests, for CIRA (Remote) requests, the computer only contacts ePO once. If it does not receive a response, the system needs to be rebooted for it to contact the ePO server.
To reach a system periodically, it needs to be configured to send CIRA messages periodically using the Alarm Clock. The Alarm Clock feature switches on the system at the time specified.
Other Wake and Patch (Remote Unlock) Administrator role facts:
An administrator can see how many systems made it into Windows for the Wake and Patch (Remote Unlock) process. The results can be seen via the 'DE: Product Client Event' Query with an appropriate filter. The results depend on the systems having communicated with the ePO server to send the audit information.
An administrator can't determine which systems did not make it past preboot when using the Wake and Patch feature. Because the system does not boot into Windows, there is no entry in the 'DE: Product Client Event' Query.
An administrator can stagger the Wake and Patch (Remote Unlock), or the interval.to contact ePO. An administrator needs to stagger the Deep Command Power On command, or their equivalent Wake on LAN request.
Systems are turned on when remediated in the SILA (local) environment (when the action is server-initiated). In other cases, the client contacts ePO; So, it can be assumed to be on because it contacted the ePO server.
What is theRemote Remediation Use Case?
This feature offers administrators the ability to perform an Emergency Boot, or replace the DE MBR on a client system via AMT. It does so without needing to physically touch the computer. Which enables an administrator to fix an issue on a client system that is half a world away.
Example Use case 1:
An administrator in Santa Clara is trying to run an emergency boot on a user who is in Japan. The user needs a recovery urgently before an important meeting.
Using this process requires no user intervention. They can simply watch you repair their client system. Which is correct for CILA (Local). For CIRA (Remote), it initially fails, but after the system connects via CIRA it is acted on. NOTE: The time taken for how long the Remote Remediation takes in the above example is largely dependent on the network speed. When it has booted onto the image, it takes the same amount of time as the Emergency Boot takes today if you have done it manually. It actually follows the same process, but in an automated fashion.
Example Use case 2:
The Remote Remediation process was successful and the user has gained access to Windows. The user can give their presentation, but does not have a connection to the corporate ePO server.
In this scenario, the user needs to go through the same process again when they restart their client. This action is the case, if the preboot was damaged, the client would have been emergency booted. It can't be repaired until the client can successfully communicate with the ePO server.
How does Remote Remediation work?
At a high level, a small disk image (1.44 MB in size, but only 300k of it is used) is pushed down via AMT to the client system. When it is received on the client, it restarts and boots using boot network from IDE-R. That image then perform the needed remediation actions and start the process to boot Windows. Other Remote Remediation general facts:
Remote remediation only work on computers with a BIOS boot process.
Remote Remediation functionality does not work in a UEFI environment. IDE Redirection does not work in UEFI and this functionality is required for remote remediation.
The possible actions for Remote Remediation are:
The first is to perform an emergency boot
The second is to replace the MBR.
Other Remote Remediation Administrator role facts:
To use Remote Remediation functionality, an administrator selects one or more systems, then selects the 'Out of Band – Remediation' as the action. Finally specifies either 'Emergency Boot' or 'Restore Endpoint Encryption MBR', before clicking OK.
The following applies for an administrator to receive notifications of the progress of the Remote Remediation:
The administrator is only informed that it has started, and when it has finished.
Upon completion, the administrator is told whether it was successful.
The audit log on the client, is only sent back to ePO on the next Agent to Server Communication (ASCI).
The administrator can run a query on the client events to find the clients with an UNLOCK event.
An administrator would want to replace the MBR, if:
A third-party product accidentally overwrote the MBR, while the system was encrypted
Or
If the system was infected with an MBR virus
For both the above, you would need to get the system back into Windows so any other remediation could then take place.
When selecting a remediation, an Administrator can select a specific disk image. There are different images for BIOS boot and Opal and non-Opal remediation.
Automatic is the default option, and the one you must always use, unless directed otherwise. The automatic option uses the information received from the client to select the correct image. If the information is not available, it does not perform the remediation. This option allows you to specify the exact image that is sent down to the computer.
IMPORTANT: If the administrator selects the wrong disk image for the client, for when the image is selected manually. The User Interface (UI) indicates that you could potentially damage the disk by using the wrong image. This option was added for the event when the Encryption provider or BIOS type is not available.
Other Remote Remediation user experience facts:
Notification of the progress of the Remote Remediation to the user.A message is displayed on the screen when the image has downloaded, and the remediation process starts. NOTE: Downloading of the image to the client via AMT, in some instances you can see a blinking glyph in the top-right corner of the screen. This light is an indication that AMT is receiving network traffic. Again, the duration is largely dependent on network traffic and speed. If the network is fast, the user might see Windows suddenly load.
When a Remote Remediation is performed, a user might not see the blinking glyph. That functionality is only included in AMT version 7. So if you have AMT version 6, you do not see it.
When a user performs a Remote Remediation, runs out of time, and must leave their current location, they do not need to start the whole process again. The reason is because the process starts again automatically. When the administrator has added the request for remote remediation, it sits in the action queue until it has been completed. Or the administrator deletes it. The result is that it tries to perform the remediation each time you switch on the client until it is successful.
How is Remote Remediation initiated on the client when it is local?
Here is an overview of the process when the client system is connected to local enterprise network:
The user boots the system and finds that it is not working.
The user calls the administrator and asks for help.
The administrator selects the appropriate remediation action and the action starts processing immediately. This action is also known as SILA (Server Initiated Local Access).
If the client system is found and can be connected to, Redirection starts and repairs the system automatically.
But, if the client system can't be found in the local network, the action fails and the status remains as pending in the queue. This situation can then only be processed when the system calls in. In this situation, the system can't call because preboot is broken. So a similar flow as described in the next scenario below could also be used.
How is Remote Remediation initiated on the client when it is remote?
Here is an overview of the process when the system is connected through a public network:
The user boots the system and finds that it is not working.
The user calls the administrator and asks for help
The administrator selects the appropriate remediation action and the action starts processing immediately. In this situation, the action fails because it can't find the system in the enterprise network.
The administrator asks the user to initiate a 'Call for Help' from the BIOS. This call varies from one OEM to another. But it tends to be under boot options and in some systems you could simply press CTRL+ALT+F1.
When this option is selected, the system connects to Stunner (Deep Command Gateway Services). Then the Agent handler detects this service, and sends a message to Deep Command.
Deep Command processes the action associated with the system. In this case, it is the remediation action.
NOTE: Remediation over CIRA can take considerably longer than when performing the same action inside the enterprise. On some systems, it could potentially take up to 20 minutes depending on network use during processing. Back to Contents
Whatreports can an administrator use to know that the AMT action has completed successfully on the client?
DE only has one server-side action, which is for remediation. To determine if it completed, an administrator must look at the ePO Server Task Log. Achieved by running a query on the event audit log to see the client events. All other actions (Unlock/Reset, User password) are client-initiated. When the administrator configures these actions, there is an entry in the ePO User Audit log to record that the request has been added to the 'DE: Out‑of‑band action queue'. Then when the client PBA requests help, it creates an audit item on the client. This audit item is sent to ePO on the next ASCI when Windows is loaded. These events appear in the 'DE: Product Client Events' query.
What reports or logs can an administrator view to determine what and where things went wrong and failed to complete the action successfully?
The administrator must look at the AMTService.log and the DE: Product Client Events query.
Where can an administrator see that one (or more) of the AMT actions has been successfully completed on a client (or multiple clients)?
Run the DE: Product Client Event query.
Can an administrator create reports on the AMT actions, for example, to show how many systems have automatically booted today using the Remote Unlock functionality?
Run 'DE: Product Client Events' query with an appropriate filter. This query relies on the systems having successfully communicated with the ePO server to send the audit information.
Whattroubleshooting can an administrator undertake for an AMT Out-of-Band issue? What are the first steps they must perform?
The administrator must establish whether the issue stems from a CILA (local) task or a CIRA (remote) task.
In the case where a CIRA (remote) task was performed, what does the administrator do now?
Ask the administrator to boot the client system and access the BIOS. Or boot to Windows, and use the Intel Management and Security Status to request help. Ask them to look in the 'AMTService.log' to see if a request has been received. If it has, the support call involves DE Technical Support. If not, it involves Deep Command Technical Support.
What if the AMT Out-of-Band issue stemmed from a CILA (local) task?
Ask the administrator to use the Deep Command action to boot the client into the BIOS. If successful, the support call involves DE Technical Support. If not, it involves Deep Command Technical Support.
