4 Replies Latest reply on Jul 7, 2017 5:37 AM by mirom73

    DE 7.2.0 "Users AD timestamp out of date. Showing notification."

    kvk

      Hi, I have a problem with McAfee Drive Encryption 7.2.0 at a clients site. One user is getting constant notifications to update the user password to match the Windows password.

       

      It doesn't matter how often that is done by the user, the notifications won't stop. I have an extract of the MfeEpe.log File, maybe one of you can tell me what I can do to make this stop? I replaced all occurences of usernames with "PRIVATE".

       

      Thanks for your help!

        • 2. Re: DE 7.2.0 "Users AD timestamp out of date. Showing notification."
          ja2013

          Check your setting for Password synchronization. In my lab, testing that is set aggressively for polling will likely make you change it.

           

          Jay

          • 3. Re: DE 7.2.0 "Users AD timestamp out of date. Showing notification."
            kvk

            Hi Jay,

             

            thank you for replying. The problem is not that the user doesn't want to change the password. The interval is already down to 30 minutes.
            The problem here is that, even if the user has the same passwords for the domain account and McAfee preboot login, Drive Encryption doesn't seem to recognize this and keeps nagging the user to match the passwords.

            • 4. Re: DE 7.2.0 "Users AD timestamp out of date. Showing notification."
              mirom73

              Hi, try to open McAfee Drive Encryption Status windows and Save Machine Info. Open the saved machine info document and try to look at the user information / timestamps:

              UUID:                    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

              Name:                    your_user

              UserNameTime:            1474883167265

              Certificate Timestamp:   0

              Token UUID:              yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

              Token Timestamp:         13068914273064

              Logon Data Timestamp:    13094219719337

              Self-Recovery State:     Uninitialized

              Self-Recovery Timestamp: 13143823830652

              SSO Timestamp:           13065619100707

               

              The iportant timestamp for you is Token Timestamp:

              UserNameTime: The user name used to authenticate at preboot and pulled from Active Directory or User Directory

              Token Timestamp: The token used to authenticate at preboot. This is the machine key that is salted and encrypted using the users password.

              Logon Data Timestamp: This is the password used for the user to login at Preboot and collected either by the Credential Provider during a password change or from PBA if the password is changed there.

                     Note: The Token and Logon timestamps do not always match. If the password is changed on a different system and then propagated to that machine, the token will be updated with the new password and thus timestamp will be newer as the logon data timestamp will reflect the actual point in time the password was collected on the other system.

              Self-Recovery Timestamp: This is the self recovery information and if enabled, the user will be prompted to enter this information at preboot.

               

              Convert TokenTimestamp to human readable time by powershell, or any network converter.

              ################################################################################ ########################

              $TimeZoneDiff = ([datetime]::Now - [datetime]::UtcNow).Hours

               

              $SamAccountName = 'ADXXXXX'

              $UserNameTime = 1499349635632

              $TokenTimestamp = 13143197879578

              $LogonDataTimestamp = 13143824697248

              $SelfRecoveryTimestamp = 13124992176471

              $SSOTimestamp = 13143197878897

               

              $user = New-Object -TypeName psobject ([ordered]@{

                SamAccountName = $SamAccountName

                #Get passwordlastset property from active directory domain

                PasswordLastSet = get-aduser $SamAccountName -Properties passwordlastset | select -ExpandProperty passwordlastset

                #Convert MDE Token Timestamp from "epoch, Unix time" to human readable time

                UserNameTime = ((get-date "1/1/1970").AddMilliseconds($UserNameTime)).AddHours($TimeZoneDiff)

                TokenTimestamp = (([datetime]"1/1/1601").AddMilliseconds($TokenTimestamp)).AddHours($TimeZoneDif f)

                LogonDataTimestamp = (([datetime]"1/1/1601").AddMilliseconds($LogonDataTimestamp)).AddHours($TimeZon eDiff)

                SelfRecoveryTimestamp = (([datetime]"1/1/1601").AddMilliseconds($SelfRecoveryTimestamp)).AddHours($Time ZoneDiff)

                SSOTimestamp = (([datetime]"1/1/1601").AddMilliseconds($SSOTimestamp)).AddHours($TimeZoneDiff)

              })

               

              $user

              ################################################################################ ######################

               

              output:

              PS D:\> .\Convert-ePoTimestampToDateTime.ps1

              Name                           Value

              ----                           -----

              SamAccountName                 ADXXXXX

              PasswordLastSet                23. 6. 2017 16:53:25

              UserNameTime                   6. 7. 2017 16:00:35

              TokenTimestamp                 29. 6. 2017 10:17:59

              LogonDataTimestamp             6. 7. 2017 16:24:57

              SelfRecoveryTimestamp          30. 11. 2016 17:09:36

              SSOTimestamp                   29. 6. 2017 10:17:58

               

              As you can see, TokenTimestamp  29. 6. 2017 10:17:59 in ePO DE is newest then PasswordLastSet 23. 6. 2017 16:53:25 in ActiveDirectory.

              This is a correct state, because user first changed password in active directory and then this change was replicated / synchronized to DE

               

              If the state of your user is correct, try to remove the user from the encrypted system (use ePo console -> Encryption Users), synchronize this change to the end system and when the user will be removed from the end system, add him back.

               

              Miro