McAfee ENDPOINT ENCRYPTION ENTERPRISE - BEST PRACTICES GUIDE, Manual

Page: 26 / 26

26
•
When using smartcard readers and tokens, avoid assigning many or all of the Reader or Token file
groups together.
Whilst they can be used together, more compatibility and easier troubleshooting is ensured using just
the specific token or reader files required for a group of machines.
•
Using $autoboot$ user assigned to machines permanently for convenience to bypass pre boot logon
as a normal everyday operational client – there is NO security in doing this.
This results in end users never seeing the pre ‐ boot authentication screen. There are several perceived
benefits to this approach:
‐ No user training
‐ No helpdesk calls for password resets
‐ No administrative work to map users to machines
‐ Most auditors simply require that you prove encryption, not strong authentication
However, there is one major risk to this approach that should outweigh all the perceived benefits: the
data is not secure . If an unauthorised user wanted the data from the drive, they would simply press
the power button and get to the Windows GINA. From there, there a number of known attacks to
access Windows.
Instead, secure your data by removing $autoboot$ users when not needed (for example, after rolling
out a Windows update). Force an authentication to encrypted data.
•
Using one $autoboot$ user for too many machines.
Instead use more autoboot users to reduce the multiple connections and load on the autoboot user
object in the database.
Autoboot user is just like a normal user object in the database. So if the account is accessed by too
many endpoints at once, its object could become locked on the server causing errors with the object
or client.
As a rule of thumb, do not allow more than 100 machines to use a single autoboot account. This can
vary wildly depending on server load, configuration and optimisation. Of course, if concurrency is
high and the server is often busy, reduce this number much more. One tool that can help is the
AutoDomain power tool. This can add and remove individual autoboot users to machines if necessary
for deployment. AutoDomain is not covered by this document.
Also, add backup autoboot accounts. Then, if the autoboot account is removed from the endpoint by
accident ‐ and there is a backup account in place ‐ the user can remain blissfully unaware. The boot
code will look through all autoboot users until it finds one to use.
So add more than one for example :
$autoboot$0001, $autoboot$0002, $autoboot$0003 etc.
Note: at least version 5.2 or above is required for this to work.
For further information on using Autoboot users or the AutoDomain power tool contact McAfee
representatives who can arrange McAfee Professional Services to assist.