1 2 Previous Next 15 Replies Latest reply on Oct 11, 2010 4:49 AM by jawuk

    Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

      Hi all,

       

      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?

       

       

      Regards

       

      J

        • 1. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

          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?

          • 2. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

            Thanks Simon,

             

            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. . . .

             

            J

            • 3. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

              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
              • 4. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

                Hi Peter

                 

                 

                 

                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

                 

                Regards

                 

                J

                 

                 

                Message was edited by: jawuk on 05/10/10 15:56:29 CDT

                 

                 

                Message was edited by: jawuk on 05/10/10 15:57:39 CDT
                • 5. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

                  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.

                  • 6. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

                    The problem though is this. The temporary password is set via a policy which is assigned to a system (not a user).

                     

                    It is called a default password (not temporary) and it is assigned to each new, unauthenticated user (not system). There two types of policies for EEPC: Product Settings and User Based policies. Password settings are set within User Based policy.

                     

                    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.

                     

                    Right on!. Therefore if you want to distribute non-default password user to your systems, assign it to your machine first. Then authenticate (and of course change password) for that account. Only after that is done and fully communicated with ePO backend, assign that admin user to large (selected) number of systems that you want to manage.

                     

                     

                    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.

                     

                    Actually this problem is not so much limited to admin accounts. It is applicable to any account that is not yet authenticated but already assigned to system. Therefore my recommendation is not to assign blindly unauthicated users to machines. I strongly recommend against assigning large group of users to each system.

                     

                     

                     

                    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!

                     

                    You right about default password. It can be only one per policy. But I have showed you how to implement additional accounts safely.

                     

                     

                    Hope that explains the problem better

                     

                    PS talking here about the ePO Managed  EEPC 6.x not the 'scriptable' EEPC 5.x

                     

                    Right, I have realized that later on. So forget about simple EEPC 5.x scripting.

                    • 7. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

                      Hi Simon,

                       

                      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.

                       

                      Regards

                       

                      J

                       

                       

                      Message was edited by: jawuk on 06/10/10 04:00:17 CDT
                      • 8. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)

                        Hi Peter,

                         

                        thanks for your feedback.

                         

                        Right on!. Therefore if you want to distribute non-default  password user to your systems, assign it to your machine first. Then  authenticate (and of course change password) for that account. Only  after that is done and fully communicated with ePO backend, assign that  admin user to large (selected) number of systems that you want to manage

                         

                        So tell me, in a large environment, for a deployment perspective. How would YOU have some pre-defined users in the PBA environment for all encrypted laptops that an IT Administrator can rock up to and boot a machine, using a pre-set username and a long complex password only known by the admin.  Its just not practical to expect that when every machine is build, that an admin will log-on to the PBA and change the password before giviing the machine to a user. In enterprise environments, where builds are very automated, not only is it common to have zero-touch deployment processes, but the same bod that builds and gives the machine to the end-user, you may not be wanting to know the EEPC PBA account and password that would be used by admins to do a PBA bypass in a support situation, which you would be doing if you were telling them to change the passwords. Seriously. . this is a big problem for anyone other than an SME

                         

                        J

                         

                         

                        Message was edited by: jawuk on 06/10/10 03:58:43 CDT
                        • 9. Re: Preconfigured Admin Accounts for Pre-boot Authentication (bypass)
                          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.

                          1 2 Previous Next