1 Reply Latest reply on Jul 18, 2014 10:55 AM by dwebb

    Serious flaw in MDE 7.1.X for organizations that conduct routine system patching (SSO)

    acsmashing

      Hopefully this discussion gets some attention. We are a medium sized organization and manage approximately 400 PCs/Laptops with Mcafee Drive Encryption. We saw great presenations by Mcafee sales reps of the product and we even went over options within EPO to facilitate the patching of machines that have EPO installed by using the various autoboot features. We were sold.

       

      I've already opened up a case with Mcafee support, and the tier 2 engineer state that "Regarding the use of Automatic Booting to allow patches to be applied on a scheduled basis, your configuration is best practice." Makes me feel like we did something right...

       

      1. Mcafee Support has said with regards to Automatic Booting used for patching is best practice.
      2. Page 52 in the MDE 7.1 Product guide says that the Temporary Autobooting feature "Allows you to turn (on or off) the PBA screen, with a client-side utility. This eliminates the need to modify the policy in McAfee ePO, and fully automates patching and other client management scenarios."

       

      But say for example we do patching on Friday evening at 8pm. In order for the patching system to complete it's task, the PCs being patched must be rebooted multiple times. Obviously if the pre-boot authentication screen is active during patching, most likely the user won't be there waiting around to sign the computer into the system everytime the PC is restarted because of patches. What Mcafee recomends for such common scenarios is to disable automatic booting during this patching window.

       

      So thats what we do for patching, enable auto-boot for the duration of the patching job. Then Monday morning rolls around and the user is presented with their Windows logon screen(not the pre-boot screen because remember automatic booting was enabled for patching). The user logs onto Windows and continues with their job. Our standard domain policy is that the user must change his/her password every 90 days. So a month or two may roll by, and maybe a few more patching jobs will run within that time which requires the use of autoboot. Eventually the user will be prompted to change their password, either at initial logon, or if they change their password with the ctrl+alt+del method. So far so good right? Now maybe a few more patching jobs are run with autoboot feature enabled and the user logs into their PC the following business morning after patching and they are still in business.

       

      Well what happens if the user needs to restart the PC, or the PC is restarted for other purposes, such as the installation of new software? Well, the user would be brought to the pre-boot screen, but this time, when it's time for them to enter their password they fail. They may try this about 5 times, entering in their password carefully. Then they call IT and we are scratching our heads wondering what is going on - why in the world is their password not sync'd? We look at the logs and don't see anything obvious.

       

      Earlier this week, we experienced an overload of calls coming into our small IT department. We had 20+ calls all with the same symptoms! We were lucky if the user remembered their LAST windows AD password, because if they did, they could get past pre-boot, log onto Windows with their NEW password, at which point - Mcafee syncs the Windows AD password so on subsequent reboots this would not be an issue.

       

      We are not a unique organization in our patching work flows. We can no longer reccomend this product for our business units and partners until the Mcafee Drive Encryption team comes up with a solution or a documented workaround for organizations that MUST patch for compliance, and that MUST patch for security.

       

      For any Mcafee support representitive who responds back with, just fill out a PER, this is just an embarssment and highlights even more the products failure to integrate into an envrionment that conducts routine patches of their systems. To say that, this is how the product is designed is saying "Our product is horrible and does not integrate well into Windows AD systems that undergo routine patching."

       

      Now I must reinvent the wheel, because I have seen no workaround from Mcafee.

       

      I ask, what can we do to avoid this?

       

      1. After each patching job, and when the autoboot is disabled, restart the systems so the user will sign into pre-boot with their current crednentials?

      2. Restart our systems once per week, to minimize the effect?

       

      I'd like to hear from anyone who must routinely patch their systems and use this product in a Windows AD envrionment. I want to know what your process is for patching your systems and using MDE.

       

      Thanks,

       

      Message was edited by: acsmashing on 7/16/14 4:23:14 PM CDT
        • 1. Re: Serious flaw in MDE 7.1.X for organizations that conduct routine system patching (SSO)
          dwebb

          I’m very sorry to hear you havebeen experiencing difficulties with Drive Encryption and Windows password changes.

           

          In autoboot mode, nobody has logged in at pre-boot, so there is no “Drive Encryption user” associated with the running Windows session.  This means we cannot map a Windows user to a Drive Encryption user for the purpose of synchronizing credentials between the two.  The password changes that your users perform are therefore not being synced to any Drive Encryption user, since there is no active Drive Encryption user at the time of the password change.

           

          To alleviate these symptoms, you will need to have your users log in to pre-boot following your patch cycle –this will ensure that there is an active Drive Encryption user associated with the running Windows session when password changes are made. In the case of patching on a Friday evening, you should plan your workflows such that when your users come in on Monday morning, they are presented with Drive Encryption Pre-boot.

           

          One way to achieve this is touse the Temporary Autoboot tool to enable temporary autoboot for a defined number of restarts (<n>), and ensure that your patching workflow restarts the system <n+1> times.

           

          I hope this helps you understand why you are seeing the symptoms you do, and provides you with some steps that will alleviate the symptoms.

           

          I would also recommend that you look at McAfee Endpoint Assistant as a way to reduce helpdesk calls related to recovery scenarios.  This app (available on Android and iPhone) allows users to register their Drive Encryption recovery keys so that, in the case of a forgotten password, then users can authenticate through preboot using a challenge-response code that they can generate themselves on their mobile device, thus avoiding a helpdesk call.

           

          https://community.mcafee.com/docs/DOC-5517

          https://play.google.com/store/apps/details?id=com.mcafee.endpointassist&hl=en_GB

          https://itunes.apple.com/gb/app/mcafee-endpoint-assistant/id797510089?mt=8

          http://www.youtube.com/watch?v=k1LhoagIlC8

           

          Alternatively, if your endpoint hardware is AMT-capable, you could harness the power of DeepCommand to allow full network-based preboot authentication, ensuring full security without requiring user authentication. Please note, however, that a network unlock also has no active EEPC user.

           

          https://community.mcafee.com/community/business/data/epoenc/blog/2012/12/19/how- to-use-out-of-band-unlock-pba

          http://www.youtube.com/watch?v=B4nKEU0BAX8

           

          Message was edited by: SafeBoot on 7/18/14 11:55:52 AM EDT