We recently ran into issues trying to leverage lastLogonTimestamp to determine roughly how long it had been since a batch of service accounts had last logged in. We found that lastLogonTimestamp was no longer updating for accounts that only used simple binds and that the updating stopped at the same time we upgraded our domain controllers from 2012 R2 to 2016. We found an article that we thought highlighted the problems we were having (https://support.microsoft.com/en-us/help/4131507/) and mentioned this on another list. We were pointed to a joeware blog post (http://blog.joeware.net/2007/05/01/864/) that sheds better light on the old behavior of simple binds, lastLogon, and lastLogonTimestamp.
We read through Joe’s post and noted how a valid simple bind in isolation did not update the lastLogon attribute but that one after an invalid simple bind would. We have done a bit of testing and think we’ve figured out the condition that will cause a simple bind against Server 2016 to update lastLogon but wanted to run our thinking by the list and see if we could get a definitive answer. We think that when badPwdCount is greater than zero, the next valid simple bind will cause lastLogon to be updated. Does anyone know if our guess is correct, and if not, the actual conditions that will cause a simple bind to update lastLogon in Server 2016? Thanks! ALEX BARTH | ITS Systems - Shared Infrastructure The University of Texas at Austin | alexbarth@xxxxxxxxxxxxxxxx | utexas.edu