DE 7.1.3 - User keeps receiving Balloon notification Preboot password needs updating

[Former Member]

MfeEpe.log shows:   INFO    EpePcMonitor.6028                    Users AD timestamp out of date. Showing notification.

Every two hours (default polling interval for AD domain controllers).

So far only seen this on one out of the 4 systems DE 7.1.3 is deployed to.  On all systems, we are also seeing the McAfee tile on the Credential Provider screen.

Reference #s 1052112 & 1046611

https://kc.mcafee.com/corporate/index?page=content&id=KB84502

Anyone else seeing this in testing?

[Former Member]

Cleared SSO for the user - so far so good. 

Will update if status changes.

Agent 4.8.0.1938 DE: 7.1.3 ePO 4.6.8 with the LDAP sync hotfix installed (Win 7 x64 system in BIOS mode)

[robg3381]

We're testing 7.1.3 and rolled it out to a test group.  Of the 41 upgraded systems, we have had 1 user mention this problem.  I have not had them reset the token yet as I wanted to learn more about the issue before I just fixed it.

We too are noticing the McAfee tile on login as well.

ePO 5.1, Agent 4.8.0.1500.  DE is 7.1.3

Here is a larger snapshot of the MFeEPE log.

2015-08-26 19:10:36,911 INFO    MfeEpeCredentialProviderServiceV2    MfeEpeCredentialProviderServiceV2217330b2-4c26-11e5-af25-acfdce1f51d4 initialized successfully

2015-08-26 19:10:36,911 INFO    MfeEpeCredentialProviderServiceV2    Service Started Successfully

2015-08-26 19:10:37,020 INFO    MfeEpeCredentialProviderServiceV2    Service Stopped Successfully

2015-08-26 19:10:37,067 INFO    MfeEpeCredentialProviderServiceV2    MfeEpeCredentialProviderServiceV2217330b4-4c26-11e5-af25-acfdce1f51d4 initialized successfully

2015-08-26 19:10:37,067 INFO    MfeEpeCredentialProviderServiceV2    Service Started Successfully

2015-08-26 19:10:40,515 INFO    DRIVER                               Session notification: EPEPC_DRIVER_SESSION_UNLOCK

2015-08-26 19:10:41,573 INFO    MfeEpeCredentialProviderServiceV2    Service Stopped Successfully

2015-08-26 19:12:53,946 INFO    EpePcMonitor.5100                    Users AD timestamp out of date. Showing notification.

2015-08-26 19:14:54,552 INFO    EpoPlugin                            enforcePolicy: No policy enforcement required (nothing has changed), waiting until next ASCI.

2015-08-26 19:27:54,023 INFO    EpePcMonitor.5100                    Users AD timestamp out of date. Showing notification.

2015-08-26 19:30:10,491 INFO    EpoPlugin                            enforcePolicy: No policy enforcement required (nothing has changed), waiting until next ASCI.

2015-08-26 19:42:53,912 INFO    EpePcMonitor.5100                    Users AD timestamp out of date. Showing notification.

2015-08-26 19:45:26,531 INFO    EpoPlugin                            enforcePolicy: No policy enforcement required (nothing has changed), waiting until next ASCI.

[jhall2]

The timestamp for the last password change located in AD is newer than the MDE token timestamp for the user. MDE queries AD and pulls the "PassLastSet" timestamp attribute and compares it to the MDE user token timestamp. If the AD timestamp is newer, a prompt will be displayed. However, some of the reasons why the AD timestamp would be newer than the MDE timestamp include:

   1. The client system is not utilizing the same NTP server resulting in the Domain Controller's and client system's not being in sync.

   2. The client system's clock was changed prior to the password change.

   3. A third party password sync utility is utilized that updated the password in AD after the capture of the change at the Ctl + Alt + Del on the client system.

The McAfee icon on the credential provider tile is shown with MDE 7.1.3 as the MDE credential provider logon component is always active when the system is displaying the credential provider. This change was made to allow MDE to capture the password any time it entered, not just when the password is being changed to reduce the occurrences of PBA and domain passwords out of sync.

[robg3381]

Great response!  Thanks!  Do you or anyone know of a way to grab the MDE user token timestamp manually for a user?  Either within ePO or on the users' endpoint?

[jhall2]

The MDE user timestamp can be found in the Machine Info File that can be generated by clicking on the Machine Info button on the MDE Status Monitor (Option must be enabled in the product policy). The timestamp can be converted using an epoch time converted. (The year will be 369 years in the future)

The AD attribute can be obtained using the DSQuery command run on a domain controller:

DSQuery * "CN=TestUser,CN=Users,DC=<YourDomainName>, DC=<Com>" -Attr PwdLastSet

The AD timestamp can be then converted using the w32tm command:

w32tm.exe /monitor /computers:<hostname>

example: w32tm.exe /monitor /computers:MyDC

[robg3381]

Thanks jhall.  I got the Endpoint Info file, but converting using epoch is giving me some crazy values (see below).  To make sure that it wasn't just the trouble users' token/system, I also tried a couple other systems and got similar date/times.  I tried the first 2 google results for "epoch time converter".

UserNameTime:            1426075236148    converts to Wed Mar 11 2015 08:00:36 GMT-0400 (Eastern Daylight Time)

Token Timestamp:         13070401734933 converts to Thu Mar 08 2384 14:08:54 GMT-0500 (Eastern Standard Time)

Logon Data Timestamp:    13085238080488 converts to Mon Aug 27 2384 08:21:20 GMT-0400 (Eastern Daylight Time)

Self-Recovery Timestamp: 13046883475541 converts to: Fri Jun 10 2383 10:17:55 GMT-0400 (Eastern Daylight Time)

SSO Timestamp:           13070401734153 converts to: Thu Mar 08 2384 14:08:54 GMT-0500 (Eastern Standard Time)

For this specific user, their AD timestamp was Monday, August 10, 2015 10:15:10 AM

[jhall2]

Epoch doesn't have a standard start date although most have agreed upon Unix time with a start date is Jan 1 1970. MDE uses the epoch start date for many timestamps of Jan 1 1646; however others start on Jan 1 1970. The date and time are correct but the year is projected out 369 years when decoding using a Unix epoch converter.

From what it shows is MDE captured the password on March 8th but AD is listing Aug 10th. Either the date for the PwdLastSet in AD was updated on Aug 10th via some tool or the clients clock was wrong at the time of the password change as it shows March 8th. It is possible that a password was injected to AD either with a 3rd party utility or by a admin resetting the password via AD Users and Computers but set the password to the same password previously set.

Based on the timestamps, it appears the behavior of displaying the balloon is functioning as expected.

[robg3381]

Thanks jhall.  I was just about the post back that I figured out the epoch time thing.  But you beat me to punch :-).  Everything makes more sense now.  Wished there was a way that it would update those cases where the password was changed via AD Users & computers or a 3rd party utility.  That is what I thought this new feature was improving on and has been a thorn in our help desk' side for years.  Too bad.  Oh well.

[Former Member]

robg3381 ​can you contact me via email at  michael_moyle(at)mcafee.com

Email address altered to remove chance of being harvested for spam sending Moderator