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
Anyone else seeing this in testing?
Cleared SSO for the user - so far so good.
Will update if status changes.
Agent 126.96.36.1998 DE: 7.1.3 ePO 4.6.8 with the LDAP sync hotfix installed (Win 7 x64 system in BIOS mode)
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 188.8.131.520. 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.
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.
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?
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
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
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.
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.