Back in May of last year I mentioned that Longhorn RODCs would have an issue with updating lastLogonTimeStamp. This was indeed the case at the time. I just wanted to revisit the topic and say that the DS team at MSFT realized that was a serious problem and put in some special functionality into Windows Server 2008 so that lastLogonTimeStamp does indeed get updated as it should even if you are logging into an RODC most of the time.
Thanks guys!
Also the first bullet I now believe to be wrong. It was about lastLogonTimeStamp only being updated if lastLogon was updated. I believe I have seen a case where lastLogon wasn’t updated by lastLogonTimeStamp was. I don’t recall the details, just recall seeing it and going… Hmmmm.
So it’s only Mostly Read-Only, abbreviated to MoROn.
As you said in the comments to your earlier posts, relying on lastLogonTimeStamp to say whether an account is “still needed” is not the best way of determining ‘need’ – it determines ‘use’, only.
Let’s say, for instance, that you have an account whose sole purpose is to recover data – say an EFS recovery agent account (I know, it doesn’t need to be an account), or a restore function of some kind.
How often would you logon to that account? Once every recovery exercise?
You … uh … do exercise your recovery capabilities, yes?
Okay, so you’re going to have an account that gets disabled and deleted because nobody logged on to it, and then when you need it, it’s not going to be there, and even re-creating the account, you aren’t going to have the keys associated with it, so you won’t be able to recover the encrypted content that was the whole point of having the account in the first place.
Of course, then you can debate the whole wisdom of deleting accounts in the first place.
The lastLogonTimestamp update logic essentially replicates a new date if the former value was roughly 14 days or more prior. It is covered in the attribute description at http://msdn.microsoft.com/en-us/library/ms676824.aspx.
Note that it requires domain functional level of 2003 or greater.
Mike