Service Accounts LastLogonTimestamp

In an Active Directory domain, if I configure a Windows service on a domain member computer to start with an AD user account (aka "ye olde service account",) and the then the service stays running but I don't restart the service or reboot the machine for a year... does the LastLogonTimestamp of the service account's user object continue to update?

Edit: If you say "it depends on the service," then use MS SQL Server as an example. I set MSSQL Engine to run as contoso\sql-service. Then I leave it alone for a year.

After some research:

LastLogonTimestamp is updated with the following logon types: Interactive, Network, and Service logons.

However, the attribute isn't updated with EVERY logon...

There is another attribute ms-DS-Logon-Time-Sync that controllers how often [in days] the LastLogonTimestamp attribute is updated. The default value is 14 days and is set in code, so if you look at the value in ADSIEdit, you won't see it set.

So, the decision to update LastLogonTimestamp is based off the current date, minus the value of ms-DS-Logon-Time-Sync minus a random percentage (of 5). If the result is equal to or greater than LastLogonTimestamp the attribute is updated and replicated to other DCs.

Process:

Walkthrough of a lastLogontimeStampUpdate update

1. (Assuming the value of the ms-DS-Logon-Time-Sync-Interval is at the default of 14)
2. User logs on to the domain
3. The lastLogontimeStamp attribute value of the user is retrieved
4. 14 - (Random percentage of 5) = X
5. Current date - value of lastLogontimeStamp = Y
6. X ≤ Y - update lastLognTimeStamp
7. X > Y - do not update lastLogontimeStamp

Most of this was found at the following blog article from the Microsoft Directory Services team: The LastLogonTimeStamp Attribute” – “What it was designed for and how it works”

So, yes, you should see the attribute update, but only based off the timing described above.

I have set up an environment in which to run this experiment. It consists of an Active Directory, with the MSDS-LogonTimeSyncInterval set to 1 day. I then installed an MS SQL instance on another domain-joined server, and created a new domain account to use as the SQL service account. SQL started on June 9th, which of course when SQL started, the service account was logged on to the domain for the first time as well. The LastLogonDate of the service account has still not updated from its initial value of June 9th, and I'm expecting that it never will... until SQL is restarted.

The idea behind this was if I'm searching for "inactive" user accounts that need to be disabled, just relying on the user's LastLogonDate could net you some service accounts that are still actively being used, but happen to be used to run services that haven't restarted in a long time.