It seems that I have been asked to provide a lot of user (& computer) logon information over the past few months. In order to provide this information, I (as others have) leveraged the LastLogonTimeStamp attribute to determine when a user (or computer) logged on last. Assuming you have a Windows 2003 forest mode Active Directory environment, this attribute is available for use. Prior to Windows 2003, the LastLogon attribute which is updated on the local authenticating DC could be queried to get this information with the caveat that it is not replicated. This means that one would have to query the LastLogon attribute for a user(s) on every Domain Controller in the domain to determine the actual last logon date & time.
Detailed information on the LastLogonTimeStamp attribute (Microsoft DS Team Blog)
According to the information on the blog, the LastLogonTimeStamp attribute was never meant to provide accurate logon information given that the attribute’s contents are behind by about 9-14 days.
NOTE: The default replication setting for this attribute is 14 days with a random replication skew of a percent of 5 days. However, if the replication value is set to 5 or less, no randomization is performed.
Furthermore, according to the blog entry:
The lastLogontimeStamp attribute is not updated with all logon types or at every logon. The good news is that the logon types that admins usually care about will update the attribute and often enough to accomplish its task of identifying inactive accounts.
Interactive and Network logons will update the lastLogontimeStamp.
At least one of my customer’s has changed the default value for ms-DS-Logon-Time-Sync-Interval which determines how frequently the LastLogonTimeStamp is replicated. I wanted to easily identify what the modified value is set to so I can provide information in the user logon script to state how accurate the information is. Obviously with the default being 14, the data in the attribute could be two weeks old.
I did quite a bit of research on the ms-DS-Logon-Time-Sync-Interval (displayname msDS-LogonTimeSyncInterval) and discovered that ms-DS-Logon-Time-Sync-Interval is an attribute of the naming context and has a value of “not set” by default (which enforces the default 14 days). Querying this attribute using the PowerShell commandlet Get-ADObject does not show the attribute listed for the naming context. However, when I manually set the value to a number, it shows up.
Changing the ms-DS-Logon-Time-Sync-Interval value is actually quite simple.
- Open ADSI Edit
- Right-Click on the domain DN (DC=domain,DC=com) under Default naming context and select Properties.
- Under Attribute Editor, scroll down to the msDS-LogonTimeSyncInterval attribute and Click Edit.
- Enter a value from 1 to 100,000 (280 years, max set in AD code) and Click OK.
- Click OK
NOTE: Entering a value of 0 for ms-DS-Logon-Time-Sync-Interval disables replication of the LastLogonTimeStamp attribute.
Use Repadmin to get the LastLogonTimeStamp value on all DCs for a specific user:
repadmin /showattr * (DN of the target user) /attrs:lastLogontimeStamp > lastLogontimeStamp.txt
I put together the following code to get the value for ms-DS-Logon-Time-Sync-Interval:
Import-Module ActiveDirectory
# Get Domain Info
write-output “Gathering Active Directory Domain Information… `r”
Write-Verbose “Performing Get-ADDomain powershell command `r”
$ADDomainInfo = Get-ADDomain
$ADDomainDistinguishedName = $ADDomainInfo.DistinguishedName
$DirectoryServicesNamingContext = Get-ADObject -Identity “$ADDomainDistinguishedName” -Properties *
$LLTReplicationValue = $DirectoryServicesNamingContext.”msDS-LogonTimeSyncInterval”
IF ($LLTReplicationValue -ge 1)
{ Write-Output “The msDS-LogonTimeSyncInterval attribute value on $DomainDNS was changed from the default value of 14 to $LLTReplicationValue which means the LastLogonTimeStamp attribute will replication about every $LLTReplicationValue days `r ” }
ELSE
{ Write-Output “The msDS-LogonTimeSyncInterval attribute value on $DomainDNS is configured with the default value of 14 (value is blank) `r ” }
When constructing a Powershell query for inactive users, I also check the PasswordLastSet value. As long as the LastLogonTimeStamp date is older than my threshold (say 365 days) AND the PasswordLastSet date is older than the domain required password, then I can be fairly certain the user is inactive.
Note that using the Powershell AD commandlets, there are additional automatically generated attributes that are most useful. One of these is the LastLogonDate which is the full date and time of the last logon instead of the Integer8 (64bit integer value) representation in the LastLogonTimeStamp attribute. The LastLogonTimeStamp value represents the number of 100-nanosecond intervals that occurred from January 1, 1601 until the time of user logon. Before the Powershell commandlet, one would have to convert this number to the date/time format with which we are more familiar.
Addtional information on LastLogon & LastLogonTimeStamp
Recent Comments