I don’t know if anyone else has a hybrid 365 environment, but I am faced with a frustrating dilemma. Based on a support ticket with Microsoft and my research there is no synchronization between 365 and your local active directory for lastlogondate. This means if a user authenticates to a local AD resource vs a 365 cloud resource you can/will have a lastlogondate mismatch. Why is this so concerning you may ask.
Based on security parameters I would like to disable(disuser) accounts that have not be used in a set number of days. That is no problem already have a powershell script to achieve this. What I am trying to figure out is what is the best way to compare the date in my local AD vs the 365 environment to store the true(correct) lastlogondate?
Anyone else that has any feedback it would greatly be appreciated.
I ran into this recently as well. The problem is lastLogonTimestamp is designed for auditing stale accounts, and therefore it is only accurate up to around 14 days or so. If you want to see who hasn’t logged in for a year, this is great. But if you want the literal last time someone logged into the domain, that is a little trickier.
There is another attribute called lastLogon, which is the literal last time a user logged into a specific domain controller. The problem is that this attribute is not replicated to the other domain controllers. What I did was write a script to go to each domain controller and pull that attribute, convert to datetime like you did above, and then sort by LastLogon descending and select the first 1. To do this you would run Get-AdUser with the -Server param and specify the domain controller.
One more interesting factoid about LastLogonTimestamp that you may not be aware of (and that I recently discovered much to my dismay). An update to LastLogonTimestamp can be triggered by a third party process that doesn’t even possess the affected account’s credentials!
To see this in action try this: pick an account in your domain that hasn’t logged in for some time (greater than 2 weeks). Now open up the security properties on some object with an ACL (a fileshare for instance). Now run an “effective permissions” against that account. Wait a few minutes and check the LastLogonTimestamp value for that account and you’ll see that it got updated.
And there are applications out there (such as SharePoint) that regularly run the equivalent of an “effective permissions” against large sets of users.
I’ve lost a lot of faith in the validity of LastLogonTimestamp since learning this and really wish Microsoft would fix this issue.