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.