one thing that seems blindingly apparent to me is there does not seem to be a way of predefining Admin User accounts and also pre-setting the passwords for those admin accounts, for use by adminstrators to bypass the pre-boot authentication that may be present on a device when they are doing support work on them
Completing, if not all, other FDE products let you specify via policy a list of pre-set admin accounts, and also , preset their paswords so that support staff can boot a machine up into windows if required. I can see no other way apart from doing a Challenge/Response.
I would not wish either to have to manually change the pre-defined temporary password which is assigned to all collected user accounts, as this is the same password we would communicate to users for when they first have to log in. Its a security first to think we would have a list of user accounts, all setup at preboot because they have been collected, all set with the same, widely communicated temporary password, because no administrator has logged in at pre-boot and changed it.
This is a major issue. How have others dealt?
most people just create accounts for their administrators to use, put them in a group, and assign that group to every machine ? What am I missing?
and what password would all those users be assigned and use by default? All, the same one that is communicated to users to use as a temporary log-on password for thier accounts?
Not very secure. . . .
Of course not default passwords. Create and use strong passwords for your admins.
You can even script that process if you need to create and selecively add 1000 admins to 100,000 machines.on 10/5/10 1:08:44 PM EDT
The problem though is this. The temporary password is set via a policy which is assigned to a system (not a user). It doesn't matter what user is assigned to the machine, all assigning a user to a machine means is that the 'username'/user is valid for PBA. Until that user logs on for the first time, the password will stay as the default one, which is the same as I say for all users, until they log on and change it.
If I have a load of users called for example 'eepcadmin1' and 'eepcadmin2' and these are in an AD Group called 'eepcadmins', which is assigned to a system, that means there will be two users, in PBA, which, until either eepcadmin1 or eepcadmin2 log on with, will be the same password set in the policy. It is unlikely these admin users will log in until there is a problem, which means it will be left as the same password you would communicate to your users to use against 'their' username after it is first deployed to there machines ergo . .
.admin accounts with a commonly known password.
You cannot set passwords on a per user basis yet via EPO policy, it's just the temporary one until someone logs onto the machine!
Hope that explains the problem better
PS talking here about the ePO Managed EEPC 6.x not the 'scriptable' EEPC 5.x
Message was edited by: jawuk on 05/10/10 15:56:29 CDTMessage was edited by: jawuk on 05/10/10 15:57:39 CDT
I think you are misunderstanding the architecture - users are not "per machine" they are common throughout your environment, so if you assign the AD user "peter" to 2000 machines, he does not have to set a password on each one - the first machine he sets his password on will send that to all the other machines.
So, don't create "special" AD accounts for your administrators, just assign their actual everyday AD account to every machine you want them to be able to access...
this is true for all versions of EEPC from 2001 onwards.
Some other products from other vendors have unique user lists per machine, so "peter" on laptop 1 has nothing to do with "peter" on laptop 2 - they are completely different accounts with different passwords etc. This is NOT how McAfee EEPC works.
are you absolutely sure about this . . . in EEPC 6.x ??
If i have a group, as per my example, assigned to multiple machines. . . if i log on at PBA for the first time. . it will ask for the default password and force a change. That password is then stored against that user in the EEPC PBA environment on that machine. I am not aware the the password is hashed. . .sent back to EPO. . stored in database. . .and then communicated back to any other machines with that user assigned. (i wish eepc 6.x did work like that)
If i wonder up to another machine which has the same group assigned, which would mean users would be assigned to the PBA environment, that i have NEVER logged onto before, . . .will have had its default password changed within the EEPC PBA environment. . . .??
I really really dont think EEPC 6.x works like that. . . although i wish it did. I have a Feature Modification List as long as my arm and one of them is the ability for EPO to actually be aware of passwords set in the PBA environment from clients, so that this. . and other problems do not exist, and you can ACTUALLY set passwords of a per user basis prior to deployment rather than this poxy default password.
JMessage was edited by: jawuk on 06/10/10 04:00:17 CDT
are you absolutely sure about this . . . in EEPC 6.x ??
Absolutely , 100%.
It's the main reason people buy EEPC - because we sync password details across the estate, and we implement users "properly" - ie centrally managed, centrally controlled.
It's not instantaneous - obviously it requires the machine you set/changed your password on to do an ASIC, and it requires the other machines your account is allocated on to also ASIC to pick up the changes, but I am absolutely sure this is how it works.
OK, i will try this in my test lab and let you know how i get on.
There is absolutely no documentation i have managed found anywhere on the McAfee site demonstrating it works in this way, hence my presence on here Can you point me somewhere ?
If this is the case then, why is there not the ability to 'pre-define' a password for an individual user prior to deployment, It would seem like an easy inclusion to make to the product. Especially as AFAIK the 6.1 version of the product, currently in beta allows you to add Non-LDAP users to the PBA of machines.
Its also odd to think that the current EEPC 6.x product does not capture a users password and push that through into the Pre-boot environment, so when PBA gets enabled, they can just use the password it captured with the Windows Log-in.
Seems to be very much EEPC >>> Windows password sync, rather than Windows >>>>> EEPC
There's no docs saying it works any other way... Seriously though, your company probably spent 6 months evaluating the product before purchase, it would have come up.
As to why we don't give you the opportunity to pre-define the password, it was something customers said they did not want when we did the initial design for V6 - people wanted to be able to allocate users to machines, and have the system capture their password on first use.