Q: What is Reactive AutoBoot?
Reactive AutoBoot is an enhancement to the traditional AutoBoot functionality that already exists on Widows and OS X. Like AutoBoot, the drive is encrypted, but the user will not see the pre-boot authentication screen and will be booted directly into the OS.
However unlike traditional AutoBoot, Reactive AutoBoot has one additional piece of functionality. When enabled, the product will monitor Windows authentication requests and if an end user exceeds a specified maximum number of authentication failures, it will automatically enable pre-boot authentication, disable AutoBoot, and immediately reboot the machine.
Once this occurs, you have an encrypted drive and have to successfully pass pre-boot authentication before you have access to the OS and the data on the drive. In summary, this functionality allows the authentication policy to automatically transition from AutoBoot (unlocked, insecure) to Pre-Boot (locked, secure) based on certain conditions designated by a customer as risky being triggered.
Note: although Reactive AutoBoot may appear at first glance to make the system more secure, in fact there is no more security offered by a system in Reactive AutoBoot than there is in AutoBoot, which is precisely none.
Q: How do I enable it?
Reactive AutoBoot is not enabled by default. To enable Reactive AutoBoot an Administrator must check the product policy setting named “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 machines that require the Reactive AutoBoot functionality.
Q: What is a real life example for the use of this feature?
Some customers want to encrypt shared systems that need to be accessed by any user in the organization. As a result, they are unable to assign a specific user or a group of users for pre-boot authentication. Reactive AutoBoot may be an acceptable solution for these customers that otherwise may be forced to deploy using AutoBoot.
Q: Is this a client side feature or does something happen on the ePO server?
This functionality is enacted purely on the client. While audit events, etc. will be uploaded to ePO on the next sync, the ePO server has no interaction with this functionality.
Q: Is this a Windows only feature or does it also work on OS X?
It is a Windows only feature. Reactive AutoBoot is currently not offered on OS X.
Q: What version of Windows does it work on?
This functionality is available on Windows Vista and above. It does not operate on Windows XP.
Q: Are the drive(s) in the machine encrypted when using AutoBoot?
Yes, if so defined in the encryption policy. However, since authentication is not enabled when AutoBoot is enabled, the data is not protected.
Q: Can I specify the maximum number of failed attempts?
Yes, an administrator can specify the maximum number of failed attempts in the policy. It has a minimum value of 1 and a maximum value of 10.
Q: Does this apply to all Windows authentication attempts?
It applies to both Windows logons and unlocks.
Q: Does it matter if the Windows user is a Workgroup user or a Domain user?
Q: Does Reactive AutoBoot work with both Software Encryption and Opal?
Yes, it works the same on both.
Q: Can I use Reactive AutoBoot in co-operation with Temporary AutoBoot?
No. Reactive AutoBoot is only available as an option for scenarios where AutoBoot is always enabled.
End User Experience
Q: What is the end user experience like when Reactive AutoBoot is enabled?
When the end user powers on their machine they will be booted directly into Windows. AutoBoot means there is no pre-boot authentication. They will proceed directly to the Windows logon. Assuming they always successfully authenticate to Windows the end user experience will not change.
Q: What does the end user experience when they exceed the maximum number of failed Windows authentication attempts?
If the end user exceeds the maximum number of failed Windows authentication attempts the following steps will occur on this machine:
Q: If a user has accidentally failed to authenticate, will they have time to save their work before the machine reboots?
No. It is an ungraceful shutdown of Windows. The machine assumes it is under attack and locks down as quickly as possible. The end user will not have any opportunity to save anything they have been working on.
Q: I’m a user who has been using Reactive AutoBoot and after a few failed Windows logons I now see something I’ve never seen before asking me to authenticate. What do I do?
The end user is now seeing the pre-boot environment. They will need to authenticate or go through one of the recovery mechanisms in order to boot the machine into Windows.
Q: Can I simply authenticate with my Windows credentials or use Self-Recovery in order to pass pre-boot and boot into Windows?
The likely answer is No. Assuming that the machine had always been working in AutoBoot mode there is unlikely to be assignment of your EEPC user for pre-boot authentication.
However, if your EEPC user is assigned and you know your EEPC username and credentials then they could of course use those to authenticate.
Q: Can I use the Challenge / Response Recovery to allow the machine to boot into Windows.
Yes. In this scenario this is the option open to all users.
Q: How does Reactive AutoBoot get re-enabled and pre-boot authentication disabled, allowing the end user to go back to their previous workflow?
In this scenario the user will need to successfully authenticate at pre-boot or go through the necessary recovery functionality in order to boot Windows. Once Windows has booted and the EEPC services have started, Reactive AutoBoot will be re-enabled automatically. Other than an authentication at pre-boot, there is nothing for the end user to do.
Q: Is this event audited? And can an ePO administrator see which machines have enabled pre-boot authentication due to this functionality?
Yes. 30070: “Automatic Booting Deactivated – Exceeded maximum failed logons”. However, note that this event information is sent to ePO only after the next successful authentication to Windows and when connectivity to ePO is possible.
The moment that the system thinks it is under attack, it disables AutoBoot and reboots the system. There is no time to send an event to ePO, so ePO is not aware of the lockdown as it is implemented.
Q: Does an administrator need to do anything special to re-enable Reactive AutoBoot on a machine where it has become disabled due to an exceeded number of failed Windows Authentication attempts?
No, there is nothing special an administrator needs to do. Once the machine has booted into Windows, Reactive AutoBoot will be re-enabled automatically. The system does not need to communicate with ePO to re-enable AutoBoot.
Usage with the Intel AMT integration
Q: Can I use the Location Aware use case from the AMT integration with Reactive AutoBoot?
While you could in theory do this, the combined usage doesn’t make sense together.
To refresh your memory on the Location Aware use case you can review the AMT FAQ from version 7.0 (https://community.mcafee.com/docs/DOC-4373).
Q: Why is that?
Firstly, while Reactive AutoBoot is enabled the AMT functionality is not used in pre-boot as the machine will boot directly into Windows.
From a security and usability perspective, it is far better to use the AMT functionality and the Location Aware use case to enable a secure and authorized automatic booting of the machine into Windows. If you’ve gone to the trouble of setting this up it is by far the better solution when compared to Reactive AutoBoot.
Q: Yes, but I want to use the AMT functionality to remove/reduce help desk calls from end users when the Reactive AutoBoot functionality enables pre-boot!
While it’s true that it may reduce/remove the need for a help desk call to continue past the pre-boot environment you can still achieve a scenario where the helpdesk call is required. Importantly, however, the AMT functionality provides data security by requiring an automatic pre-boot authentication to be provided by the server. By contrast, AutoBoot has no pre-boot authentication and provides no data security.
Q: But with both the AMT integration and Reactive AutoBoot the user is taken straight into Windows and allowed to authenticate. If they fail to authenticate too many times I want the system to reboot into pre-boot.
While it is true that the end user experience appears to be the same, that is, they turn on the machine and it boots into Windows, they are in fact different. Reactive AutoBoot is an insecure solution that will just boot into Windows using cryptographic information already present on the client. The Intel AMT integration is a secure solution that will reach out to ePO and ask for permission to boot into Windows and will be passed the necessary cryptographic information in order to do so.
Now think of the scenario:
Once you reach step 7 it will likely force a help desk call anyway. Keep in mind that Reactive AutoBoot is a client side activity and there is no communication with the server, nor time to communicate with the server, when the functionality responds to failed logon attempts.
Q: Then what should I do?
If you’ve gone to the effort of enabling the Location Aware use case using AMT, McAfee’s recommendation is to use that functionality and not Reactive AutoBoot since it provides data security by authenticating from the server. If required you can set a Windows policy to disable the user if they fail to authenticate after a set threshold.