Windows Server


How to detect Stale Accounts from AD    



How to detect Stale Accounts from AD


How to detect Stale Accounts from AD


Stale Account Detection


Stale account detection is required so that unused computer and user accounts can be removed from Active Directory. On domain controllers running Windows Server 2003 and Windows Server 2003 with SP1, these accounts can be identified by the value in the lastLogonTimeStamp attribute of user and computer objects. This attribute identifies the last time that a user or computer successfully logged on to a domain. The attribute value is replicated to all domain controllers in the domain. lastLogonTimeStamp is new in Windows Server 2003, and its use is enhanced in Windows Server 2003 with SP1.

Scenarios that generate stale accounts

The following common scenarios result in the proliferation of computer and user accounts that are often abandoned by the users who create the accounts:

Delegated computer account creation, which is common in corporate environments, provides the freedom to create multiple accounts but no requirement for deleting them.


Web applications allow external partners to create and manage user accounts that are provided by the host company.


Employees leave the company.

Detection of successful password verification

In earlier versions of Windows, the pwdLstSet attribute was used to identify stale accounts. However, many conditions interfere with the accuracy of this method, such as users who are on sabbatical or otherwise temporarily not using an account. In addition, password time limits can vary throughout an organization. The most efficient way to identify an account that is stale is by evaluating the last time that the user successfully logged on to the domain, rather than the last time the password was reset.

The introduction of the lastLogonTimeStamp attribute in Windows Server 2003 provides the ability to mark an account each time that the system is asked to validate the account password (that is, at logon) for NTLM and Kerberos authentication. These two security protocols update the lastLogonTimeStamp attribute during successful authentication.

Implementation in the domain

Updates to lastLogonTimeStamp are replicated in the domain directory partition. Therefore, the value of this attribute can be checked on any domain controller in the domain. To minimize the effect of domain-wide replication every time that a user or computer logs on, lastLogonTimeStamp is updated only periodically. The period of update is configurable, as follows:

Object: DC=DomainName


Attribute: msDS-LogonTimeSyncInterval


Default value: 14 days

Because the lastLogonTimeStamp attribute is available only when the Windows Server 2003 schema is in effect on all domain controllers in the domain, the feature is activated when the domain functional level is raised to Windows Server 2003. After the domain functional level increase, the first time that a successful logon occurs, the lastLogonTimeStamp attribute is activated on the user or computer object. This method of activation can result in loopholes for certain accounts, as follows:

Accounts that are created before the domain functional level increase but that are not used subsequently


Accounts that are created after the domain functional level increase but that are not used

In these cases, lastLogonTimeStamp is not present on the account object. To identify these accounts, you can query for user and computer objects that have no lastLogonTimeStamp attribute and that have a value in the whenCreated attribute that is earlier than or equal to a specified date.

For example, suppose a user account is created on 1/1/2005. The user leaves the company on 5/1/2005. The domain functional level is raised on 6/1/2005. On 9/1/2005, you query for accounts that do not have the lastLogonTimeStamp attribute. The query returns the account of the user who left the company before the raising of the functional level. However, you need to know if the account was created recently and has not yet been used or if the account was created before the functional level increase and is legitimately out of use. To answer this question, you query for accounts that do not have the lastLogonTimeStamp and that have a whenCreated value of 8/15/2005 or earlier. You select this date on the assumption that any account that was created within the last two weeks will have been used and any account that was created between June 1 and August 15 will certainly have been used. Accounts that are returned by the query are therefore legitimately out of use and can be deleted.

Randomization mechanism for initial use of lastLogonTimeStamp

To avoid network overloads due to thousands of concurrent lastLogonTimeStamp updates when the domain functional level is raised, a five-day window is used to calculate whether the lastLogonTimeStamp value should be updated. The following randomization mechanism is applied to control updates after the domain functional level is raised:


At the time that the functional level is raised, the default value of 14 days for msDS-LogonTimeSyncInterval is used, regardless of whether a different value is set in the attribute.



The value in lastLogonTimeStamp is used to determine the number of days since the last valid logon of the account.



A random percentage of the value 5 is taken and then subtracted from the value in msDS-LogonTimeSyncInterval.



If the result is greater than or equal to the value in lastLogonTimeStamp, the value in lastLogonTimeStamp is updated.

For example, suppose that the value in lastLogonTimeStamp indicates 12 days since the last successful logon. Suppose also that the random percentage is 80 percent of 5 = 4. With the default value of 14 days in effect for msDS-LogonTimeSyncInterval, the calculation is 14 - 4 = 10. Because 12 > 10, lastLogonTimeStamp is updated. In this example, in all cases where the value is less than 10, lastLogonTimeStamp is not updated until the first successful logon that occurs after the msDS-LogonTimeSyncInterval value is reached.





If the value in msDS-LogonTimeSyncInterval is set to 0, the stale account detection feature is disabled and lastLogonTimeStamp is not updated.

Security protocols that update lastLogonTimeStamp in Windows Server 2003

In the initial implementation of lastLogonTimeStamp in Windows Server 2003, lastLogonTimeStamp is updated by the following authentication protocols:




Security protocols notify the directory database of a successful logon so that the account can be marked appropriately in the lastLogon and lastLogonTimeStamp attributes. Therefore, to use stale account detection effectively, it is important that administrators are aware of the security protocols that are in use in their environments.

For example, in Windows Server 2003 environments, the following security protocols request that the system validate a user password:

Secure channel setup (computer accounts only)


NTLM authentication (both interactive and network)


Kerberos authentication


Digest authentication


Third-party Security Support Provider Interfaces (SSPIs) when using the LSA APIs

The following security protocols can reference an account for a security operation:

Schannel, when mapped to an account


Kerberos Service-for-User (S4U) logons


AuthZ APIs in non-S4U mode

The obvious problem is that some accounts might be authenticated without updating the lastLogonTimeStamp, and if this detection method is relied on for stale account cleanup, accounts might be deleted that are still in use.

For example, the following issues occur in Windows Server 2003 implementations:

The NTLM authentication protocol does not update the lastLogonTimeStamp attribute for all network logons. NTLM is therefore not reliable for stale account detection.


The Kerberos S4U authentication protocol, which is used for Web single sign on (SSO) provisioning, does not update lastLogonTimeStamp. Specifically, when extranet users log on to servers running Microsoft Internet Information Services (IIS), Active Directory user accounts are mapped to certificates that are trusted by the IIS server. These certificates are distributed to the client computer so that users do not have to specify credentials. (That is, they are not directly authenticated by a security protocol.)

lastLogonTimeStamp improvements in Windows Server 2003 SP1

Windows Server 2003 SP1 corrects the problems of some protocols not updating lastLogonTimeStamp, as follows:

The inconsistency of NTLM updates of lastLogonTimeStamp is corrected.


Updates to the Key Distribution Center (KDC) ensure that lastLogonTimeStamp is updated in Active Directory when a user logs on to a protected IIS Web site.

Scripting stale account detection

You can implement a scripting solution for managing stale account detection and cleanup. For more information about lastLogonTimeStamp and instructions for creating scripts, see "Dandelions, VCR Clocks, and Last Logon Times: These are a Few of Our Least Favorite Things" on the Microsoft Web site at  




No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3168

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011