From the WNT4 days it was possible to use the "lastLogon" attribute to determine the last logon time of a user account. This attribute has been available in all OS’s until now. The caveat of this attribute is that it does not replicate between DCs and because it is possible for a user account to be authenticated by any DC in the domain, you would need to retrieve the information from every DC in the domain. Starting with Windows Server 2003 (W2K3) a new attribute called "lastLogonTimeStamp" has been introduced which records the last logon time of a user account somewhat more accurately. This attribute is only used by the system when the Domain Functional Level has been raised to Windows Server 2003. That means that only W2K3 DCs exist in the AD domain and no WNT4 or W2K DCs. Compared to the "lastLogon" attribute, the "lastLogonTimeStamp" attribute DOES replicate. To prevent excessive replication that attribute is only updated for NTLM and Kerberos Interactive Logons under certain conditions. The attribute is updated if it is older than [(the current time) – (value of "msDS-LogonTimeSyncInterval" attribute)]. For an accurate explanation of when the attribute is updated I suggest you read joe’s post about the "Replication of lastLogonTimeStamp".
As you might have noticed, Windows Server 2008 (Microsoft’s flagship OS) has RTMed. That OS introduces a new set of attributes which allow you to determine:
- The last successful Interactive Logon (information stored in the "msDS-LastSuccessfulInteractiveLogonTime" attribute)
- The last failed Interactive Logon (information stored in the "msDS-LastFailedInteractiveLogonTime" attribute)
- The total number of failed Interactive Logons recorded since the time has been enabled (information stored in the "msDS-FailedInteractiveLogonCount" attribute)
- The total number of failed Interactive Logons recorded since the last successful Interactive Logon (information stored in the "msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon" attribute)
This feature is only available after the Domain Functional Level has been increased to Windows Server 2008. That means that only W2K8 DCs exist in the AD domain and no WNT4, no W2K or W2K3 DCs. Even after increasing the DFL the feature is not available right away. For this feature you need to distinguish two things: "reporting the information at logon" and "writing the information into the directory at logon". The feature can only be leveraged by Windows Vista and Windows Server 2008. Other OS’s will ignore it. Compared to the other attributes mentioned, these attributes are updated without conditions.
To "write the information into the directory at logon" a GPO with DCs in its Scope of Management must have the setting the following setting enabled:
- Computer Configuration\Administrtive Templates\Windows Components\Windows Logon Options\Display information about previous logons during user logon = ENABLED
At the same time it will also report the information for all accounts logging on at ANY DC in the AD domain.
To "report the information at logon" a GPO with servers and/or clients in its Scope of Management must have the setting the following setting enabled:
- Computer Configuration\Administrative Templates\Windows Components\Windows Logon Options\Display information about previous logons during user logon = ENABLED
If the feature is enabled for servers and/or clients, but not for W2K8 DCs (independent of Domain Functional Level) the following error will occur at logon.
As you can see the user is NOT able to logon. So someone managing a GPO that targets servers and/or clients can configure the system in a way that nobody is able to logon. So be very careful with this!
So if the feature is enabled for BOTH W2K8 DCs and Windows Vista/Windows Server 2008 clients/servers the following will appear the first time an account logs on:
As you can see the user MUST click OK to continue. There is no other option.
I the feature is enabled for BOTH W2K8 DCs and Windows Vista/Windows Server 2008 clients/servers the following will appear at the next successful logon after a certain amount of failed logons:
An example of the account metadata looks like:
Now you might wonder why this feature is important. One of the examples that come to my mind is online banking. As an awareness measure when using online banking some of the online banking systems report the last time your account logged on and used the online banking system. A similar feature like this can be very important for very high secure environments. That way you are able to see if someone is trying to use your account and guessing the password. Unfortunately it does not report from which computers the logons were carried out. For that you would still need to check the security logs of the DCs. One of the tricks you could do to see on which DC the attribute was written is to retrieve the object metadata of the user account (with REPADMIN /SHOWOBJMETA <DC> <ObjectDN>) and check the originating DC of one of the four attributes. When only using W2K8 RWDCs this method is accurate is enough. However, this method might not be that accurate when also using Read-Only Domain Controllers. The reason is that when an account is authenticated by an RODC the information is written into the attributes on the RODC and on a nearby RWDC. And NO, the information does not replicate from the RODC to the RWDC!!! Although the RODC already has the information it will replicate back again from the RWDC to the RODC. This occurs because the update sequence number (USN) and the high-water mark are not updated on the RODC, but they are updated on the RWDC. So it might look like the account was authenticated by an RWDC, but it could also have been authenticated by an RODC.
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########